Bug#810312: tracker.debian.org: Add debian/copyright link

[Orestis Ioannou]

Package: tracker.debian.org
Severity: wishlist
Tags: patch

Dear Maintainer,

I would like to access to the copyright information of packages on the distro-
tracker.
Examples https://sources.debian.net/copyright/license/python-django/1.9.1-1/
https://sources.debian.net/copyright/license/gnubg/1.05.000-3/

I attach a patch that provides a link in the links panel



-- System Information:
Debian Release: 8.2
  APT prefers testing
  APT policy: (1000, 'testing'), (1000, 'stable'), (995, 'stable'), (750, 
'testing')
Architecture: amd64 (x86_64)

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/dash
Init: systemd (via /run/systemd/system)
>From 015cf0331508af79cd2afea4ab384964347ba5d0 Mon Sep 17 00:00:00 2001
From: Orestis Ioannou 
Date: Sat, 2 Jan 2016 14:36:46 +0200
Subject: [PATCH] Provide link to debsources copyright tracker

---
 distro_tracker/vendor/debian/tests.py  | 13 -
 distro_tracker/vendor/debian/tracker_panels.py | 10 --
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/distro_tracker/vendor/debian/tests.py b/distro_tracker/vendor/debian/tests.py
index 5757b41..c641cad 100644
--- a/distro_tracker/vendor/debian/tests.py
+++ b/distro_tracker/vendor/debian/tests.py
@@ -2738,7 +2738,14 @@ class CodeSearchLinksTest(TestCase):
 def browse_link_in_content(self, content):
 html = soup(content)
 for a_tag in html.findAll('a', {'href': True}):
-if a_tag['href'].startswith('https://sources.debian.net'):
+if a_tag['href'].startswith('https://sources.debian.net/src'):
+return True
+return False
+
+def copyright_link_in_content(self, content):
+html = soup(content)
+for a_tag in html.findAll('a', {'href': True}):
+if a_tag['href'].startswith('https://sources.debian.net/copyright'):
 return True
 return False
 
@@ -2757,6 +2764,7 @@ class CodeSearchLinksTest(TestCase):
 response = self.get_package_page_response(self.package.name)
 
 self.assertTrue(self.browse_link_in_content(response.content))
+self.assertTrue(self.copyright_link_in_content(response.content))
 self.assertFalse(self.search_form_in_content(response.content))
 
 def test_package_not_in_allowed_repository(self):
@@ -2771,6 +2779,7 @@ class CodeSearchLinksTest(TestCase):
 response = self.get_package_page_response(self.package.name)
 
 self.assertFalse(self.browse_link_in_content(response.content))
+self.assertFalse(self.copyright_link_in_content(response.content))
 self.assertFalse(self.search_form_in_content(response.content))
 
 def test_package_in_unstable(self):
@@ -2784,6 +2793,7 @@ class CodeSearchLinksTest(TestCase):
 
 response_content = response.content.decode('utf-8')
 self.assertTrue(self.browse_link_in_content(response_content))
+self.assertTrue(self.copyright_link_in_content(response_content))
 self.assertTrue(self.search_form_in_content(response_content))
 
 def test_pseudo_package(self):
@@ -2797,6 +2807,7 @@ class CodeSearchLinksTest(TestCase):
 
 response_content = response.content.decode('utf-8')
 self.assertFalse(self.browse_link_in_content(response_content))
+self.assertFalse(self.copyright_link_in_content(response_content))
 self.assertFalse(self.search_form_in_content(response_content))
 
 def test_code_search_view_missing_query_parameter(self):
diff --git a/distro_tracker/vendor/debian/tracker_panels.py b/distro_tracker/vendor/debian/tracker_panels.py
index 49ba680..35e3b2e 100644
--- a/distro_tracker/vendor/debian/tracker_panels.py
+++ b/distro_tracker/vendor/debian/tracker_panels.py
@@ -132,7 +132,9 @@ class SourceCodeSearchLinks(LinksPanel.ItemProvider):
 'stable',
 'oldstable',
 )
-SOURCES_URL_TEMPLATE = 'https://sources.debian.net/src/{package}/{suite}/'
+DEBSOURCES = 'https://sources.debian.net/'
+SOURCES_TEMPLATE = DEBSOURCES + 'src/{package}/{suite}/'
+COPYRIGHT_TEMPLATE = DEBSOURCES + 'copyright/license/{package}/{suite}/'
 SEARCH_FORM_TEMPLATE = (
 '

Bug#803846: opal: FTBFS with FFmpeg 2.9

[Eugen Dedu]

On 08/01/16 00:31, Andreas Cadhalpun wrote:

Hi Eugen,


On 09.11.2015 11:55, Eugen Dedu wrote:
Thank you for the patch.  We hope to upload a new release of opal in
2 months (very very approximately), which includes most if not all of
your changes, so I prefer to wait a bit.


The next version of FFmpeg is planned to be released this month
(and it might be called 3.0 instead of 2.9).

Two month have passed now, so I'm wondering what the status
of this bug is:
  * Is the upstream release ready?
  * Do you plan an upload soon?

If this bug isn't fixed soon, it will become release critical and
thus the package will either get NMUed or removed from testing.


Hi Andreas,

The release have not happened and will not happen certainly this month. 
 So I will very soon apply the path in debian.


Happy new year!
--
Eugen

Bug#769928: ITP: python-instagram -- A Python 2/3 client for the Instagram REST and Search APIs

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> I would very much like to see this module in Debian, as it is a dependency
> of the creepy package I maintain.  Is there anything I can do to help?  I
> noticed the request for sponsoring in #770149, but unfortunately too late
> as the package has been removed from mentors in the mean time.

I just found http://anonscm.debian.org/cgit/collab-maint/python-instagram.git/ >,
which seem to be the source used by Jörg.  I'll update it to the latest version.
-- 
Happy hacking
Petter Reinholdtsen

Bug#810310: systemd gets stuck at shutdown/reboot

[Michael Biebl]

Am 08.01.2016 um 08:44 schrieb Harald Dunkel:
> Package: systemd
> Version: 228-3
> Since the most recent upgrade of cryptsetup (2:1.7.0-1) systemd
> gets stuck at shutdown or reboot. Last message:

Ok, then this looks like a regression in cryptdisks.

>   stopping remaining crypto disks
> 
> I waited for a minute, then I pulled the plug.
> 
> systemd must not get stuck, no matter what.

systemd has a 90s default timeout after which services are killed by
default.

So would be worth waiting for at least that amount of time.

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



signature.asc
Description: OpenPGP digital signature

Bug#809402: offlineimap: Ui cannot be specified anymore and passwords with % inside do not work

[Ilias Tsitsimpis]

Control: retitle -1 offlineimap: Blinkenlights cannot be used with '-l' option
Control: tags -1 + upstream
Control: severity -1 normal
Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/293

Hi Raphael,

On Thu, Jan 07, 2016 at 06:00PM, raph...@encr.es wrote:
> Indeed the %% works, I tried it before, but I don't know why I didn't see it
> was working ! Sorry for the noise
> I used another UI, and all work except Blinkenlight

Good to hear that it worked!

I changed the title of the report in order to track the broken
Blinkenlight UI and lowered the severity to 'normal' since it is now
working for you.

Cheers,
Ilias

Bug#810315: backuppc: problem charset in BackupFilesOnly

[root]

Package: backuppc
Version: 3.3.0-2
Severity: important

Dear Maintainer,

I've got a problem when i try to backup a windows 7 french host, when this one 
got special character in "BackupFilesOnly" path.
I use to do that the web interface.
here is an example of a host which works fine : 

$Conf{RsyncShareName} = [
  '/cygdrive/c/Users/user1/'
];
$Conf{BackupFilesOnly} = {
  '/cygdrive/c/Users/user1/' => [
'Messagerie',
'Data'
  ]
};

In this example, everything works fine, only Messagerie and Data are saved and 
not the entire "/cygdrive/c/Users/user1/" directory.


here is an example of a host which does not works fine : 
If the directory to save is /cygdrive/c/Users/user2/Données/(note the 
accent)

$Conf{BackupFilesOnly} = {
  '/cygdrive/c/Users/user2/Données/' => [
'Messagerie'
  ]
};
$Conf{RsyncShareName} = [
  "/cygdrive/c/Users/user2/Donn\x{e9}es/"
];

then the entire "/cygdrive/c/Users/user2/Données/" directory is saved, it seems 
that BackupFilesOnly directive is not used


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

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

Versions of packages backuppc depends on:
ii  adduser   3.113+nmu3
ii  apache2 [httpd]   2.4.10-10+deb8u3
ii  apache2-mpm-worker [httpd]2.4.10-10+deb8u3
ii  apache2-utils 2.4.10-10+deb8u3
ii  bzip2 1.0.6-7+b3
ii  debconf [debconf-2.0] 1.5.56
ii  dpkg  1.17.26
ii  iputils-ping  3:20121221-5+b2
ii  libarchive-zip-perl   1.39-1
ii  libc6 2.19-18+deb8u1
pn  libcompress-zlib-perl 
ii  libtime-modules-perl  2013.1113-2
ii  libwww-perl   6.08-1
ii  perl [libdigest-md5-perl] 5.20.2-3+deb8u1
ii  samba-common-bin  2:4.1.17+dfsg-2+deb8u1
ii  smbclient 2:4.1.17+dfsg-2+deb8u1
ii  ssmtp [mail-transport-agent]  2.64-8
ii  tar   1.27.1-2+b1
ii  ucf   3.0030

Versions of packages backuppc recommends:
ii  libfile-rsyncp-perl  0.70-1.1+b1
ii  libio-dirent-perl0.05-1+b2
ii  openssh-client [ssh-client]  1:6.7p1-5
ii  rrdtool  1.4.8-1.2
ii  rsync3.1.1-3

Versions of packages backuppc suggests:
pn  par2   
ii  w3m [www-browser]  0.5.3-19

-- Configuration Files:
/etc/backuppc/config.pl bfde4d3d06afcb9a335f47e3dcacd90d [Errno 2] Aucun 
fichier ou dossier de ce type: u'/etc/backuppc/config.pl 
bfde4d3d06afcb9a335f47e3dcacd90d'
/etc/backuppc/hosts changed [not included]
/etc/backuppc/localhost.pl changed [not included]

-- debconf information excluded

Bug#769928: ITP: python-instagram -- A Python 2/3 client for the Instagram REST and Search APIs

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> I just found  http://anonscm.debian.org/cgit/collab-maint/python-instagram.git/ >,
> which seem to be the source used by Jörg.  I'll update it to the latest 
> version.

I've updated the packaging slightly and uploaded the code with Jörg as 
maintainer
and me as uploader.  Hope this was OK.

I've tested the new package with creepy, and it seem to work as it should with 
it.

-- 
Happy hacking
Petter Reinholdtsen

Bug#810311: ITP: field3d -- a library for storing voxel data on disk and in memory.

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: field3d
  Version : 1.6.1
  Upstream Author : Sony Pictures Imageworks Inc
* URL : https://github.com/imageworks/Field3D
* License : BSD
  Programming Lang: C++
  Description : a library for storing voxel data on disk and in memory.

Field3D is an open source library for storing voxel data. It provides C++
classes that handle in-memory storage and a file format based on HDF5 that
allows the C++ objects to be written to and read from disk.

NOTE: This package is an optional build dependency for OpenImageIO.

Bug#605090:

[Yves-Alexis Perez]

On ven., 2016-01-08 at 00:44 +, ban...@openmailbox.org wrote:
> I've been experimenting with the source package in unstable. There is 
> still some security advantages of building the source package such as 
> unique RANDSTRUCT values not known publicly: 
> https://github.com/Whonix/grsecurity-installer/issues/1#issuecomment-
> 169819722

Yeah but that's definitely not the point here, which was to provide a binary
package. For people willing to build their own kernels, the make deb-pkg way
is the most effective imho (or you could use Brad's build service).
> 
> Installing the build dependencies on Debian stable would upgrade a lot 
> of core libs to unstable. Can you consider adding the gcc and other 
> build tools Debian stable versions to the package control file?

I actually have a jessie branch which I'll try to upload to jessie-backports
at one point. For now it's available on my repository, as previously.

Regards,
-- 
Yves-Alexis



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

Bug#797785: [Aptitude-devel] Bug#797785: aptitude: TUI to catch debtags warnins/errors

[Pavel Reznicek]

Hi Manuel,

  sorry for the delay. These are the repositories where I experience
the problem:

deb [arch=i386] http://www.rarewares.org/debian/packages/unstable/ ./

deb [arch=i386] http://repository.elivecd.org/ lenny drivers efl elive games 
main multimedia other ports tests

Each of them containing a single non-UTF8 character in one of the
package descriptions, easily to be found by running:

grep -axvn '.*' /var/lib/apt/lists/*

Best regards,
Pavel

Bug#807026: FTBFS on amd64

[Graham Inggs]

On 08/01/2016 06:58, Jens Reyer wrote:

I committed changes that allow to build arch:all everywhere again.
Despite the below described problems with arch specific paths in the
manpage, I still think this is the best solution.


Thanks, better than not building at all on amd64, for sure.


Upstream recently changed the buildsystem, since then the wine manpage
isn't available any more on 64-bit.


Has this been reported with upstream?  I don't think arch-dependent 
manpages are a good idea.

Bug#810313: procps: On update, dpkg fails with an error code (1)

[LESOUEF Emmanuel]

Package: procps
Version: 2:3.3.11-3
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
On update of my laptop, then configuration process of procps fails with an
error code.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt-get dist-upgrade
   * What was the outcome of this action?
Dpkg fails with the following error message :
"Job for systemd-sysctl.service failed because the control process exited with
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe"
for details."
Executing journalctl as root displays among other things :
-- L'unité (unit) systemd-sysctl.service a commencé à démarrer.
janv. 08 09:27:21 nienor systemd-sysctl[5089]: Couldn't write '2' to
'kernel/dmesg_restrict', ignoring: Invalid argument
janv. 08 09:27:21 nienor systemd[1]: systemd-sysctl.service: Main process
exited, code=exited, status=1/FAILURE
janv. 08 09:27:21 nienor systemd[1]: Failed to start Apply Kernel Variables.
-- Subject: L'unité (unit) systemd-sysctl.service a échoué

   * What outcome did you expect instead?
A good procps update I suppose :)



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

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

Versions of packages procps depends on:
ii  initscripts   2.88dsf-59.2
ii  libc6 2.21-6
ii  libncurses5   6.0+20151024-2
ii  libncursesw5  6.0+20151024-2
ii  libprocps52:3.3.11-3
ii  libtinfo5 6.0+20151024-2
ii  lsb-base  9.20150917

Versions of packages procps recommends:
ii  psmisc  22.21-2.1+b1

procps suggests no packages.

-- no debconf information

Bug#810287: fail2ban: Error in jail.conf configuration file in [roundcube-auth] section

[Dmitry Katsubo]

On 2016-01-08 01:08, Yaroslav Halchenko wrote:

Thanks!

it was fixed upstream awhile back in
d278fbca306d8bdcc5b3ffe34b1cfc3cd8963f0b
I guess we should cook up a new upstream release (0.9.4) and update 
package in

Debian

Cheers


Hi Yaroslav,

If you have a chance, could you look into how systemd logs the error 
message in case when fail2ban server fails to start? It was really a 
challenge to find out what went wrong.


Thanks.

--
With best regards,
Dmitry

Bug#809101: libdatetime-format-duration-perl: warns on usage with Perl 5.22

[Niko Tyni]

Control: tag -1 pending

On Mon, Dec 28, 2015 at 02:31:46PM +, Colin Watson wrote:
> On Sun, Dec 27, 2015 at 01:36:49PM +0200, Niko Tyni wrote:
> > This package now warns on usage, and makes its reverse dependencies
> > like libmoosex-types-iso8601-perl do so as well.
> > 
> > % perl -w -e 'use DateTime::Format::Duration'
> > Unescaped left brace in regex is deprecated, passed through in regex; 
> > marked by <-- HERE in m/%{ <-- HERE (\w+)}/ at 
> > /usr/share/perl5/DateTime/Format/Duration.pm line 583.
> > Unescaped left brace in regex is deprecated, passed through in regex; 
> > marked by <-- HERE in m/(%{ <-- HERE (\w+)})/ at 
> > /usr/share/perl5/DateTime/Format/Duration.pm line 584.
> 
> https://github.com/karenetheridge/DateTime-Format-Duration/commit/640674988a1e62a780967d5045df5f2ed2987cde
> fixes this and can be cherry-picked as follows, although a maintainer
> upload should possibly just upgrade to 1.04.
> 
>   * Cherry-pick from upstream: fix "Unescaped left brace in regex is
> deprecated" warning in 5.22+ (closes: #809101).

Thanks, Colin! I've uploaded an NMU to DELAYED/10 with the attached patch.

Jonas, please let me know if you'd like to fix this yourself, or
alternatively, if you'd like to see the pkg-perl group adopt this package.
-- 
Niko Tyni   nt...@debian.org
diff -Nru libdatetime-format-duration-perl-1.03a/debian/changelog 
libdatetime-format-duration-perl-1.03a/debian/changelog
--- libdatetime-format-duration-perl-1.03a/debian/changelog 2016-01-08 
11:12:51.0 +0200
+++ libdatetime-format-duration-perl-1.03a/debian/changelog 2016-01-08 
10:51:08.0 +0200
@@ -1,3 +1,13 @@
+libdatetime-format-duration-perl (1.03a-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick from upstream: fix "Unescaped left brace in regex is
+deprecated" warning in 5.22+, thanks to Colin Watson.
+(Closes: #809101)
++ switch the package to the "3.0 (quilt)" source format.
+
+ -- Niko Tyni   Fri, 08 Jan 2016 10:45:59 +0200
+
 libdatetime-format-duration-perl (1.03a-1) unstable; urgency=low
 
   * Initial Release. (Closes: #632353)
diff -Nru 
libdatetime-format-duration-perl-1.03a/debian/patches/0001-fix-regex-warning-in-perl-5.22.patch
 
libdatetime-format-duration-perl-1.03a/debian/patches/0001-fix-regex-warning-in-perl-5.22.patch
--- 
libdatetime-format-duration-perl-1.03a/debian/patches/0001-fix-regex-warning-in-perl-5.22.patch
 1970-01-01 02:00:00.0 +0200
+++ 
libdatetime-format-duration-perl-1.03a/debian/patches/0001-fix-regex-warning-in-perl-5.22.patch
 2016-01-08 11:03:26.0 +0200
@@ -0,0 +1,31 @@
+From 1f783cac482a9572687cdc4118d84142db91f310 Mon Sep 17 00:00:00 2001
+From: Niko Tyni 
+Date: Fri, 8 Jan 2016 10:41:38 +0200
+Subject: [PATCH] fix regex warning in perl 5.22+
+
+Author: Karen Etheridge 
+Origin: backport, 
https://github.com/karenetheridge/DateTime-Format-Duration/commit/640674988a1e62a780967d5045df5f2ed2987cde
+Bug: https://rt.cpan.org/Ticket/Display.html?id=101607
+Bug-Debian: https://bugs.debian.org/809101
+---
+ lib/DateTime/Format/Duration.pm | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/DateTime/Format/Duration.pm b/lib/DateTime/Format/Duration.pm
+index e5f0af8..8f1f565 100755
+--- a/lib/DateTime/Format/Duration.pm
 b/lib/DateTime/Format/Duration.pm
+@@ -580,8 +580,8 @@ sub _build_parser {
+ 
+ 
+   # Any function in DateTime.
+-  $regex =~ s|%{(\w+)}|($tempdur->can($1)) ? "(.+)" : ".+"|eg;
+-  $field_list =~ s|(%{(\w+)})|($tempdur->can($2)) ? "#$2#" : $1 |eg;
++  $regex =~ s|%\{(\w+)}|($tempdur->can($1)) ? "(.+)" : ".+"|eg;
++  $field_list =~ s|(%\{(\w+)})|($tempdur->can($2)) ? "#$2#" : $1 |eg;
+ 
+   # White space:
+   $regex =~ s/%(\d*)[tn]/($1) ? "\\s{$1}" : "\\s+"/eg;
+-- 
+2.6.4
+
diff -Nru libdatetime-format-duration-perl-1.03a/debian/patches/series 
libdatetime-format-duration-perl-1.03a/debian/patches/series
--- libdatetime-format-duration-perl-1.03a/debian/patches/series
1970-01-01 02:00:00.0 +0200
+++ libdatetime-format-duration-perl-1.03a/debian/patches/series
2016-01-08 10:45:51.0 +0200
@@ -0,0 +1 @@
+0001-fix-regex-warning-in-perl-5.22.patch
diff -Nru libdatetime-format-duration-perl-1.03a/debian/source/format 
libdatetime-format-duration-perl-1.03a/debian/source/format
--- libdatetime-format-duration-perl-1.03a/debian/source/format 1970-01-01 
02:00:00.0 +0200
+++ libdatetime-format-duration-perl-1.03a/debian/source/format 2016-01-08 
10:50:10.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#810314: /usr/bin/gnatstub: gnatstub: bug box (on all my test examples)

[Jacob Sparre Andersen]

Package: asis-programs
Version: 2014-4
Severity: important
File: /usr/bin/gnatstub

Dear Maintainer,

When I tried to see how 'gnatstub' works, I found that it fails with a
"bug box" on all my chosen example files:

An example:

% cat noget.ads
package Noget is
   procedure Hello (I : Integer);
end Noget;
% gnatstub -t noget.ads

+===ASIS BUG DETECTED==+
| ASIS 2.0.R for GNAT 4.9.2 CONSTRAINT_ERROR a4g-gnat_int.adb:242 range check 
failed|
| when processing A4G.Contt.SD.Read_and_Check_New (tree file /tmp/noget.adt)|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box and the ASIS debug info  |
| in the report.   |
| Include the exact list of the parameters of the ASIS queries |
| Asis.Implementation.Initialize and Asis.Ada_Environments.Associate   |
| from the ASIS application for which the bug is detected  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
| NOTE: ASIS bugs may be submitted to rep...@adacore.com   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.


% ls -l noget.*
-rw-r--r-- 1 sparre sparre 62 jan  8 10:08 noget.ads
-rw-r--r-- 1 sparre sparre 348728 jan  8 10:16 noget.adt
-rw-r--r-- 1 sparre sparre284 jan  8 10:16 noget.ali
%

I don't depend on being able to use 'gnatstub', but it would be nice
if it worked.

-- 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/4 CPU cores)
Locale: LANG=fo_FO.ISO-8859-1, LC_CTYPE=fo_FO.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages asis-programs depends on:
ii  gnat4.9
ii  gnat-4.94.9.2-1
ii  libasis2014 2014-4
ii  libc6   2.19-18+deb8u1
ii  libgcc1 1:4.9.2-10
ii  libgnat-4.9 4.9.2-1
ii  libgnatcoll1.6  1.6gpl2014-6
ii  libgnatprj4.9   4.9.2-1
ii  libgnatvsn4.9   4.9.2-1

Versions of packages asis-programs recommends:
ii  libaunit3.7.1-dev  3.7.1-1

asis-programs suggests no packages.

-- no debconf information

Bug#810291: RFS: emacs-async/1.6-1 [ITP] -- simple library for asynchronous processing in Emacs

[Michael Albinus]

Sean Whitton  writes:

> Dear mentors,

Hi Sean,

> I am looking for a sponsor for my package emacs-async.
>
> * Package name: emacs-async
>   Version : 1.6
>   Upstream Author : John Wiegley 
> * URL : https://github.com/jwiegley/emacs-async
> * License : GPL-2+
>   Section : lisp

Please note, that async has been added to GNU ELPA recently. According
to John Wiegley, further development shall happen there. And indeed,
first patches for async.el have arrived the GNU ELPA repo.

> Thanks.
>
> Sean Whitton

Best regards, Michael.

Bug#809755: this is fixed in experimental

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have just uploaded 0.5.5.1+debian-1 to experimental (you may install
it right now from
https://people.debian.org/~praveen/diaspora-unreleased/ or wait for it
to reach testing)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWj2vBAAoJEM4fnGdFEsIqX4MP/jhl6QHaAgZdszZ1aMoaqoVz
Jc18rmvNjAHhDfTLAdGR3kiWYZ6NUeIpb3zAv2+dWWrzJelqxKVDzBKndXP6JRY+
qPvf+EDDAErCiBF0GIJYr5lgJkUxLJsbik1pMEGsxZoSGIbHq+AA4usHetbRy/HL
sjHEJedy3mADH7d8hYr6ob6YDhZJVZ5p5nb0DKtoHKMcUXHccCNxBhnaBxyhUfgh
f6tRWnP8pE4QlKDPwvb8nQZg5pyPs21Oa413A9CE23+R/s6xy4wyRf4akr+PBq+h
LFwzIEouTdjKYY5Ps7k9BOwvlsJsajuKJ5CiBgoj+9m2H4mldWdfzf+IHtm3NSbG
rrmWxZLqXgQSw5p0CjwvKBRdHrTbnwFK38WElNwIAsMXNgw00v/sxvxHSP/3rBHY
TGGW0hH/oYiWcXb+Rzay9epH7k34UocmFSiwpZOoRMLW62Sygog+glV5JPrFooOf
agojJtLG69Ds2KPXdunFyNv61kwO4RlqrzkUg7Ch1nB7N3/q7/wj+OWNrCr5jVBn
VQgdOiJ/BWbBtp8p7zZDz2TAtGslANAFAccQwRMIoRYN/3to1Avyzc1IhsV19Zox
8Culi8CIyLz5f4AqMUTeiAgGl1RQz0INh7PWo8YpEruyqCSegmhiqhA8uXmSC4EU
6MnG7MqWzH6F0HECNJP+
=mdil
-END PGP SIGNATURE-

Bug#810325: Wordpress backported patches

[Rodrigo Campos]

Or, if you prefer, you can see the changes backported to 4.1 directly by
wordpress (they release 4.1.9 that you can use as base for debian stable).

Also, if you want to see the patches in git, you can see:

https://github.com/WordPress/WordPress/commits/4.1-branch

The relevant patch that Salvatore points out, is backported there (in fact,
there are only 3 patches in this new 4.1.x release).

So, if the patch does not apply cleany, as long as wordpress maintains that
branch, you can just apply the patches from there.




Thanks a lot,
Rodrigo

Bug#810390: RFS: pynac -- Engine for symbolic geometric calculus for Python

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pynac" -- a previous version
is already in Debian, so this is only an update :

 * Package name: pynac
   Version : 0.6.0
   Upstream author : Burcin Erocal
 * URL : http://pynac.org
 * License : GPL-2+
   Section : math

  It builds those binary packages:

libpynac-dev - Engine for symbolic geometric calculus for Python 
(development fi

libpynac1  - Engine for symbolic geometric calculus for Python

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


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


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/pynac/pynac_0.6.0-1.dsc



  It is packaged within the Debian Science team here:

Vcs-Git: git://anonscm.debian.org/debian-science/packages/pynac.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/pynac.git


  It is a dep of sagemath, and shouldn't require a transition.

  Thanks,

  Snark on #debian-science

Bug#810469: speedpad: Missing directory 'fortune'

[Torquil Macdonald Sørensen]

Package: speedpad
Version: 1.0-1
Severity: normal

After installing "speedpad", and running it from the terminal, I get the 
following
error message:

Error: No such file or directory: 'fortune'

Best regards,
Torquil Sørensen

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

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

Versions of packages speedpad depends on:
ii  python  2.7.11-1

Versions of packages speedpad recommends:
pn  fortune-mod | fortunes | fortunes-bg | fortunes-bofh-excuses | fort  

speedpad suggests no packages.

-- no debconf information

Bug#807026: FTBFS on amd64

[Jens Reyer]

On 01/08/2016 09:40 AM, Graham Inggs wrote:
> On 08/01/2016 06:58, Jens Reyer wrote:
>> Upstream recently changed the buildsystem, since then the wine manpage
>> isn't available any more on 64-bit.
> 
> Has this been reported with upstream?  I don't think arch-dependent
> manpages are a good idea.

It was done on purpose and knowingly. I read about it on the upstream
mailing list, before seeing the consequences here. Since the manpages
contain arch specific paths I see this as the right solution generally.

The problem is that we can't really make use of the "correct" upstream
buildsystem in Debian, because we ship wrapper scripts in path, without
really knowing if the 32- or the 64-bit version gets installed, or if
they even get co-installed (then the wrapper scripts now default to
32-bit wine and 64-bit wineserver).

However I tend to ignore that as a real problem in the documentation,
see previous mails. I even decided for now to build the
wine64-binary-loader manpage from the unchanged wine-binary-loader
manpage-source.

Greets
jre

Bug#810389: emoslib: FTBFS on m68k: relocation truncated

[Thorsten Glaser]

Source: emoslib
Version: 2:4.3.3-2
Severity: important
Justification: FTBFS on debian-ports arch

https://buildd.debian.org/status/fetch.php?pkg=emoslib=m68k=2%3A4.3.3-2=1452216223


-- Forwarded message --
From: Andreas Schwab 
Message-ID: <87k2nkmjca@igel.home>
Date: Fri, 08 Jan 2016 11:55:17 +0100
Subject: Re: Log for attempted build of emoslib_2:4.3.3-2 on m68k
(dist=unstable)

Thorsten Glaser  writes:

> CMakeFiles/emos_sp_shared.dir/__/interpolation/hirlsm.F.o: In function 
> `hirlsm_':
> /<>/interpolation/hirlsm.F:486:(.text+0x90e): relocation 
> truncated to fit: R_68K_GOT16O against `.LC21'

That can be fixed by using -fPIC instead of -fpic.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Bug#810396: apcupsd: please switch to libusb 1.0

[Aurelien Jarno]

Package: apcupsd
Version: 3.14.12-1.1
Severity: wishlist

Dear Maintainer,

apcupsd has a build-depends on libusb-dev. A few years ago upstream
has released a new major version libusb 1.0 with a different API which
aims to fix design deficiencies with USB 2.0 and 3.0 in mind.

The old libusb 0.1 package is not supported upstream anymore and should
be considered deprecated.

If apcupsd supports the new libusb 1.0 library, please consider
switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not
please inform upstream that porting the software to the new API is
recommended.

Thanks,
Aurelien

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

Bug#810365: [apt] Temporary failure resolving xxxx even when the network is up and running

[BogDan Vatra]

On Friday 08 January 2016 20:21:10 BogDan Vatra wrote:
> On Friday 08 January 2016 17:16:27 Julian Andres Klode wrote:
> > On Fri, Jan 08, 2016 at 05:16:00PM +0100, Julian Andres Klode wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > On Fri, Jan 08, 2016 at 05:28:02PM +0200, Bogdan Vatra wrote:
> > > > Package: apt
> > > > Version: 1.1.10
> > > > Severity: serious
> > > > 
> > > > --- Please enter the report below this line. ---
> > > > The problem happens on an chrooted arm64 image on Android.
> > > > 
> > > > Commands log:
> > > > 
> > > > root@localhost:~# apt update
> > > > Err:1 http://httpredir.debian.org/debian sid InRelease
> > > > 
> > > >   Temporary failure resolving 'httpredir.debian.org'
> > > > 
> > > > Reading package lists... Done
> > > > Building dependency tree
> > > > Reading state information... Done
> > > > All packages are up to date.
> > > > W: Failed to fetch
> > > > http://httpredir.debian.org/debian/dists/sid/InRelease
> > > > Temporary failure resolving 'httpredir.debian.org'
> > > > W: Some index files failed to download. They have been ignored, or old
> > > > ones
> > > > used instead.
> > > 
> > > Probably /etc/resolv.conf is not readable by _apt?
> > 
> > _apt being a username used by the fetching process.
> 
> Well it is world readable:
> 
> root@localhost:~# ls -l /etc/resolv.conf
> -rw-r--r--. 1 root root 43 Jan  8 14:57 /etc/resolv.conf
> 
> I think the problem is that apt is running under _apt user which on android
> it doesn't network permissions.
> 
> Is it possible to run at as root?
> 

I "fixed" it by changing _apt UID to 0 :), but IMHO it is not the best 
solution... 

Yours,
BogDan.

Bug#810470: libusb: superseded by libusb-1.0

[Aurelien Jarno]

Source: libusb
Version: 2:0.1.12-28
Severity: wishlist

libusb 0.1 has been superseded by libusb 1.0, which as a new API in
order to fix design deficiencies with USB 2.0 and 3.0 in mind. It is
not supported upstream anymore and should be considered deprecated. We
should avoid shipping it with stretch if possible.

Bug#810472: linux-image-4.3.0-0.bpo.1-amd64: Please apply upstream patch "xen/gntdev: Grant maps should not be subject to NUMA balancing"

[Matthew Vernon]

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

Hi,

Can you apply the patch described here:
https://lkml.org/lkml/2015/12/16/455

which is 9c17d96500f78d7ecdb71ca6942830158bc75a2b

Otherwise xenstored SIGBUSes, and all sorts of things don't work.
It would be nice if this could be applied to the backports version, too :)

Thanks,

Matthew

-- Package-specific info:
** Version:
Linux version 4.3.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.3.3-2~bpo8+1 (2015-12-23)

** Command line:
placeholder root=/dev/mapper/guests-root ro swiotlb=65536 quiet

** Not tainted

** Kernel log:
[  223.501562] xen-blkback: ring-pages:1, event-channel 9, protocol 1 
(x86_64-abi) persistent grants
[  223.513978] vif vif-14-0 vif14.0: Guest Rx ready
[  223.514359] IPv6: ADDRCONF(NETDEV_CHANGE): vif14.0: link becomes ready
[  223.514425] xenbr0: port 7(vif14.0) entered forwarding state
[  223.514436] xenbr0: port 7(vif14.0) entered forwarding state
[  224.919650] xenbr0: port 4(vif11.0) entered forwarding state
[  227.554177] block drbd22: role( Secondary -> Primary ) 
[  227.763437] device vif15.0 entered promiscuous mode
[  227.765531] IPv6: ADDRCONF(NETDEV_UP): vif15.0: link is not ready
[  229.247892] xen-blkback: event-channel 9
[  229.248075] xen-blkback: /local/domain/15/device/vbd/51712:using single 
page: ring-ref 8
[  229.248186] xen-blkback: ring-pages:1, event-channel 9, protocol 1 
(x86_64-abi) persistent grants
[  229.261336] vif vif-15-0 vif15.0: Guest Rx ready
[  229.261786] IPv6: ADDRCONF(NETDEV_CHANGE): vif15.0: link becomes ready
[  229.261854] xenbr0: port 8(vif15.0) entered forwarding state
[  229.261867] xenbr0: port 8(vif15.0) entered forwarding state
[  229.431740] xenbr0: port 5(vif12.0) entered forwarding state
[  232.204837] block drbd24: role( Secondary -> Primary ) 
[  232.417989] device vif16.0 entered promiscuous mode
[  232.419706] IPv6: ADDRCONF(NETDEV_UP): vif16.0: link is not ready
[  233.815893] xenbr0: port 6(vif13.0) entered forwarding state
[  233.907447] xen-blkback: event-channel 9
[  233.907524] xen-blkback: /local/domain/16/device/vbd/51712:using single 
page: ring-ref 8
[  233.907615] xen-blkback: ring-pages:1, event-channel 9, protocol 1 
(x86_64-abi) persistent grants
[  233.924031] vif vif-16-0 vif16.0: Guest Rx ready
[  233.924406] IPv6: ADDRCONF(NETDEV_CHANGE): vif16.0: link becomes ready
[  233.924457] xenbr0: port 9(vif16.0) entered forwarding state
[  233.924469] xenbr0: port 9(vif16.0) entered forwarding state
[  238.552037] xenbr0: port 7(vif14.0) entered forwarding state
[  244.312168] xenbr0: port 8(vif15.0) entered forwarding state
[  248.952326] xenbr0: port 9(vif16.0) entered forwarding state
[  263.709267] block drbd10: role( Secondary -> Primary ) 
[  263.936863] device vif17.0 entered promiscuous mode
[  263.938996] IPv6: ADDRCONF(NETDEV_UP): vif17.0: link is not ready
[  265.429646] vif vif-17-0 vif17.0: Guest Rx ready
[  265.429984] IPv6: ADDRCONF(NETDEV_CHANGE): vif17.0: link becomes ready
[  265.430053] xenbr0: port 10(vif17.0) entered forwarding state
[  265.430066] xenbr0: port 10(vif17.0) entered forwarding state
[  265.430429] xen-blkback: event-channel 11
[  265.430543] xen-blkback: /local/domain/17/device/vbd/51712:using single 
page: ring-ref 770
[  265.430640] xen-blkback: ring-pages:1, event-channel 11, protocol 1 
(x86_64-abi) persistent grants
[  269.168215] block drbd11: role( Secondary -> Primary ) 
[  269.402078] device vif18.0 entered promiscuous mode
[  269.404387] IPv6: ADDRCONF(NETDEV_UP): vif18.0: link is not ready
[  270.888454] xen-blkback: event-channel 9
[  270.888533] xen-blkback: /local/domain/18/device/vbd/51712:using single 
page: ring-ref 8
[  270.888608] xen-blkback: ring-pages:1, event-channel 9, protocol 1 
(x86_64-abi) persistent grants
[  270.905991] vif vif-18-0 vif18.0: Guest Rx ready
[  270.906327] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready
[  270.906395] xenbr0: port 11(vif18.0) entered forwarding state
[  270.906410] xenbr0: port 11(vif18.0) entered forwarding state
[  273.450949] block drbd5: role( Secondary -> Primary ) 
[  273.696952] device vif19.0 entered promiscuous mode
[  273.699033] IPv6: ADDRCONF(NETDEV_UP): vif19.0: link is not ready
[  275.183686] xen-blkback: event-channel 9
[  275.183803] xen-blkback: /local/domain/19/device/vbd/51712:using single 
page: ring-ref 8
[  275.183896] xen-blkback: ring-pages:1, event-channel 9, protocol 1 
(x86_64-abi) persistent grants
[  275.202798] vif vif-19-0 vif19.0: Guest Rx ready
[  275.203174] IPv6: ADDRCONF(NETDEV_CHANGE): vif19.0: link becomes ready
[  275.203246] xenbr0: port 12(vif19.0) entered forwarding state
[  275.203260] xenbr0: port 12(vif19.0) entered forwarding state
[  278.382573] block drbd14: role( Secondary -> Primary ) 
[  278.621910] device vif20.0 entered promiscuous mode
[  278.623918] IPv6: ADDRCONF(NETDEV_UP): vif20.0: link is not ready
[  280.106576] xen-blkback: 

Bug#805282: Please package version >= 3.9.3

[Jonathan Ulrich Horn]

Control: block 779680 by -1

Hello,

what's the progress on this? Is there anything I could help you with?

Cheers,
Jonathan




signature.asc
Description: OpenPGP digital signature

Bug#810471: libdrm2: [drm] stuck on render ring

[cacatoès]

Package: libdrm2
Version: 2.4.65-3

Dear Maintainers,

I've been recently playing with wine, and playing the game The Witcher.

Sometimes it crashes quite early, and produces some messages in dmesg,
which invite me to write following bug report.

This crash doesn't happen every time, since I was able to run the game a
few times normally.

While my main architecture is amd64, this bug should apply to i386.

Closed bug #745061 has similar error message, but can't say they are
related.

Attached is dmesg log for both times it happened.
You can also find /sys/class/drm/card0/error files there :
https://1fichier.com/?7p4l44bcjq

Tell me if you need more infos/tests.

See you.

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

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

Some installed packages from apt list command:
libdrm-intel1/testing,now 2.4.65-3 amd64  [installé, automatique]
libdrm2/testing,now 2.4.65-3 amd64  [installé, automatique]
First crash:

[19943.354528] [drm] stuck on render ring
[19943.355114] [drm] GPU HANG: ecode 6:0:0x85eefffc, in witcher.EXE [17750], 
reason: Ring hung, action: reset
[19943.355116] [drm] GPU hangs can indicate a bug anywhere in the entire gfx 
stack, including userspace.
[19943.355117] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
against DRI -> DRM/Intel
[19943.355118] [drm] drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.
[19943.355119] [drm] The gpu crash dump is required to analyze gpu hangs, so 
please always attach it.
[19943.355121] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[19943.357212] drm/i915: Resetting chip after gpu hang
[19949.352556] [drm] stuck on render ring
[19949.353124] [drm] GPU HANG: ecode 6:0:0x85fc, in witcher.EXE [17750], 
reason: Ring hung, action: reset
[19949.355456] drm/i915: Resetting chip after gpu hang

Second crash:

[21377.874696] [drm] stuck on render ring
[21377.875315] [drm] GPU HANG: ecode 6:0:0x85eefffc, in witcher.EXE [13986], 
reason: Ring hung, action: reset
[21377.875317] [drm] GPU hangs can indicate a bug anywhere in the entire gfx 
stack, including userspace.
[21377.875318] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
against DRI -> DRM/Intel
[21377.875319] [drm] drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.
[21377.875320] [drm] The gpu crash dump is required to analyze gpu hangs, so 
please always attach it.
[21377.875322] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[21377.877412] drm/i915: Resetting chip after gpu hang
[21383.884690] [drm] stuck on render ring
[21383.885293] [drm] GPU HANG: ecode 6:0:0x85fc, in witcher.EXE [13986], 
reason: Ring hung, action: reset
[21383.887632] drm/i915: Resetting chip after gpu hang


signature.asc
Description: OpenPGP digital signature

Bug#808899: android-platform-frameworks-base: FTBFS: undefined reference to `pseudolocalize_string(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'

[Tobias Frost]

Debugging into it: 
A rebuild of android-platform-build-21 seems to fix it.

-- 
tobi

Bug#810473: yowsup-cli: Fails to register with "old_version"

[Manolo Díaz]

Package: yowsup-cli
Version: 2.4-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

There is no much to add to the subject. The complete output:

INFO:yowsup.common.http.warequest:{"status":"fail","reason":"old_version"}

status: fail
reason: old_version


Best Regards,
Manolo Díaz



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

Kernel: Linux 4.3.3 (SMP w/2 CPU cores)
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 yowsup-cli depends on:
ii  python  2.7.11-1
ii  python-libxml2  2.9.3+dfsg1-1
ii  python-yowsup   2.4-1

yowsup-cli recommends no packages.

yowsup-cli suggests no packages.

-- no debconf information

Bug#790978: android-platform-build: diff for NMU version 21-4.1

[Tobias Frost]

Control: tags 790978 + patch

Dear maintainer,

I've prepared an NMU for android-platform-build (versioned as 21-4.1). The diff
is attached to this message.

Regards.
diff -Nru android-platform-build-21/debian/changelog 
android-platform-build-21/debian/changelog
--- android-platform-build-21/debian/changelog  2014-11-25 13:02:07.0 
+0100
+++ android-platform-build-21/debian/changelog  2016-01-08 20:16:32.0 
+0100
@@ -1,3 +1,11 @@
+android-platform-build (21-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuilt for GCC-5 Transistion (Closes: #790978), adding
+a break against current aapt as suggested in the BTS.
+
+ -- Tobias Frost   Fri, 08 Jan 2016 20:16:32 +0100
+
 android-platform-build (21-4) unstable; urgency=low
 
   * include Breaks: and Replaces: to allow for proper upgrading
diff -Nru android-platform-build-21/debian/control 
android-platform-build-21/debian/control
--- android-platform-build-21/debian/control2014-11-25 12:51:32.0 
+0100
+++ android-platform-build-21/debian/control2016-01-08 20:15:41.0 
+0100
@@ -44,6 +44,7 @@
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: aapt (<= 21-2)
 Description: Android utility library for cross-platform tools
  Library providing utility functions to Android related tools. This is needed
  purely to get various Android utilities working.

Bug#810474: cups: Unable to clear print queue

[David Christensen]

Package: cups
Version: 1.5.3-5+deb7u6
Severity: normal

Dear Maintainer,

If I print a large job from an application and then discover it is bad,
I am unable to stop the job and clear the print queue. 

-  If I power down the printer, the print job restarts when I power
up the printer.

- If I power down the printer and computer, the print job restarts when
I power them up.

- If I go to Xfce -> Settings -> Printing, right click on my printer
and choose View Print Queue, I see nothing.

- If I issue the command 'cancel -a' as root, the job still prints.


David


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

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

Versions of packages cups depends on:
ii  adduser3.113+nmu3
ii  bc 1.06.95-2+b1
ii  cups-client1.5.3-5+deb7u6
ii  cups-common1.5.3-5+deb7u6
ii  cups-filters   1.0.18-2.1+deb7u2
ii  cups-ppdc  1.5.3-5+deb7u6
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.16
ii  ghostscript9.05~dfsg-6.3+deb7u2
ii  libavahi-client3   0.6.31-2
ii  libavahi-common3   0.6.31-2
ii  libc-bin   2.13-38+deb7u8
ii  libc6  2.13-38+deb7u8
ii  libcups2   1.5.3-5+deb7u6
ii  libcupscgi11.5.3-5+deb7u6
ii  libcupsimage2  1.5.3-5+deb7u6
ii  libcupsmime1   1.5.3-5+deb7u6
ii  libcupsppdc1   1.5.3-5+deb7u6
ii  libdbus-1-31.6.8-1+deb7u6
ii  libgcc11:4.7.2-5
ii  libgnutls262.12.20-8+deb7u3
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u4
ii  libkrb5-3  1.10.1+dfsg-5+deb7u4
ii  libldap-2.4-2  2.4.31-2+deb7u1
ii  libpam0g   1.1.3-7.1
ii  libpaper1  1.1.24+nmu2
ii  libslp11.2.1-9+deb7u1
ii  libstdc++6 4.7.2-5
ii  libusb-1.0-0   2:1.0.11-1
ii  lsb-base   4.1+Debian8+deb7u1
ii  poppler-utils  0.18.4-6
ii  procps 1:3.3.3-3
ii  ssl-cert   1.0.32+deb7u1

Versions of packages cups recommends:
ii  avahi-daemon   0.6.31-2
ii  colord 0.1.21-1
ii  foomatic-filters   4.0.17-1
ii  ghostscript-cups   9.05~dfsg-6.3+deb7u2
ii  printer-driver-gutenprint  5.2.9-1

Versions of packages cups suggests:
ii  cups-bsd   1.5.3-5+deb7u6
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20120523-1
ii  hplip  3.12.6-3.1+deb7u1
ii  printer-driver-hpcups  3.12.6-3.1+deb7u1
ii  smbclient  2:3.6.6-6+deb7u5
ii  udev   175-7.2

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, lpd, socket, usb, snmp, dnssd

Bug#640376: dh-autoreconf: Please handle gtk-doc-tools correctly

[Andrey Gursky]

Hi,

I tried to package locally the gtksourceview3 library from git. It
failed due to similar reasons. And this is not the only package
suffering from missing enhancement to dh_autoreconf. Additionally
intltoolize should also be added [1].

Or maybe instead of dh_autoreconf something like dh_autogen with
different options should be introduced in Debian?

Regards,
Andrey

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741703

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Scott Kitterman]

On January 8, 2016 12:26:24 PM EST, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> As is currently being discussed on #debian-devel, the git:// protocol
>is
>> insecure, but is what is normally used in Vcs-git fields in Debian
>packages.
>
>> For git, it would be far better to used https://, but I don't think
>policy is
>> completely clear that is OK since it says to use the "version control
>system's
>> conventional syntax".  For git, that's arguably git:// even though
>it's a
>> security risk.
>
>> Please see the attached patch.  Although the diff is slightly noisy,
>the patch
>> only adds one word.
>
>I would rather add a new sentence saying that ideally the URL should
>use a
>secure transport mechanism.  Right now, with this rephrasing, it sort
>of
>implies that if there's no encrypted transport, you shouldn't use this
>field.  It used to be that serving Git over HTTPS was a huge pain and
>disabled a bunch of features, so some folks may just not have bothered
>to
>ever set that up.

Sounds good to me.  My proposal was an attempt at a minimal change.  I think 
what you're suggesting is better.

Scott K

Bug#810388: https-everywhere: two rulesets for DebConf

[Jakub Wilk]

Source: https-everywhere
Version: 5.1.1-2
Severity: minor

There are two, mostly equivalent, rulesets for DebConf:

DebConf.org.xml
DebConf.xml

This is confusing...

--
Jakub Wilk

Bug#805769: netbeans: Startup stuck on "Loading modules..."

[Mu]

This is embarrasing :) Last time I checked still was not available.

I,ve been trying and I am afraid that that my tests are difficult to
interpret, since the error seems a bit random.

I have tried the importation several times with:

$ rm -rf 8.0.2/ 8.1/ ; netbeans

(I am importing configuration from 7.3)

For several times the program started normally and the projects were
correctly imported.

Then I remembered I had problems with the 8.1 version of netbeans I
downloaded from the webpage. I have tried that version and it got stuck on
"Loading modules".

The strange thing is that after that, any try I have done on the debian
version got stuck on "Starting modules". If I kill the process and try
without deleting the configuration directory, it starts normally and the
projects are imported.

I think it has to be related to something netbeans did in my projects
directory, but I can't figure out what because I don't have those files
versioned. Anyway, the bug is no longer a big deal to me, since I could
import my projects and I can run netbeans as long as I don't delete the
config directory.

2016-01-08 12:23 GMT+01:00 Markus Koschany :

> Am 08.01.2016 um 12:08 schrieb Mu:
> > I have testing on my computer, so I haven't received the update yet. I
> > think I can access to a computer with sid, and I will post the results
> > as soon as I can.
>
> Netbeans 8.1 is now available in testing.
>
> Markus
>
>
>

Bug#810387: openocd: please switch to libftdi1

[Paul Fertser]

Hello,

> If openocd supports the new libftdi1 library, please consider switching
> the build-depends from libfdti-dev to libftdi1-dev.

OpenOCD supports the new library, so the transition should be
painless.

Bug#809957: neverball: FTBFS with libpng16

[Markus Koschany]

On Tue, 05 Jan 2016 00:08:01 +0100 t...@debian.org wrote:
> Source: neverball
> Severity: important
> User: lib...@packages.debian.org
> Usertags: libpng16-transition
> 
> Dear neverball maintainer,
> 
> Currently we are preparing the transistion of libpng1.2 to libpng1.6.
> The transistion bug is #650601.
> 
> A rebuilt of all packages depending on libpng-dev and libpng12-dev
> has been done. The result with buildlogs can be found here:
> https://libpng.sviech.de/
> 
> neverball FTBFS during this rebuild. The buildlog is available at
> https://libpng.sviech.de/neverball.build

I think I have found the reason why Neverball fails to build from source
with libpng16. Apparently libpng-config was moved into a separate
package libpng16-devtools but libpng16-dev neither depends or recommends
this new package. However Neverball requires this tool for getting
information about installed png libraries, especially linking information.

I am not sure why this change has been made and I don't think it is very
useful. In my opinion libpng16-dev should either depend on
libpng16-devtools or the binaries should be moved into libpng16-dev
again. Just for the record: libsdl2-dev also includes sdl2-config which
I think is correct.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#810391: qemu-system-x86: Windows and Linux guests randomly die on multiple machines with no errors logged

[Aaron C. de Bruyn]

Package: qemu-system-x86
Version: 1:2.1+dfsg-12+deb8u4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I have ~25 Debian servers running at various clients.  They all run identical 
hardware with varying amounts of memory.
The machines virtualize several Windows servers and several Linux servers.
Several of these customers should probably get additional physical servers or 
more memory because they are adding more VMs, but they don't want to just yet.  
Consequently several of these systems are tight on memory.

On systems where memory starts to get tight (say under ~1 GByte on a 48 Gbyte 
system), one or more guests will randomly die with no information printed in 
syslog.  This usually occurs once or twice during a 24-hour period.
It doesn't seem to matter if the guest is running virtio drivers or SATA/IDE 
drivers.

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

Running 'echo 3 > /proc/sys/vm/drop_caches' from cron every minute seems to 
delay the issue from a few times per day to a few times every 3-4 days.

   * What was the outcome of this action?
   * What outcome did you expect instead?

If the host was truly out of memory, I would expect to see OOM-killer picking a 
process to die, or possibly errors from libvirt/qemu about servers getting 
killed.

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


-- 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/16 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 qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20141004.86285d1-1
ii  libaio1 0.3.110-1
ii  libasound2  1.0.28-1
ii  libbluetooth3   5.23-2+b1
ii  libbrlapi0.65.2~20141018-5
ii  libc6   2.19-18+deb8u1
ii  libcurl3-gnutls 7.38.0-4+deb8u2
ii  libfdt1 1.4.0+dfsg-1
ii  libgcc1 1:4.9.2-10
ii  libglib2.0-02.42.1-1
ii  libgnutls-deb0-28   3.3.8-6+deb8u3
ii  libiscsi2   1.12.0-2
ii  libjpeg62-turbo 1:1.3.1-12
ii  libncurses5 5.9+20140913-1+b1
ii  libpixman-1-0   0.32.6-3
ii  libpng12-0  1.2.50-2+deb8u1
ii  libpulse0   5.0-13
ii  librados2   0.80.7-2
ii  librbd1 0.80.7-2
ii  libsasl2-2  2.1.26.dfsg1-13+deb8u1
ii  libsdl1.2debian 1.2.15-10+b1
ii  libseccomp2 2.1.1-1
ii  libspice-server10.12.5-1+deb8u2
ii  libssh2-1   1.4.3-4.1
ii  libtinfo5   5.9+20140913-1+b1
ii  libusb-1.0-02:1.0.19-1
ii  libusbredirparser1  0.7-1
ii  libuuid12.25.2-6
ii  libvdeplug2 2.3.2+r586-1
ii  libx11-62:1.6.2-3
ii  libxen-4.4  4.4.1-9+deb8u3
ii  libxenstore3.0  4.4.1-9+deb8u3
ii  qemu-system-common  1:2.1+dfsg-12+deb8u4
ii  seabios 1.7.5-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.1+dfsg-12+deb8u4

Versions of packages qemu-system-x86 suggests:
ii  kmod 18-3
pn  ovmf 
ii  samba2:4.1.17+dfsg-2
pn  sgabios  
pn  vde2 

-- no debconf information

Bug#771838: [liblensfun0] Please package new upstream version

[Pino Toscano]

Hi,

In data venerdì 8 gennaio 2016 14:41:58, Torsten Bronger ha scritto:
> Pino Toscano writes:
> 
> > [...]
> >
> > In data domenica 15 novembre 2015 20:55:54, Torsten Bronger ha scritto:
> >
> > [...]
> >
> >> We suggest to count the database format version in the Debian
> >> package name as it is common for libraries: lensfun-data1,
> >> lensfun-data2, etc.
> >
> > Hm, on a Debian system you don't have multiple versions of lensfun
> > though, i.e. only one liblensfunN, so that version has just one
> > version of the data; hence, if I make liblensfunN x.y.z depend on
> > liblensfun-data >= x.y.z, that should ensure the library has the
> > data it needs, no?
> 
> If there is only one ABI version of lensfun installed, this would
> work.  If you want to make possible that liblensfunM can be
> installed locally parallely to liblensfunN, you need to put the
> database format version (not the ABI number) in the -data package.

I see, although often is the database format version going to be bumped?
Say only between lensfun x.y.z to x.(y+1), or even for .z releases?
My only concern about versioning the -data package is that every time
it needs to be bumped, the source (liblensfun) has to pass the NEW
queue in Debian (which means review by ftp-masters, and can take up to
days); OTOH I could live with that. The only thing I would do is naming
it like liblensfun-data-vN though, as what you suggested earlier may
imply it is providing a shared library liblensfun-data.so.N.

Another solution could be double versioning the data, by library SONAME
and database version, e.g. /usr/share/lensfun_$ABI/version_$DB/, which
could allow to have liblensfunN and liblensfunN-data,
parallel-installable aside each other SOVERSION.

(Btw, are you an upstream developer? If so, may I contact you outside
of this bug for a couple of things to be fixed?)

Thanks,
-- 
Pino Toscano

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

Bug#790350: [Pkg-haskell-maintainers] Bug#790350: ghc-mod: Crush problem of ghc-mod

[Daniel Gröber]

On Sun, Aug 16, 2015 at 11:56:58AM +0200, Sven Bartscher wrote:
> Can anyone still reproduce this somewhere? I just tried it in Debian
> stretch and couldn't reproduce it.

I can't reproduce it anymore either. I think it was a bug in GHC and
7.10 seems to have fixed it.

--Daniel

Bug#810477: android-platform-frameworks-base: diff for NMU version 21-2.1

[Tobias Frost]

Package: android-platform-frameworks-base
Version: 21-2
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for android-platform-frameworks-base (versioned as 
21-2.1). The diff
is attached to this message.

Regards.
diff -Nru android-platform-frameworks-base-21/debian/changelog 
android-platform-frameworks-base-21/debian/changelog
--- android-platform-frameworks-base-21/debian/changelog2014-12-02 
14:43:13.0 +0100
+++ android-platform-frameworks-base-21/debian/changelog2016-01-08 
20:26:33.0 +0100
@@ -1,3 +1,12 @@
+android-platform-frameworks-base (21-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update BD to libpng-dev (Closes: #810166)
+  * Rebuild against android-libhost, with versioned depend to ensure that the
+GCC-5 rebuilt version is used. (Closes: #808899)
+
+ -- Tobias Frost   Fri, 08 Jan 2016 16:42:36 +0100
+
 android-platform-frameworks-base (21-2) unstable; urgency=low
 
   * add versions to shlibs so dh can do dep detection
diff -Nru android-platform-frameworks-base-21/debian/control 
android-platform-frameworks-base-21/debian/control
--- android-platform-frameworks-base-21/debian/control  2014-11-26 
15:20:33.0 +0100
+++ android-platform-frameworks-base-21/debian/control  2016-01-08 
20:22:25.0 +0100
@@ -6,11 +6,11 @@
 Build-Depends: debhelper (>= 9.0.0~),
android-system-dev,
android-libcutils-dev (>= 21-5~),
-   android-libhost-dev,
+   android-libhost-dev (>= 21-4.1~),
android-liblog-dev,
android-libutils-dev,
libexpat1-dev,
-   libpng12-dev,
+   libpng-dev,
zlib1g-dev
 Standards-Version: 3.9.6
 Homepage: https://android.googlesource.com/platform/frameworks/base
diff -Nru android-platform-frameworks-base-21/debian/patches/libpng16.patch 
android-platform-frameworks-base-21/debian/patches/libpng16.patch
--- android-platform-frameworks-base-21/debian/patches/libpng16.patch   
1970-01-01 01:00:00.0 +0100
+++ android-platform-frameworks-base-21/debian/patches/libpng16.patch   
2016-01-08 20:48:28.0 +0100
@@ -0,0 +1,61 @@
+--- a/tools/aapt/Images.cpp
 b/tools/aapt/Images.cpp
+@@ -11,6 +11,7 @@
+ #include 
+ #include 
+ 
++#include 
+ #include 
+ 
+ #define NOISY(x) //x
+@@ -18,7 +19,7 @@
+ static void
+ png_write_aapt_file(png_structp png_ptr, png_bytep data, png_size_t length)
+ {
+-status_t err = ((AaptFile*)png_ptr->io_ptr)->writeData(data, length);
++status_t err = ((AaptFile*)png_get_io_ptr(png_ptr))->writeData(data, 
length);
+ if (err != NO_ERROR) {
+ png_error(png_ptr, "Write Error");
+ }
+@@ -89,8 +90,13 @@
+ if (color_type == PNG_COLOR_TYPE_PALETTE)
+ png_set_palette_to_rgb(read_ptr);
+ 
+-if (color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8)
++if (color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8) {
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  png_set_expand_gray_1_2_4_to_8(read_ptr);
++#else
+ png_set_gray_1_2_4_to_8(read_ptr);
++#endif
++}
+ 
+ if (png_get_valid(read_ptr, read_info, PNG_INFO_tRNS)) {
+ //printf("Has PNG_INFO_tRNS!\n");
+@@ -109,7 +115,7 @@
+ png_read_update_info(read_ptr, read_info);
+ 
+ outImageInfo->rows = (png_bytepp)malloc(
+-outImageInfo->height * png_sizeof(png_bytep));
++outImageInfo->height * sizeof(png_bytep));
+ outImageInfo->allocHeight = outImageInfo->height;
+ outImageInfo->allocRows = outImageInfo->rows;
+ 
+@@ -573,7 +579,7 @@
+  image->info9Patch.paddingTop, 
image->info9Patch.paddingBottom));
+ 
+ // Remove frame from image.
+-image->rows = (png_bytepp)malloc((H-2) * png_sizeof(png_bytep));
++image->rows = (png_bytepp)malloc((H-2) * sizeof(png_bytep));
+ for (i=0; i<(H-2); i++) {
+ image->rows[i] = image->allocRows[i+1];
+ memmove(image->rows[i], image->rows[i]+4, (W-2)*4);
+@@ -984,7 +990,7 @@
+ unknowns[0].data = NULL;
+ unknowns[1].data = NULL;
+ 
+-png_bytepp outRows = (png_bytepp) malloc((int) imageInfo.height * 
png_sizeof(png_bytep));
++png_bytepp outRows = (png_bytepp) malloc((int) imageInfo.height * 
sizeof(png_bytep));
+ if (outRows == (png_bytepp) 0) {
+ printf("Can't allocate output buffer!\n");
+ exit(1);
diff -Nru android-platform-frameworks-base-21/debian/patches/series 
android-platform-frameworks-base-21/debian/patches/series
--- android-platform-frameworks-base-21/debian/patches/series   2014-10-02 
00:52:34.0 +0200
+++ android-platform-frameworks-base-21/debian/patches/series   2016-01-08 
20:32:41.0 +0100
@@ -2,3 +2,4 @@
 libs_androidfw_makefile.patch
 tools_aapt_makefile.patch
 fix_expat_header_path.patch
+libpng16.patch

Bug#806670: fixed in openscad 2015.03-2+dfsg-1

[Marius Kintel]

@chrysn,

We were just talking about whether we should make an official 2015.03-3 
release, or just go to 2016.02 or smth.. (which would allow us to add one or 
two new features).
In terms of Debian maintenance, are there any huge differences between those 
two strategies?

 -Marius

Bug#810481: puppet-module-puppetlabs-ntp: none

[Bernd Schatz]

Package: puppet-module-puppetlabs-ntp
Severity: normal

Dear Maintainer,

Using the option logfile in the class ntp leads to a syntax error
in the ntp.conf files of the clients.(Jessie 8.2).

The relevant line in the config is
logfile = /var/log/ntp.log
but should be
logfile /var/log/ntp.log


Solution: remove the "=" in
/usr/share/puppet/modules.available/puppetlabs-ntp/templates/ntp.conf.erb
diff
/usr/share/puppet/modules.available/puppetlabs-ntp/templates/ntp.conf.erb 
~/ntp.conf.erb
47c47
< logfile = <%= @logfile %>
---
> logfile <%= @logfile %>




For instance, create file /etc/puppet/manifests/site.pp with
*
On puppet master
class { '::ntp':
  servers => [ '0.pool.ntp.org', '1.pool.ntp.org', '2.pool.ntp.org',
'3.pool.ntp.org', ],
  logfile => '/var/log/ntp.log',
}
include '::ntp'
*

update client with  "puppet agent -t"  and check result with

*
root@euwe:~# service ntp status
● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (running) since Fr 2016-01-08 22:03:04 CET; 2s ago
  Process: 13904 ExecStop=/etc/init.d/ntp stop (code=exited,
status=0/SUCCESS)
  Process: 13914 ExecStart=/etc/init.d/ntp start (code=exited,
status=0/SUCCESS)
   CGroup: /system.slice/ntp.service
   └─13923 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 124:130

Jan 08 22:03:04 euwe ntpd[13923]: syntax error in /etc/ntp.conf line 28,
column 11
Jan 08 22:03:04 euwe ntpd[13923]: Listen and drop on 0 v4wildcard
0.0.0.0 UDP 123
Jan 08 22:03:04 euwe ntp[13914]: Starting NTP server: ntpd.
Jan 08 22:03:04 euwe ntpd[13923]: Listen and drop on 1 v6wildcard :: UDP 123
Jan 08 22:03:04 euwe ntpd[13923]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jan 08 22:03:04 euwe ntpd[13923]: Listen normally on 3 eth0
192.168.1.223 UDP 123
Jan 08 22:03:04 euwe ntpd[13923]: Listen normally on 4 lo ::1 UDP 123
Jan 08 22:03:04 euwe ntpd[13923]: Listen normally on 5 eth0
fe80::1e6f:65ff:feaf:abf UDP 123
Jan 08 22:03:04 euwe ntpd[13923]: peers refreshed
Jan 08 22:03:04 euwe ntpd[13923]: Listening on routing socket on fd #22
for interface updates



-- 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/6 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)


greets
  Bernd

Bug#805030: libssh: newer upstream versions?

[Willi Mann]

Hi Chris,

Am 2016-01-08 um 07:57 schrieb Chris Knadle:
> Willi Mann:
>>
>> Could you make the git repo somewhere available?
> 
>git clone git://git.coredump.us/debian/libssh.git
> 
> I use git-buildpackage and pristine-tar, and the clone will contain all that
> plus default to the '0.7.2' branch that contains all the commits I've done
> on the package.

I think it would be good to rebase your work onto the repository in
collab-maint. Do you already have write access there? If not, could you
apply for it?

https://lists.debian.org/debian-devel-announce/2012/01/msg6.html

In the meantime, it is probably better to work with your repository.
Once I will make commits, I'll send you a link to my clone of the repo.

Bye
Willi

Bug#810476: RM: garmindev -- ROM; Lacks support for libusb 1.0 and is no longer developed upstream

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove garmindev from the archive, it lacks support for libusb
1.0 (#810413) and is no longer developed upstream.

Kind Regards,

Bas

Bug#810478: konsole: can't start konsole

[Cosimo Morelli]

Package: konsole
Version: 4:15.08.3-1
Severity: critical
Justification: breaks the whole system

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

when I try to open konsole this message appears:

Cannot load library /usr/lib/x86_64-linux-gnu/libkdeinit5_ksystraycmd:
(/usr/lib/x86_64-linux-gnu/libkdeinit5_ksystraycmd.so

also the system freezes and I need to open a terminal and kill drkonqi



- -- 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/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages konsole depends on:
ii  konsole-kpart   4:15.08.3-1
ii  libc6   2.21-6
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configgui55.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5notifyconfig5 5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5windowsystem5 5.16.0-1
ii  libkf5xmlgui5   5.16.0-1
ii  libqt5core5a5.5.1+dfsg-12
ii  libqt5gui5  5.5.1+dfsg-12
ii  libqt5widgets5  5.5.1+dfsg-12
ii  libstdc++6  5.3.1-5

konsole recommends no packages.

konsole suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWkBo6AAoJEF8PzE63GYeQN/UP+gJXrpZvnWYvzIqaEb5UPWED
mdZTi/DPn5n6q/Fr4zSNoXP7Eg94rUaLEVVHLfopSSARsQGHv82xwo9HRAIChPSS
hd1z8MZu28M/1RNUjgO5kXdqHYU9hvj0ZRk4qUK2tuAi0TYSoqql8cy2bFPSdSOg
E9Cn+aA5HVhWJ/hJhS9RtgOrgaZPkMCgAdRboJJs4VSQlvpOuK2TzPB70x2w525T
tf++RbrpsFRPsMvh5n7hLWjr/PKbJWgXhQfmmhaQqUfXj8dfSEAh2rbruNtVI5SQ
OsuiKmob/fr1RmoFQHvwnrVerCW88Lkih1dTA2t0/68mb0GcB4tqzi/RTqwnyCFZ
oRjRhwFJmXxRM7ogfK32Gv67P74+DMX9nj/gJBL96zC/GNtDj1QQWWBlW2OAS6wq
fWHgG98wrRXdYXNo7pvlNmMtudqtXwKloKyPKkP/WobZnkukHabQDP+6H4IRqsUp
Np/tRS67+Yb6GorE0nbYMxcqwX2pkvepfKEfYf6LEc2hUmaMxSwefXsOJ83j4/DC
YM9OS8Q3/RZg3XdhDbfyQgO3iuu8mRhE2jqWqAvvPYl2FwxhRXHOm1jZjQO32Yc+
LghLLJ0ftDLnRipxwq33IWlXj0PbQXtqpcKUpf/2VZ/tURJN4eBTJyqoQEF9MsXU
YQNLT8Zf9EW4bSOvbLKl
=bmVO
-END PGP SIGNATURE-

Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule

[Blake Miner]

Bump.  Any another thoughts on this bug?  It's hard to tell if this is a
usb-modeswitch bug (i.e. a problem with usb_modeswitch_dispatcher) or if
this is a problem with the udev rule itself (a usb-modeswitch-data bug).

Again, to summarize, I think that the non-working rule triggers when the
USB interface is attached and executes the command: /lib/udev/usb_modeswitch
'2-1/2-1:1.0'.  The working rule triggers when the device itself is
attached and executes the command: /lib/udev/usb_modeswitch '/2-1'.

/lib/udev/usb_modeswitch '2-1/2-1:1.0' does not work.
/lib/udev/usb_modeswitch '/2-1' works just fine.

Thanks.

On Fri, Nov 20, 2015 at 1:37 PM Blake Miner  wrote:

> ​Josh,
>
> Thanks for your response.
>
> Here's the thing... the udev rule is triggering, and systemd is running
> the /lib/udev/usb_modeswitch program, which ends up running
> usb_modeswitch_dispatcher.  All is good there, but the problem (I think) is
> as follows:
>
> The working udev rule:
> * Triggered when the USB device is attached
> * Ends up executing /lib/udev/usb_modeswitch '/2-1'
>
> The non-working catch-all udev rule:
> * Triggered when the USB device **interface** is attached
> * Ends up executing /lib/udev/usb_modeswitch '2-1/2-1:1.0'
>
> I don't understand the inner-workings of the usb_modeswitch_dispatcher,
> but why does one rule work and not the other?
>

Bug#803822: gst-libav1.0: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Sebastian,

Thanks for your quick reply.

On 08.01.2016 13:49, Sebastian Dröge wrote:
> I had no chance of looking closer yet,

That's unfortunate.

> testing will be easier once there are packages though.

How so? The replacements of the deprecated APIs have been present
for years, so you can test the patch with any recent version.

Once the new version is packaged, it will be a bit late to start
investigating this bug, as gst-libav1.0 will fail to build then.

Best regards,
Andreas

Bug#810479: RFP: paxrat -- PaX exception daemon for Debian packages

[bancfc]

Package: wnpp
X-Debbugs-CC: deskt...@secure-os.org

* Package name: paxrat
   Version : 1
   Upstream Author : David McKinney 
* URL   : https://github.com/subgraph/paxrat
* License : GPLv3
   Programming Lang: Go
   Description  : PaX exception daemon for Debian packages.

The newly packaged grsec kernel makes it easier for anyone to run a more 
secure kernel. However some major packages like Iceweasel/Tor Browser, 
JIT interpreters and main components of Gnome and KDE require PaX 
exceptions because they are not compatible with memory protection 
features of the enhanced kernel.


Paxrat from the SubgraphOS project is a daemon that maintains and 
applies rules from an exception list. It has dpkg hooks for taking care 
of binaries even when updated. [2]


Paxrat is implemented in GoLang and is simple to use.

Also a Grsecurity kernel maintainer is interested to have paxrat 
packaged. [1]


Please consider packaging it forJessie-backports too to compliment the 
backported linux-grsec package for stable installations.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487
[2] 
https://github.com/subgraph/paxrat/blob/master/etc/apt/apt.conf.d/70paxrat

Bug#808832: fwupd: polkit rules file uses "wheel" grou which doesn't exist in debian

[Mario Limonciello]

I suppose because of #808833 this isn't as important, but I'm including
a patch in next upload.

On 12/23/2015 08:42 AM, Laurent Bigonville wrote:
> Package: fwupd
> Version: 0.6.0-1
> Severity: important
>
> Hi,
>
> The polkit rule file uses the "wheel" group which doesn't exit in
> debian. The "sudo" group should probably be used instead.
>
> Cheers,
>
> Laurent Bigonville
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages fwupd depends on:
> ii  libappstream-glib8 0.5.5-1
> ii  libarchive13   3.1.2-11+b1
> ii  libassuan0 2.4.2-1
> ii  libc6  2.21-4
> ii  libdfu10.6.0-1
> ii  libefivar0 0.21-1
> ii  libfwup0   0.5-1
> ii  libfwupd1  0.6.0-1
> ii  libgcab-1.0-0  0.6-1
> ii  libgdk-pixbuf2.0-0 2.32.3-1
> ii  libglib2.0-0   2.46.2-1
> ii  libgpg-error0  1.21-1
> ii  libgpgme11 1.6.0-1
> ii  libgudev-1.0-0 230-2
> ii  libgusb2   0.2.8-1
> ii  libpolkit-gobject-1-0  0.105-14
> ii  libsoup2.4-1   2.52.2-1
> ii  libsqlite3-0   3.9.2-1
> ii  libusb-1.0-0   2:1.0.20-1
>
> Versions of packages fwupd recommends:
> ii  fwupdate  0.5-1
>
> fwupd suggests no packages.
>
> -- no debconf information
>

-- 
*Mario Limonciello*
*Dell*| Client Software Group
*office*+1 512 723 0582

Bug#810164: perl-modules-5.22: Unversioned Breaks against perl-modules should be a Conflict

[Adam Conrad]

On Fri, Jan 08, 2016 at 12:22:50PM +0200, Niko Tyni wrote:
> On Wed, Jan 06, 2016 at 11:06:35PM -0700, Adam Conrad wrote:
> 
> > 1) The "hint" for complete replacement of A with B for high level
> >dpkg frontends is an unversioned Conflicts/Replaces pair.
> > 2) Virtual packages are defined as a Provides, or Provides/Conflicts
> >if they shouldn't be installed together, or Provides/Conflicts
> >and Replaces if they have file overlaps.
> 
> is very helpful.
> 
> The general impression I have is that as Conflicts imposes much
> stronger constraints on upgrade ordering, it should be used sparingly.
> To that end, I'm wondering if we should have perl-modules-5.22
>  Breaks: perl-modules (<< 5.22.0~)
>  Provides: perl-modules
> but leave the Replaces out, effectively dropping the (currently broken)
> "hint" for complete replacement and letting the dpkg frontends to figure
> that out themselves. Do you have an opinion about that?

The only hint that frontends are guaranteed to understand for swapping
packages is Conflicts/Replaces, apt itself will suggest removal of
packages to try to reach your upgrade goal, but more cautious frontends
like unattended-upgrades or update-manager will only allow removals in
that one specific case, to avoid unintentional removals.

> I see you've filed this at severity:important. While I'm not disputing
> that, is there some specific trouble this is causing?

I filed it as important because it stalls upgrades with the above-
mentioned "cautious" frontends and forces user intervention with apt
or dselect/aptitude to get the desired result.

Given the above, I think the only reasonable solution right now is to
move your Breaks to a Conflicts.

As a side note, you may also want to make your Provides versioned, as
having it unversioned has suddenly swapped meaning for dependencies
such as:

 Depends: perl-modules (>= 5.10) | libcgi-pm-perl (>= 3.35)

An unversioned Provides is evaluated as version 0:0.0, which means an
upgrade that's removing perl-modules will pull in libcgi-pm-perl, even
though that shouldn't be necessary.  A versioned Provides would fix
that.

... Adam

Bug#655741: apcupsd: SNMP driver crash with AP9606 management card

[Tim Bagot]

I no longer see this bug in version 3.14.12-1.1. I suspect it has
been fixed by other changes to the snmplite driver upstream.

-- 
Tim Bagot

Bug#803869: vtk6: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Anton,

On 08.01.2016 06:35, Anton Gladky wrote:
> Hi Andreas, I uploaded it 20/12/2015. So we
> need just to wait for a FTP-masters, to get it
> approved.

Yes, I realized that when looking at the package tracker yesterday.
I'm just saying that a short mail informing me about the upload
(and tagging the bug pending) would have been a nice Christmas
present for me. ;)

On a related note: What are your plans for paraview (#803852)?

Best regards,
Andreas

Bug#803833: libavg: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Dimitri,

Thanks for your fast reply.

On 08.01.2016 13:41, Dimitri John Ledkov wrote:
> All my packages should be marked as LowNMU and I expect and hope for
> everyone to fix and upload things =)
> 
> So instead of filing a bug report and/or attaching a patch, you could
> have simply uploaded this build fix =)

If I were a DD, that is. Though, of course, I could ask you to sponsor
such an upload. ;)

> Please upload it, otherwise I shall test and upload it at some point
> in the future when it becomes critical...

I guess that should work, but I certainly would appreciate an upload
before this gets critical: That means less stress for you, me and the
Release Team.

Best regards,
Andreas

Bug#810033: package resubmit request

[Busch, Keith]

I received notification the package was rejected as my email was not a user on 
mentors.debian.net. I've signed up on this site today, so I think it's safe to 
resubmit.

Bug#803849: openscenegraph: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Manuel,

Thanks for your quick reply.

On 08.01.2016 14:31, Manuel A. Fernandez Montecelo wrote:
> I think that Alberto was planning since many months ago to upload
> 3.4.0, and he mentioned it the last time that we met (about 3 weeks
> ago), but different issues (like the big GCC-5/C++11 transition, and
> smaller transitions after that) prevented him from doing that at the
> times when he had the time to prepare the whole move/transition.  (OSG
> releases usually require SONAME/VERSION bumps if not source changes,
> even sometimes between -RC and final releases).

OK.

> openscenegraph is not a leaf package, but much further behind in
> priority than giflib, gdal, xine or ffmepg (and openscenegraph depends
> on a vast number of basic libraries), so in the end the transitions of
> all of these take precedence.  3.4.0 will probably require a
> transition for which maybe all rdeps are not ready, so would be a
> problem for the more important transitions that might get entangled
> with.

I see, it's better not to entangle transitions.

> I don't know if the fact of not including the patch of ffmpeg 2.9/3.0
> was an oversight or on purpose because the plan to upload 3.4, or if
> upstream patches take care of this.  If you plan to start the
> transition of ffmpeg imminently, maybe at this point it's better to
> include the patch than to start a transition also with OSG-3.4.0.

Well, this is imminent in Debian timescales, that is this month,
but not this week. ;)

> ... all of this is subject to Alberto's opinion, who is better
> informed about all of this and follows upstream development closer.  I
> just wanted to chime in because he might be busy and not reply for a
> few days, and specially to explain that moving to 3.4 might not be
> straightforward.

Thanks, this is much appreciated.

Best regards,
Andreas

Bug#807853: k3b: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Pino,

Thanks for your quick reply.

On 08.01.2016 18:12, Pino Toscano wrote:
> Yes, I've seen the patch in #807853, and a couple of review requests on
> KDE's reviewboard.

Could you please post links to upstream discussion about this or mark
the bug as forwarded?

> Let me take this opportunity to "reverse the issue": is your upstream
> aware that the continuous API breaks in each new stable series only
> waste time on the users' side?

I sense frustration in these words, but let's get the facts straight:
 * The last four stable series (2.5.*-2.8.*) didn't break the API.
 * Adapting to the new APIs is no waste of time, rather maintenance cost,
   also improving the API using program in the process, as the old APIs
   were deprecated for a reason.

And yes, the upstream developers are aware of that maintenance cost,
I made sure of that. Please go and read the discussion upstream [1][2].
And I can understand your frustration, after all, I'm the one who wrote
patches for all affected Debian packages.

> Just look at the affected code in k3b,
> plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp: many defines and ifdef's,
> just to make the very same code do the very same job, nothing less and
> nothing more.

I'm well aware how this file looks, as I wrote a patch for it.
And most of these ifdef's could just be removed, unless you need to
build this in ancient environments...

> Sure, if I don't get around to test your patch or to integrate eventual
> upstream fixes the plugin will need to be disabled, but honestly I don't
> see how this would be in favour of our users.

That's why I provided a patch, which should be more than enough to fix
this issue properly for any reasonably maintained software.

Best regards,
Andreas


1: https://lists.libav.org/pipermail/libav-devel/2015-July/071229.html
2: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176439.html

Bug#810475: python-astroid: Pylint 1.4.4 does not work with Astroid 1.4.x

[Johannes Weißl]

Package: python-astroid
Version: 1.4.3-1
Severity: grave
Justification: renders package unusable

The current versions of pylint (1.4.4) and python-astroid (1.4.3) in Debian
Stretch do not work together, causing errors like:

Problem importing module classes.py: cannot import name InferenceContext
E0602:...,...: ...: Undefined variable

See also
https://bitbucket.org/logilab/pylint/issues/720/problem-importing-module-classespy-cannot



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

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

Versions of packages python-astroid depends on:
ii  python-lazy-object-proxy  1.2.1-1
ii  python-logilab-common 1.0.2-1
ii  python-six1.10.0-1
ii  python-wrapt  1.8.0-5+b1
pn  python:any

python-astroid recommends no packages.

python-astroid suggests no packages.

-- no debconf information

Bug#803876: yorick-av: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Thibaut,

On 08.01.2016 03:38, Thibaut Paumard wrote:
> thanks for the heads up. The package is on its way, thanks for the patch.

Thanks for the quick upload.

> I initially wanted to include it directly upstream but I realise that I
> don't have the time to do so right know.

I see.

Best regards,
Andreas

Bug#803844: mplayer: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Miguel,

On 08.01.2016 03:02, Miguel A. Colón Vélez wrote:
> I was waiting for a clear idea of when FFmpeg was going to release to
> decide if I should patch 1.2 or just take an upstream snapshot. Most
> of the new bugs reports are fixed upstream so I will probably use an
> upstream snapshot.

Wouldn't it be better if all relevant fixes were included in the 1.2.1
release? Packaging snapshots is always a bit problematic as one never
knows when a good time for packaging the next snapshot is and upstream
doesn't really know which version of their code is used.

> Thanks for the reminder.

You're welcome and thanks for the quick reply. :)

Best regards,
Andreas

Bug#771838: [liblensfun0] Please package new upstream version

[Torsten Bronger]

Hallöchen!

Pino Toscano writes:

> In data venerdì 8 gennaio 2016 14:41:58, Torsten Bronger ha scritto:
>
> [...]
>
>> If there is only one ABI version of lensfun installed, this would
>> work.  If you want to make possible that liblensfunM can be
>> installed locally parallely to liblensfunN, you need to put the
>> database format version (not the ABI number) in the -data
>> package.
>
> I see, although often is the database format version going to be
> bumped?  Say only between lensfun x.y.z to x.(y+1), or even for .z
> releases?

Currently, Lensfun is under heavy development.  It is getting rid of
old mistakes and heading towards version 1.0.  Then, I expect things
to settle down quickly.

To answer your question, Lensfun does not have a policy for this
(yet).  So far, versioning has been without clear rules.  But there
is a proposal in the inbox of its maintainer to declare "z" as a
clear patch release, so no ABI or DB changes.  In contrast, a change
in "y" may change both.

> [...]
>
> Another solution could be double versioning the data, by library
> SONAME and database version,
> e.g. /usr/share/lensfun_$ABI/version_$DB/, which could allow to
> have liblensfunN and liblensfunN-data, parallel-installable aside
> each other SOVERSION.

This would mean quite a bit of new developing and testing.  If
possible, I'd like to avoid it.  Besides, there is a conceptual
ugliness that the DB files do not depend on the ABI version; one
would end up with duplicates.

> (Btw, are you an upstream developer? If so, may I contact you
> outside of this bug for a couple of things to be fixed?)

Yes, I am a developer, and everyone may contact me directly for
Lensfun issues, or use the bug tracker, for that matter.

Regards,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de

Bug#810480: freefoam: Uploader Gerber van der Graaf is no longer maintaining this package

[Tobias Frost]

Source: freefoam
Severity: normal

Was in contact with Gerber about his involvement in Debian and he told me that
he'll find no time to maintain the package. Please remove him from the Uploader
field with your next upload.

Thanks

-- 
tobi

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

Kernel: Linux 4.3.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#803797: amarok: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Diane,

On 08.01.2016 08:47, Diane Trout wrote:
> No I hadn't seen the previous bug report. Thank you for emailing me directly.

Thanks for your quick reply.

> I just looked at your patch and it seems pretty simple

Yes, they are mostly search and replace, though the patch also fixes memory
leaks. (Previously the correct way to free a frame was avcodec_free_frame,
not av_free.)

> though I'd ike to build and run it first.

That's always a good idea.

> Could you point me to any ffmpeg documentation about the deprecations in 2.9

To prevent any misunderstanding: This patch is not about deprecations introduced
in 2.9, but about deprecations from the 2.0 era. The APIs deprecated back then
got removed now. These API changes are documented in the APIchanges document 
[1].
(It's installed in ffmpeg-doc, as well.)
Also there is a Libav website about the (similar) changes in Libav 12 [2].

> If it works I should be able to upload a new version of amarok over the 
> weekend.

That would be great.

> I'm not sure if upstream is aware. They're in beta for a new release so I'll 
> need to go look at their new version. I'll try to do that over the weekend as 
> well.

Thanks.

Best regards,
Andreas


1: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/tree/doc/APIchanges
2: https://wiki.libav.org/Migration/12

Bug#803846: opal: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Eugen,

On 08.01.2016 09:12, Eugen Dedu wrote:
> The release have not happened and will not happen certainly this month.
> So I will very soon apply the path in debian.

Thanks.

Best regards,
Andreas

Bug#803828: karlyriceditor: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Martin,

On 08.01.2016 11:31, Martin Steghöfer wrote:
> severity 803828 minor

This is certainly not a minor bug, as it will be release critical in a few 
weeks.
So please change the severity back to important.

> There was no update on this bug report because I found any upload on this 
> matter
> premature. When this bug was reported, there was no transition yet [1] and the
> FFmpeg version you wanted to upgrade to hadn't even been release by upstream 
> [2].
> Nothing of this has changed so far, so I keep waiting.

I think there is a misunderstanding here. The deprecation of the APIs this patch
is about happened several years ago, so fixing the code is certainly not 
premature,
rather the contrary. The goal is that all Debian packages are ready for the new
upstream release, where these long deprecated APIs have been removed, when it
gets released. Otherwise the transition will be (a lot) less smooth.
So please don't keep waiting.

> I thank you for your patch and your initiative and hope you understand that I
> can't very well upload anything before the version we are upgrading to is 
> actually
> released and I can test its compatibility.

I don't really understand this as you can test the replacement APIs with any 
release
of the recent years. The only thing you can't test (without compiling from 
upstream
git) is whether it will build with the new version of ffmpeg. But you don't have
to test that, because I (compile-)tested my patch with upstream git.

Also I could (runtime-)test a package you prepared with upstream git, if you
let me know how to do that. ;-)

> When you first posted this report, I checked out your patch and confirmed 
> that it
> doesn't break anything.

That's great, because it means that it will work fine with the next FFmpeg 
version.

> But I can't be sure that it will fix all compatibility issues with FFmpeg 
> 2.9/3.0 -
> because it doesn't exist yet.

However, you can be reasonably sure, because I tested with upstream git and the 
time
for API breakage is over for this cycle (and was already over two months ago).

> Since I am not a DD or DM, all my uploads have to go
> through sponsors, so I really want to get it right the first time.

I'm sure Felipe Sateler (who kindly offered to help with uploads for this 
transition)
would be willing to sponsor this upload, like he did for dvbcut [1].

So as a way forward I suggest:
 * You prepare a package with this fix.
 * Optionally let me know how to test it, and I'll test with upstream git.
 * We ask Felipe to sponsor the upload.

Does that sound good to you?

Best regards,
Andreas


1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803809#20

Bug#808833: fwupd only installs rules for polkit >= 0.112

[Mario Limonciello]

Thanks, I've added some older style rules to git and will include it
with the next upload.

On 12/23/2015 08:45 AM, Laurent Bigonville wrote:
> Package: fwupd
> Version: 0.6.0-1
> Severity: important
>
> Hi,
>
> In debian, polkit in unstable is still at version 0.105 which supports
> an other kind of rule files (no javascript rules) that should be
> installed in /var/lib/polkit-1/.
>
> fwupd package should also provides a rule file for this version of
> polkit.
>
> Cheers,
>
> Laurent Bigonville
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages fwupd depends on:
> ii  libappstream-glib8 0.5.5-1
> ii  libarchive13   3.1.2-11+b1
> ii  libassuan0 2.4.2-1
> ii  libc6  2.21-4
> ii  libdfu10.6.0-1
> ii  libefivar0 0.21-1
> ii  libfwup0   0.5-1
> ii  libfwupd1  0.6.0-1
> ii  libgcab-1.0-0  0.6-1
> ii  libgdk-pixbuf2.0-0 2.32.3-1
> ii  libglib2.0-0   2.46.2-1
> ii  libgpg-error0  1.21-1
> ii  libgpgme11 1.6.0-1
> ii  libgudev-1.0-0 230-2
> ii  libgusb2   0.2.8-1
> ii  libpolkit-gobject-1-0  0.105-14
> ii  libsoup2.4-1   2.52.2-1
> ii  libsqlite3-0   3.9.2-1
> ii  libusb-1.0-0   2:1.0.20-1
>
> Versions of packages fwupd recommends:
> ii  fwupdate  0.5-1
>
> fwupd suggests no packages.
>
> -- no debconf information
>

-- 
*Mario Limonciello*
*Dell*| Client Software Group
*office*+1 512 723 0582

Bug#809957: neverball: FTBFS with libpng16

[Stephen Kitt]

On Fri, 8 Jan 2016 19:33:17 +0100, Markus Koschany  wrote:
> I think I have found the reason why Neverball fails to build from source
> with libpng16. Apparently libpng-config was moved into a separate
> package libpng16-devtools but libpng16-dev neither depends or recommends
> this new package. However Neverball requires this tool for getting
> information about installed png libraries, especially linking information.
> 
> I am not sure why this change has been made and I don't think it is very
> useful. In my opinion libpng16-dev should either depend on
> libpng16-devtools or the binaries should be moved into libpng16-dev
> again. Just for the record: libsdl2-dev also includes sdl2-config which
> I think is correct.

It's probably so that libpng16-dev can be "Multi-Arch: same", which is very
useful when cross-compiling: it becomes possible to install for example
libpng16-dev:amd64 and libpng16-dev:armhf simultaneously, which isn't the
case when libpng-config is part of the binary package.

Regards,

Stephen


pgpcBjNWS24g_.pgp
Description: OpenPGP digital signature

Bug#810470: libusb: superseded by libusb-1.0

[Sebastian Reichel]

On Fri, 08 Jan 2016 19:51:03 +0100 Aurelien Jarno  wrote:
> Source: libusb
> Version: 2:0.1.12-28
> Severity: wishlist
> 
> libusb 0.1 has been superseded by libusb 1.0, which as a new API in
> order to fix design deficiencies with USB 2.0 and 3.0 in mind. It is
> not supported upstream anymore and should be considered deprecated. We
> should avoid shipping it with stretch if possible.
> 
> 

Bug#764349: tor+http with apt-file

[Niels Thykier]

Petter Reinholdtsen:
> 
> I finally had time for some more testing of apt-file with the tor
> transport, this time using unstable, and can confirm that apt-file now
> work with apt-transport-tor.
> 

Thanks. :)

> Any plans to get the experimental version in unstable?
> 

Indeed.

 * Waiting for APT 1.2 (in unstable) which will make a world of
   difference performance-wise[0].
 * Need to sort out a few loose ends somewhere in the thread at [1].
   - Notably apt-venv needs a way to work with apt-file 3.0

Thanks,
~Niels

[0] https://lists.debian.org/debian-devel/2016/01/msg00341.html

[1] https://lists.debian.org/debian-devel/2015/12/msg00031.html





signature.asc
Description: OpenPGP digital signature

Bug#810483: RFS: helm/1.9.1-1 [ITP] -- Emacs incremental completion and selection narrowing framework

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my packaging of Helm, an alternative to
Ido that is very popular among Emacs users.  Upstream description:

Helm is incremental completion and selection narrowing framework for
Emacs. It will help steer you in the right direction when you're
looking for stuff in Emacs (like buffers, files, etc).

Helm is a fork of anything.el originally written by Tamas Patrovic
and can be considered to be its successor. Helm sets out to clean up
the legacy code in anything.el and provide a cleaner, leaner and
more modular tool, that's not tied in the trap of backward
compatibility.

* Package name: helm
  Version : 1.9.1-1
  Upstream Author : Thierry Volpiatto 
* URL : https://emacs-helm.github.io/helm/
* License : GPL-3+
  Section : lisp

My source package builds the binary packages elpa-helm and
elpa-helm-core.  This reflects the split upstream makes in publishing
Helm to MELPA, the de facto standard source of Emacs addons.

Download with dget:

dget -x http://mentors.debian.net/debian/pool/main/h/helm/helm_1.9.1-1.dsc

Or build it with gbp:

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/helm
git checkout debian/1.9.1-1
git verify-tag debian/1.9.1-1 # if you have my key
gbp buildpackage

Thanks.

Sean Whitton


signature.asc
Description: Digital signature

Bug#810295: WARNING: Serious error when reading debug info

[Andrea Stacchiotti]

Package: valgrind
Version: 1:3.11.0-1
Followup-For: Bug #810295

Confirmed also in sid, my error log is a bit different:

andreas@duelitri:~$ valgrind --tool=callgrind myprog -q 1024
==14153== Callgrind, a call-graph generating cache profiler
==14153== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==14153== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==14153== Command: myprog -q 1024
==14153==
==14153== For interactive control, run 'callgrind_control -h'.
--14153-- WARNING: Serious error when reading debug info
--14153-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
--14153-- Ignoring non-Dwarf2/3/4 block in .debug_info
--14153-- WARNING: Serious error when reading debug info
--14153-- When reading debug info from /lib/x86_64-linux-gnu/ld-2.21.so:
--14153-- Last block truncated in .debug_info; ignoring
--14153-- WARNING: Serious error when reading debug info
--14153-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so:
--14153-- Ignoring non-Dwarf2/3/4 block in .debug_info
--14153-- WARNING: Serious error when reading debug info
--14153-- When reading debug info from /lib/x86_64-linux-gnu/libm-2.21.so:
--14153-- Last block truncated in .debug_info; ignoring
--14153-- WARNING: Serious error when reading debug info
--14153-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
--14153-- Ignoring non-Dwarf2/3/4 block in .debug_info
--14153-- WARNING: Serious error when reading debug info
--14153-- When reading debug info from /lib/x86_64-linux-gnu/libc-2.21.so:
--14153-- Last block truncated in .debug_info; ignoring



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

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

Versions of packages valgrind depends on:
ii  libc6  2.21-6
ii  libc6-dbg  2.21-6

Versions of packages valgrind recommends:
ii  gdb   7.10-1
ii  valgrind-dbg  1:3.11.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
ii  kcachegrind   4:15.08.3-1
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

Bug#807404: python-matplotlib: Incomplete redraw after zoom-in -> zoom-out

[Sandro Tosi]

control: tags -1 +moreinfo +unreproducible
control: severity -1 minor

On Tue, Dec 8, 2015 at 1:28 PM, Mathias Palm
 wrote:
> When using matplotlib in the standard configuration the figure is not
> redrawn after an zoom-in/zoom out sequence or when zooming out using the
> rigth mouse button.

please clarify the steps you used to produce this "issue" as i tried
to replicate them (from what I could get from your terse and
undetailed description) i was not able to (so pressing the "home"
button correctly brought me back to the original plot)

-- 
Sandro "morph" Tosi
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#810470: libusb: superseded by libusb-1.0

[Aurelien Jarno]

Hi,

On 2016-01-08 23:24, Sebastian Reichel wrote:
> Hi,
> 
> Maybe we should switch from libusb0.1 to libusb-compat-0.1 before
> dropping it completly (which may take some time, since the changed
> API must be supported upstream).
> 
> http://www.libusb.org/wiki/libusb-compat-0.1

Yes, there is even bug #731424 opened for it. I personally don't really 
see the point of changing one library for another, except maybe 
introducing some bugs in the switch. I remember there were some issues
with this compat library, but they might have been fixed in the
meantime. Also it hasn't seen any change in the last 3 years, and not
much development besides bug fixes in the last 6 years.

Aurelien

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


signature.asc
Description: Digital signature

Bug#810488: RFS: flx/0.6.1-1 [ITP] -- sorting algorithm for fuzzy matching in Emacs

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package flx.  flx provides intuitive
fuzzy matching for Emacs, similar to Sublime Text's matching.  I'm
packaging this as a Recommends: of projectile, another ITP of mine.

* Package name: flx
  Version : 0.6.1-1
  Upstream Author : Le Wang
* URL : https://github.com/lewang/flx
* License : GPL-3+
  Section : lisp

My source package builds the binary packages elpa-flx and elpa-flx-ido.
This reflects the split upstream makes in publishing flx to MELPA, the
de facto standard source of Emacs addons

Download with dget:

dget -x http://mentors.debian.net/debian/pool/main/f/flx/flx_0.6.1-1.dsc

Or build it with gbp:

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/flx
git checkout debian/0.6.1-1
git verify-tag debian/0.6.1-1 # if you have my key
gbp buildpackage

Thanks.

Sean Whitton


signature.asc
Description: Digital signature

Bug#808905: OK it doesn't forbid if you say "n"

[積丹尼 Dan Jacobson]

retitle 808905 Say instead "Will mark version XXX of package YYY as forbidden"
found 808905 0.7.5-3
thanks

Today with 0.7.5-3 I am happy to report that if one says "n"
aptitude indeed does not mark the versions as forbidden.

However this is still after the words
# aptitude forbid-version less
Marking version 481-1 of package less as forbidden

Therefore please change the wording to
Will mark version 481-1 of package less as forbidden

(Before finally asking Do you want to continue? [Y/n/?])

Bug#810445: lirc: please switch to libusb 1.0

[Stefan Lippers-Hollmann]

Hi

On 2016-01-08, Aurelien Jarno wrote:
> Package: lirc
> Version: 0.9.0~pre1-1.2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> lirc has a build-depends on libusb-dev. A few years ago upstream
> has released a new major version libusb 1.0 with a different API which
> aims to fix design deficiencies with USB 2.0 and 3.0 in mind.
> 
> The old libusb 0.1 package is not supported upstream anymore and should
> be considered deprecated.
[...]

[ this will be basically the same answer as for libftdi1, so feel free
  to skip reading one ]

What is the rough time frame you have in mind for removing libusb-0.1-4
from unstable?

I'm asking because there are two options:

- pushing the current upstream version, with a transition, involving 
  around 30 rdepends, needing sourceful uploads for most of them, and 
  a rather complex device specific config migration, plus some pending 
  packaging work

or

- backporting (looks to be pretty reasonable) the necessary changes for 
  libusb 1.0 to lirc 0.9.0 (or 0.9.1, which 'only' needs the config 
  migration, but not the library transition and the corresponding 
  transition slot).

Depending on your schedule, I can look into the targeted backports,
but naturally I'd prefer to avoid that (as long as lirc won't be
one of the final blockers).

Regards
Stefan Lippers-Hollmann


pgpqcQgBtZwtO.pgp
Description: Digitale Signatur von OpenPGP

Bug#810489: ITP: node-nodeunit -- Easy unit testing for node.js and the browser.

[Jonathan Ulrich Horn]

Package: wnpp
Severity: wishlist
Owner: Jonathan Ulrich Horn 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-nodeunit
  Version : 0.9.1
  Upstream Author : Caolan McMahon
* URL : https://github.com/caolan/nodeunit
* License : Expat
  Programming Lang: JavaScript
  Description : Easy unit testing for Node.js and the browser.

 Nodeunit is an async unit testing tool for Node.js and the browser.
 It is simple to use, has flexible reporters for custom output
 and allows the use of mocks and stubs.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#810445: lirc: please switch to libusb 1.0

[Aurelien Jarno]

On 2016-01-09 01:05, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2016-01-08, Aurelien Jarno wrote:
> > Package: lirc
> > Version: 0.9.0~pre1-1.2
> > Severity: wishlist
> > 
> > Dear Maintainer,
> > 
> > lirc has a build-depends on libusb-dev. A few years ago upstream
> > has released a new major version libusb 1.0 with a different API which
> > aims to fix design deficiencies with USB 2.0 and 3.0 in mind.
> > 
> > The old libusb 0.1 package is not supported upstream anymore and should
> > be considered deprecated.
> [...]
> 
> [ this will be basically the same answer as for libftdi1, so feel free
>   to skip reading one ]
> 
> What is the rough time frame you have in mind for removing libusb-0.1-4
> from unstable?

I currently don't have a time frame in mind for libusb 0.1. Ideally that
should be done for stretch, but given the number of involved packages it
might be only for buster. That's why have opened theses bugs with
severity "wishlist".

For libftdi, I hope we can do that before the stretch freeze.

> I'm asking because there are two options:
> 
> - pushing the current upstream version, with a transition, involving 
>   around 30 rdepends, needing sourceful uploads for most of them, and 
>   a rather complex device specific config migration, plus some pending 
>   packaging work
> 
> or
> 
> - backporting (looks to be pretty reasonable) the necessary changes for 
>   libusb 1.0 to lirc 0.9.0 (or 0.9.1, which 'only' needs the config 
>   migration, but not the library transition and the corresponding 
>   transition slot).
> 
> Depending on your schedule, I can look into the targeted backports,
> but naturally I'd prefer to avoid that (as long as lirc won't be
> one of the final blockers).

Don't rush anything for now. I'll send an update once there are less
blockers involved.

Regards,
Aurelien

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


signature.asc
Description: Digital signature

Bug#810243: libqt5core5a: version 5.5.1+dfsg-12 causes lock-up when kdeint starts iceweasel

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 08 January 2016 06:49:50 Arthur Marsh wrote:
> Lisandro Damián Nicanor Pérez Meyer wrote on 08/01/16 05:48:
> > By the way, why using kdeini5 with iceweasel?
> > 
> > The purpose of kdeinit5, according to it's manpage, is:
> > Using kdeinit5 to launch KDE applications makes starting a typical KDE
> > 
> > application a couple times faster and reduces memory consumption by a
> > substantial amount.
> > 
> > kdeinit5 is linked against all libraries a standard KDE application
> > needs.
> > 
> > With this technique, starting an application becomes much faster because
> > now only the application itself needs to be linked whereas otherwise both
> > the application as well as all the libraries it uses need to be linked.
> > 
> > Iceweasel is by no means a "typical KDE application".
> 
> Thanks for the reply, I am only trying to start iceweasel from the KDE
> Plasma desktop application launcher (which uses kdeinit5).
> 
> When trying to isolate the issue earlier I had also tried starting
> iceweasel from a konsole terminal session.
> 
> Is it possible start applications within the KDE plasma desktop without
> them having kdeinit5 as a parent/grandparent process?

I tried opening iceweasel from krunner and from the K menu it works perfectly.

Have you ried creating a new user from scratch and testing what happens there?





-- 
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.
  Anonymous

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#810492: x11-xserver-utils: Please add Multi-Arch: foreign

[Elrond]

Package: x11-xserver-utils
Version: 7.7+5
Severity: wishlist

Hi,

It looks like x11-xserver-utils offers an
architecture independent (process/cli level) interface to
its users.
Would you mind setting it to Multi-Arch: foreign?  It's
usually a matter of adding one line to debian/control.

This would hopefully improve install options for different
architectures.  Like for example using the x32 variant of
x11-xserver-utils on a mixed amd64/x32 system.


Cheers

Elrond

Bug#810493: RFS: epl/0.8-1 [ITP] -- Emacs Package Library

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package epl.  EPL stands for 'Emacs
Package Library'.  It provides a convenient high-level API for the
various versions of package.el that are distributed with different
versions of Emacs.  As such it is useful for developing other Emacs
Addons.

I am packaging this as a dependency of pkg-info-el, another ITP of mine.

* Package name: epl
  Version : 0.8-1
  Upstream Author : Sebastian Wiesner 
* URL : https://github.com/cask/epl
* License : GPL-3+
  Section : lisp

Download with dget:

dget -x http://mentors.debian.net/debian/pool/main/e/epl/epl_0.8-1.dsc

Or build it with gbp:

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/epl
git checkout debian/0.8-1
git verify-tag debian/0.8-1 # if you have my key
gbp buildpackage

Thanks.

Sean Whitton


signature.asc
Description: Digital signature

Bug#810495: Update edk2 to add GICv3 support

[dann frazier]

Package: qemu-efi
Version: 0~20150106.5c2d456b-2
Tags: patch

GICv3 support has been added upstream, which is needed to support EFI
KVM guests on systems like Cavium's ThunderX. Attached are patches to
update the packaging after an upstream merge (I prepared/tested them
on top of upstream commit c2a892d).

>From fee3c101820b71fe912a7c875473b6154523 Mon Sep 17 00:00:00 2001
From: dann frazier 
Date: Tue, 5 Jan 2016 16:04:19 -0700
Subject: [PATCH 1/6] New upstream release, for GICv3 support.

---
 debian/changelog

diff --git a/debian/changelog b/debian/changelog
index 2736c37..5cd97a6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+edk2 (0~20160105.c2a892d-1) UNRELEASED; urgency=medium
+
+  * New upstream release, for GICv3 support.
+
+ -- dann frazier   Tue, 05 Jan 2016 16:03:34 -0700
+
 edk2 (0~20150106.5c2d456b-2) unstable; urgency=medium
 
   [ Steve Langasek ]
-- 
2.7.0.rc3

>From b4b1778517c5172f63149e6cf938ff262940023c Mon Sep 17 00:00:00 2001
From: dann frazier 
Date: Tue, 5 Jan 2016 16:12:25 -0700
Subject: [PATCH 2/6] Drop patches that no longer apply

---
 .../patches/arm64-no-expensive-optimizations.patch | 23 --
 debian/patches/no-missing-braces.diff  | 15 -
 debian/patches/no-stack-protector-all-archs.diff   | 37 --
 debian/patches/series  |  3 --
 4 files changed, 78 deletions(-)
 delete mode 100644 debian/patches/arm64-no-expensive-optimizations.patch
 delete mode 100644 debian/patches/no-missing-braces.diff
 delete mode 100644 debian/patches/no-stack-protector-all-archs.diff

diff --git a/debian/patches/arm64-no-expensive-optimizations.patch b/debian/patches/arm64-no-expensive-optimizations.patch
deleted file mode 100644
index b1fe9ac..000
--- a/debian/patches/arm64-no-expensive-optimizations.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-Description: Workaround ARM64 compiler issue by disabling certain optimizations
- GCC5 introduced a regression when building edk2. The symptom is that KVM
- VMs hang before displaying any EFI messages. This was bisected down to the
- introduction of some bswap optimizations that can be disabled with
- -fno-expensive-optimizations.
-Author: dann frazier 
-Last-Update: 2015-09-03
-Bug-Ubuntu: http://bugs.launchpad.net/bugs/1489560
-Forwarded: no
-
-diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template
-index c3166e5..3848dc2 100644
 a/BaseTools/Conf/tools_def.template
-+++ b/BaseTools/Conf/tools_def.template
-@@ -6732,7 +6732,7 @@ RELEASE_ARMGCC_ARM_CC_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ARM_CC_F
- #
- # Use default values, or override in DSC file
- #
--*_ARMGCC_AARCH64_ARCHCC_FLAGS= -fno-stack-protector
-+*_ARMGCC_AARCH64_ARCHCC_FLAGS= -fno-stack-protector -fno-expensive-optimizations
- *_ARMGCC_AARCH64_ARCHASM_FLAGS   =
- *_ARMGCC_AARCH64_ARCHDLINK_FLAGS =
- *_ARMGCC_AARCH64_PLATFORM_FLAGS  =
diff --git a/debian/patches/no-missing-braces.diff b/debian/patches/no-missing-braces.diff
deleted file mode 100644
index 3001ecb..000
--- a/debian/patches/no-missing-braces.diff
+++ /dev/null
@@ -1,15 +0,0 @@
-Description: Add -Wno-missing-braces to CFLAGS to avoid build failures
-Author: dann frazier 
-Forwarded: no
-
 a/BaseTools/Conf/tools_def.template	2015-01-06 19:00:37.684069275 -0700
-+++ b/BaseTools/Conf/tools_def.template	2015-01-06 19:01:24.320317934 -0700
-@@ -3839,7 +3839,7 @@
- DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm --rename-section .data=.hii
- DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii
- 
--DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
-+DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -Wno-missing-braces -ffunction-sections -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
- DEFINE GCC44_IA32_CC_FLAGS   = DEF(GCC44_ALL_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32
- DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large
- DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -n -q --gc-sections --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script
diff --git a/debian/patches/no-stack-protector-all-archs.diff b/debian/patches/no-stack-protector-all-archs.diff
deleted file mode 100644
index 66384c9..000
--- a/debian/patches/no-stack-protector-all-archs.diff
+++ /dev/null
@@ -1,37 +0,0 @@
-Author: Steve Langasek 
-Description: pass -fno-stack-protector to all 

Bug#810370: lirc: please switch to libftdi1

[Stefan Lippers-Hollmann]

Hi

On 2016-01-08, Aurelien Jarno wrote:
> Package: lirc
> Version: 0.9.0~pre1-1.2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> lirc has a build-depends on libftdi-dev. Upstream has released a new
> major version with a slightly different API and based on libusb 1.0. The
> old libusb and libftdi versions should be considered deprecated as they
> are not maintained upstream anymore.
[...]

[ this will be basically the same answer as for libusb, so feel free
  to skip reading one ]

What is the rough time frame you have in mind for removing libftdi1
from unstable?

I'm asking because there are two options:

- pushing the current upstream version, with a transition, involving 
  around 30 rdepends, needing sourceful uploads for most of them, and 
  a rather complex device specific config migration, plus some pending 
  packaging work

or

- backporting (looks to be pretty reasonable) the necessary changes for 
  libftdi1-dev to lirc 0.9.0 (or 0.9.1, which 'only' needs the config 
  migration, but not the library transition and the corresponding 
  transition slot).

Depending on your schedule, I can look into the targeted backports,
but naturally I'd prefer to avoid that (as long as lirc won't be
one of the final blockers).

Regards
Stefan Lippers-Hollmann


pgpQ9qg5OCG3s.pgp
Description: Digitale Signatur von OpenPGP

Bug#810490: bash-completion: completion with single-apostrophe does not continue beyond the first '

[lkcl]

Package: bash-completion
Version: 1:2.1-4
Severity: normal
Tags: upstream

* i have two filenames which happens to have a single-quote character ' in it.
* the extension of each file is different.
* pressing tab completes BEYOND the apostrophe, up to the part where the
  files differ
* pressing tab a second time FAILS
* typing any letters (even a single letter) and then pressing tab FAILS

so it would appear that the single-quote, once in the buffer of
characters that have already been completed, causes any further
completion to fail.

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

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

Versions of packages bash-completion depends on:
ii  bash  4.3-14+b1
ii  dpkg  1.18.1

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information

Bug#810491: netsurf-gtk: CVE-2015-7505 CVE-2015-7506 CVE-2015-7507 CVE-2015-7508

[Moritz Muehlenhoff]

Package: netsurf-gtk
Severity: grave
Tags: security
Justification: user security hole

Please see these:

CVE-2015-7508 [heap overflow]
http://source.netsurf-browser.org/libnsbmp.git/commit/?id=041df43bbe273b0829132b0b17d89a69da2927d4

CVE-2015-7507 [out-of-bounds read]
http://source.netsurf-browser.org/libnsbmp.git/commit/?id=49427b52ba41a1813e3822301612e2e170107efd

CVE-2015-7506 [out-of-bounds read]
http://source.netsurf-browser.org/libnsgif.git/commit/?id=088fa0819f1aeaf212a95caf7393a38c1640b5f0

CVE-2015-7505 [stack overflow]
http://source.netsurf-browser.org/libnsgif.git/commit/?id=a268d2c15252ac58c19f1b19771822c66bcf73b2

Cheers,
Moritz

Bug#807853: k3b: FTBFS with FFmpeg 2.9

[Pino Toscano]

In data venerdì 8 gennaio 2016 21:50:33, Andreas Cadhalpun ha scritto:
> Hi Pino,
> 
> Thanks for your quick reply.
> 
> On 08.01.2016 18:12, Pino Toscano wrote:
> > Yes, I've seen the patch in #807853, and a couple of review requests on
> > KDE's reviewboard.
> 
> Could you please post links to upstream discussion about this or mark
> the bug as forwarded?

I saw these two patches:
https://git.reviewboard.kde.org/r/122569/
https://git.reviewboard.kde.org/r/122601/
they refer to the master branch of k3b, but the code in
plugins/decoder/ffmpeg/ is the same in both the 2.0 branch (from where
the 2.0.x releases like the latest 2.0.3a are taken) and master.
Would it be possible for you to check them, and maybe also comment on
the reviewboard?

> > Let me take this opportunity to "reverse the issue": is your upstream
> > aware that the continuous API breaks in each new stable series only
> > waste time on the users' side?
> 
> I sense frustration in these words, but let's get the facts straight:
>  * The last four stable series (2.5.*-2.8.*) didn't break the API.

Possibly, but IIRC only 2.7 was used back in Debian, so what 2.5 and 2.6
did is generally not relevant for me. Before it was libav, yes, but from
a Debian maintainer POV it was "whatever provided libav* libraries".

>  * Adapting to the new APIs is no waste of time, rather maintenance cost,
>also improving the API using program in the process, as the old APIs
>were deprecated for a reason.

The ffmpeg decoding plugin in k3b is doing the same job for the latest
6+ years, so at least to me all these API changes look like they brought
nothing. And well, changing the code to newer APIs that don't bring
anything new to what was already done is a cost that, as developer, I'd
rather not pay.

> And yes, the upstream developers are aware of that maintenance cost,
> I made sure of that. Please go and read the discussion upstream [1][2].
> And I can understand your frustration, after all, I'm the one who wrote
> patches for all affected Debian packages.

Thank you for that, at least should help bringing upstream back to the
real world, where there are developers using older distros (e.g. LTS
ones)...

> > Just look at the affected code in k3b,
> > plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp: many defines and ifdef's,
> > just to make the very same code do the very same job, nothing less and
> > nothing more.
> 
> I'm well aware how this file looks, as I wrote a patch for it.
> And most of these ifdef's could just be removed, unless you need to
> build this in ancient environments...

There is not an active k3b upstream, so I'm afraid the new ffmpeg
support code should be as much as conservative as possible (that is,
support the new version but keep supporting older ones as done now).

Thanks,
-- 
Pino Toscano

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

Bug#810494: RFS: pkg-info-el/0.6-1 [ITP] -- provide information about Emacs packages

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package pkg-info-el.  The package is a
library of Emacs Lisp functions used to extract information about Emacs
packages.  As such it is useful in developing other Emacs Lisp addons.

I am packaging this as a dependency of projectile, another ITP of mine.

* Package name: pkg-info-el
  Version : 0.6-1
  Upstream Author : Sebastian Wiesner 
* URL : https://github.com/lunaryorn/pkg-info.el
* License : GPL-3+
  Section : lisp

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/p/pkg-info-el/pkg-info-el_0.6-1.dsc

Or build it with gbp:

git clone https://anonscm.debian.org/git/pkg-emacsen/pkg/pkg-info-el
git checkout debian/0.6-1
git verify-tag debian/0.6-1 # if you have my key
gbp buildpackage

Thanks.

Sean Whitton


signature.asc
Description: Digital signature

Bug#792552: still not working for me

[Frédéric Brière]

On Fri, Jan 08, 2016 at 08:49:44AM +0100, Harald Dunkel wrote:
> metoo. My /etc/crypttab contains just a comment line.

Indeed, the applied patch will loop infinitely when given an empty
crypttab.  Conversely, it will fail to loop if a busy entry is followed
by a non-busy one.

Here's a quick fix for both issues.

--- cryptdisks.functions.distrib	2016-01-06 20:35:05.0 -0500
+++ cryptdisks.functions	2016-01-08 11:08:58.367424334 -0500
@@ -772,15 +772,14 @@
 
 	ITERATE=1
 	while [ "$ITERATE" = "1" ]; do
+		ITERATE=0
 		egrep -v "^[[:space:]]*(#|$)" "$TABFILE" | while read dst src key opts; do
 			handle_crypttab_line_stop "$dst" "$src" "$key" "$opts" <&3
 			STATE=$?
 			if [ "$STATE" = "0" ]; then
 echo  "stopped $dst"
-ITERATE=0
 			elif [ "$STATE" = "1" ]; then
 log_action_end_msg $?
-ITERATE=0
 			elif [ "$STATE" = "2" ]; then
 echo "$dst Busy. Retrying..."
 sleep 1

Bug#705225: python-passlib: bcrypt not usable from python-passlib -- missing backend

[Brian May]

Brian May  writes:

> I just opened #796853 for this security issue.

#796853 was closed, so I believe this bug can now be closed...
-- 
Brian May 

Bug#809079: please tell the user...

[積丹尼 Dan Jacobson]

Please next time,
tell the user,
that what he sees,
is the old prerm script being run,
and that it won't happen again after this last time,
Else he won't know,
and will then reopen the bug,
and waste lots of time,
debugging for you.

Bug#805030: libssh: newer upstream versions?

[Chris Knadle]

Willi Mann:
> Hi Chris,
> 
> Am 2016-01-08 um 07:57 schrieb Chris Knadle:
>> Willi Mann:
>>>
>>> Could you make the git repo somewhere available?
>>
>>git clone git://git.coredump.us/debian/libssh.git
>>
>> I use git-buildpackage and pristine-tar, and the clone will contain all that
>> plus default to the '0.7.2' branch that contains all the commits I've done
>> on the package.
> 
> I think it would be good to rebase your work onto the repository in
> collab-maint. Do you already have write access there? If not, could you
> apply for it?
> 
> https://lists.debian.org/debian-devel-announce/2012/01/msg6.html

At DebConf15 there was discussion of movement away from Alioth for a number
of reasons, including Alioth being considered "too full".  I don't have an
objection to hosting Debian-related work in a Debian git repository -- but
Alioth isn't controlled by Debian.  For existing projects on Alioth I don't
mind making a request to join them, but I'd rather put repos for new
projects somewhere else.

> In the meantime, it is probably better to work with your repository.
> Once I will make commits, I'll send you a link to my clone of the repo.

Sure -- I can either pull from your repo or you could send patches as
attachments in email via git format-patch.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#810482: RFP: rtags -- C/C++ client/server indexer with integration for Emacs

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: rtags
  Version : 2.0
  Upstream Author : Anders Bakken 
* URL : https://github.com/Andersbakken/rtags
* License : GPL
  Programming Lang: C++
  Description : C/C++ client/server indexer with integration for Emacs

RTags is a client/server application that indexes C/C++ code and keeps a
persistent file-based database of references, declarations, definitions,
symbolnames etc. There’s also limited support for ObjC/ObjC++. It allows you
to find symbols by name (including nested class and namespace scope). Most
importantly we give you proper follow-symbol and find-references support. We
also have neat little things like rename-symbol, integration with clang’s
“fixits” (http://clang.llvm.org/diagnostics.html). We also integrate with
flymake using clang’s vastly superior errors and warnings. Since RTags
constantly will reindex “dirty” files you get live updates of compiler
errors and warnings. Since we already know how to compile your sources we
have a way to quickly bring up the preprocessed output of the current source
file in a buffer.

Bug#809136: Block borgbackup migration to stable for now

[Antoine Beaupré]

Source: borgbackup
Followup-For: Bug #809136

[TL;DR: keep borg in testing. let it be released with stable when
streth gets released. use backports to ensure compatibility works
across debian releases, if necessary (and it is not, right now!).]

Both as a user and developer of borg backup, I disagree with some of
the comments made of borg in this bug report.

Borg has actually shown great API stability since it forked from
Attic. The change that occured was necessary, and was well documented
in the release notes and the manual. (It should have been documented
in the NEWS.Debian file in the Debian package as well.) It is also the
*only* one that happened in over 15 releases since the fork from
Attic. We can even still convert older, prehistoric attic repositories
to borg without data loss.

Furthermore, this only concerns the backup remote RPC protocol. The
storage format is *still* compatible, all the way back to attic. If
you have a copy of your repository, you can still backup to and from
it. If your server is upgraded, it is true that you do need to upgrade
your client, however (and vice-versa).

But tons of backup software in Debian have that behavior: unison was
already mentionned, but rdiff-backup also has the same problems. That
is why we have backports: when the server side upgrades, we upgrade
the clients to the backports version. It's annoying, but it works, and
rdiff-backup has been in Debian for a long time. Those other backup
softwares are way more popular, sometimes by orders of magnitude, than
borg:

https://qa.debian.org/popcon.php?package=rdiff-backup
https://qa.debian.org/popcon.php?package=unison
https://qa.debian.org/popcon.php?package=borgbackup

Keeping borg from entering stable (or, more precisely, testing in this
case) is exactly what we *don't* want here. If we keep borg from
entering testing, we keep it from being backported. If we keep it from
being backported, we make it *harder* for people to run the same
version of borg across different versions of Debian. So we basically
make the Debian package useless, which means people won't use it and
will instead use the pip version.

Is that what we want?

I was looking at backporting borg from stretch to jessie, but if the
maintainers are going to remove it from stretch, i'm certainly not
going to bother, and that would be a shame...

Finally, keep in mind that this is a problem only in Debian, and only
if we have multiple, incompatible versions of borg in
Debian. (Non-debian installs can use virtualenvs to install as many
borg versions as they want.) Right now, we only have one version
(0.29.0-2), and it's compatible between unstable and testing. If
testing gets released right now, stable, testing and unstable are all
compatible, and we have absolutely no problem.

Furthermore, it's very likely that borg 1.0 gets released before
stretch, so all those arguments will be completely irrelevant because
borg *will* be API stable.

This, in short, is a non-isse right now. If 0.28 was in stable and
0.29 in testing, this would be a bug, but then the fix would be a
backport, not a removal from stable (which you can do, if you are
really stuck, anyways).

Now, can i open this bug about backporting? :)

a.

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

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

Bug#810471: libdrm2: [drm] stuck on render ring

[Julien Cristau]

On Fri, Jan  8, 2016 at 19:54:12 +0100, cacatoès wrote:

> Package: libdrm2
> Version: 2.4.65-3
> 
> Dear Maintainers,
> 
> I've been recently playing with wine, and playing the game The Witcher.
> 
> Sometimes it crashes quite early, and produces some messages in dmesg,
> which invite me to write following bug report.
> 
> This crash doesn't happen every time, since I was able to run the game a
> few times normally.
> 
> While my main architecture is amd64, this bug should apply to i386.
> 
> Closed bug #745061 has similar error message, but can't say they are
> related.
> 
Most likely not.

> Attached is dmesg log for both times it happened.
> You can also find /sys/class/drm/card0/error files there :
> https://1fichier.com/?7p4l44bcjq
> 
> Tell me if you need more infos/tests.
> 
[...]
> [19943.355117] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
> against DRI -> DRM/Intel
> [19943.355118] [drm] drm/i915 developers can then reassign to the right 
> component if it's not a kernel issue.

Please follow the above advice; more details at
https://01.org/linuxgraphics/documentation/how-report-bugs

Afterwards please let us know the bug number so we can track it.

Cheers,
Julien

Bug#743599: lintian: false positive python-script-but-no-python-dep when using #!/usr/bin/python2

[Luca Boccassi]

Control: tags -1 patch

On Fri, 04 Apr 2014 03:31:05 +0200 Per Andersson  wrote:
> Package: lintian
> Version: 2.5.22.1
> Severity: normal
> 
> Dear Maintainer,
> 
> Including a script with shebang #!/usr/bin/python2 in a Debian package
> results in lintian reporting the error python-script-but-no-python-dep.
> 
> I believe this to be incorrect since python-minimal ships
> /usr/bin/python2 as a symlink to python2.7, as per upstream PEP0394 [1].
> 
> 
> [1] http://legacy.python.org/dev/peps/pep-0394/

Dear Maintainer(s),

A new script was recently added to the Linux kernel in version 4.3:
https://github.com/torvalds/linux/commit/4b715d24f4f14731c7b553cbb8604fe865cb8d3c
This script uses /usr/bin/python2 as shebang as indicated by pep0394,
since it depends strictly on Python 2.

This Lintian bug is causing it to be flagged as an error in our internal
build of the kernel, so it got on our radar. The attached patch fixes
the problem by having /usr/bin/python2 treated as /usr/bin/python. Would
this be an acceptable solution to the problem? If not, what would you
recommend?

Thank you!

Kind regards,
Luca Boccassi
Brocade Communications Systems


From c9a9e433c7734737712f1fc1067bdf6966938ec1 Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Fri, 8 Jan 2016 20:12:09 +
Subject: [PATCH] Do not match /usr/bin/python2 to python2:any

A python2 package does not exist, so dh_python correctly does not
generate a dependency.
Using /usr/bin/python2 as shebang is required as explained in pep-0394:
http://legacy.python.org/dev/peps/pep-0394/
---
 data/scripts/versioned-interpreters | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/data/scripts/versioned-interpreters 
b/data/scripts/versioned-interpreters
index fff44c2..48b8cc5 100644
--- a/data/scripts/versioned-interpreters
+++ b/data/scripts/versioned-interpreters
@@ -75,7 +75,7 @@ lua => /usr/bin, lua([\d.]+), lua$1, 40 50 5.1 5.2
 octave  => /usr/bin, octave([\d.]+), octave$1, 3.0 3.2
 php => /usr/bin, php(\d+), php$1-cli, 5, @NO_DEFAULT_DEPS@
 pike=> /usr/bin, pike([\d.]+), pike$1 | pike$1-core, 7.6 7.8, 
@NO_DEFAULT_DEPS@
-python  => /usr/bin, python([\d.]+), python$1:any | python$1-minimal:any, 2.7, 
@SKIP_UNVERSIONED@
+python  => /usr/bin, python(2\..+|[3-9.]+), python$1:any | 
python$1-minimal:any, 2.7, @SKIP_UNVERSIONED@
 ruby=> /usr/bin, ruby([\d.]+), ruby$1, 1.8 1.9, @SKIP_UNVERSIONED@
 runghc  => /usr/bin, runghc(\d+), ghc$1, 6, ghc
 scsh=> /usr/bin, scsh-([\d.]+), scsh-$1, 0.6
-- 
2.1.4



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

Bug#810470: libusb: superseded by libusb-1.0

[Sebastian Reichel]

Hi,

Maybe we should switch from libusb0.1 to libusb-compat-0.1 before
dropping it completly (which may take some time, since the changed
API must be supported upstream).

http://www.libusb.org/wiki/libusb-compat-0.1

-- Sebastian


signature.asc
Description: PGP signature

Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule

[Josua Dietze]

Am 08.01.2016 um 21:25 schrieb Blake Miner:

Bump.  Any another thoughts on this bug?  It's hard to tell if this is a
usb-modeswitch bug (i.e. a problem with usb_modeswitch_dispatcher) or if this
is a problem with the udev rule itself (a usb-modeswitch-data bug).


Have you tried to enable usb_modeswitch's logging?
If the rules are at least triggering and starting the dispatcher, there should 
be a log being created.



/lib/udev/usb_modeswitch '2-1/2-1:1.0' does not work.
/lib/udev/usb_modeswitch '/2-1' works just fine.


The log should give more hints.


Regards,
Josh

Bug#810486: sus: Error in `/usr/share/doc-base/susv*', line 9: all `Format' sections are invalid.

[Christoph Anton Mitterer]

Source: sus
Version: 7.20160107
Severity: normal


Hey.

During installation, the following errors pop up:
Unpacking susv4 (7.20160107) over (7.20150719) ...
Processing triggers for mime-support (3.59) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for install-info (6.0.0.dfsg.1-4) ...
Processing triggers for doc-base (0.10.6) ...
Processing 5 changed doc-base files, 1 added doc-base file...
Error in `/usr/share/doc-base/susv3', line 9: all `Format' sections are invalid.
Error in `/usr/share/doc-base/susv4', line 9: all `Format' sections are invalid.
Error in `/usr/share/doc-base/susv2', line 9: all `Format' sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above errors.
Registering documents with scrollkeeper...


Cheers,
Chris. :)

Bug#764349: tor+http with apt-file

[Petter Reinholdtsen]

I finally had time for some more testing of apt-file with the tor
transport, this time using unstable, and can confirm that apt-file now
work with apt-transport-tor.

Any plans to get the experimental version in unstable?

-- 
Happy hacking
Petter Reinholdtsen