Bug#801488: aptitude: crash when removing package which apt-get can remove without problem

[Nick Black]

Package: aptitude
Version: 0.7.3-1
Severity: important

Dear Maintainer,

Aptitude crashes when removing certain packages (not all), whether using
remove or purge, command line or curses UI. Apt-get can remove the same
package just fine. The issue seems possibly related to multiarch.

I ran:

 sudo dpkg --add-architecture i386 
 sudo aptitude update

I then installed wine32:i386. I already had wine:amd64 and wine64:amd64
installed. I removed wine64:amd64 and wine64-bin:amd64 without problems.
Attempting to run
 
 sudo aptitude -v -v -v purge wine

or

 sudo aptitude -v -v -v purge wine32:i386

crashes with no output, just status 139, SIGSEGV. This is true whether I
use "purge" or "remove". No entry is made in
/var/log/aptitude/aptitude.log.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.3 compiled at Oct  7 2015 23:33:19
Compiler: g++ 5.2.1 20151003
Compiled against:
  apt version 4.16.0
  NCurses version 6.0
  libsigc++ version: 2.6.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20150810
  cwidget version: 0.5.17
  Apt version: 4.16.0

aptitude linkage:
linux-vdso.so.1 (0x7fffe6d68000)
libapt-pkg.so.4.16 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.16 
(0x7f5fe916b000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f5fe8f3b000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f5fe8d11000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f5fe8b0b000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f5fe880c000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f5fe853f000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f5fe8326000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f5fe7f24000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f5fe7d07000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f5fe798c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5fe768b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f5fe7475000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5fe70cc000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f5fe6ec9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5fe6cc5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5fe6aaa000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f5fe689a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f5fe6677000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5fe646f000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f5fe626a000)
/lib64/ld-linux-x86-64.so.2 (0x7f5fe9a9)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.7.3-1
ii  libapt-pkg4.161.0.10.2
ii  libboost-iostreams1.58.0  1.58.0+dfsg-3+b1
ii  libc6 2.19-22
ii  libcwidget3v5 0.5.17-4
ii  libgcc1   1:5.2.1-21
ii  libncursesw5  6.0+20150810-1
ii  libsigc++-2.0-0v5 2.6.1-2
ii  libsqlite3-0  3.8.11.1-1
ii  libstdc++65.2.1-21
ii  libtinfo5 6.0+20150810-1
ii  libxapian22v5 1.2.21-1.2

Versions of packages aptitude recommends:
ii  aptitude-doc-en [aptitude-doc]  0.7.3-1
ii  libparse-debianchangelog-perl   1.2.0-8
ii  sensible-utils  0.0.9

Versions of packages aptitude suggests:
ii  apt-xapian-index  0.47
pn  debtags   
pn  tasksel   

-- no debconf information

Bug#794104: Closing wishlist "new upstream release" bug

[Andreas Ronnquist]

fixed 794104 3.3.0-0.1
thanks

The new version has now been uploaded, but of course I forgot to close
this bug in the changelog. Now closing.

-- Andreas Rönnquist
gus...@debian.org

Bug#801490: RFS: knopflerfish-osgi/5.1.0+dfsg1-3

[Felix Natter]

Package: sponsorship-requests
Severity: normal

Dear mentors/debian-java,

I am looking for a sponsor for my package "knopflerfish-osgi"

* Package name: knopflerfish-osgi
  Version : 5.1.0+dfsg1-3
  Upstream Author : Makewave 
* URL : http://www.knopflerfish.org/
* License : BSD-3-clause
  Section : java

I just moved it from asm3 to asm5 (see #800860). It has been tested
locally with an r-dep and with pbuilder on sid.

It builds those binary packages:

libknopflerfish-osgi-framework-java - Java framework implementing the OSGi R5 
version
libknopflerfish-osgi-java-doc - Java framework implementing the OSGi R5 version 
(docs)

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

http://mentors.debian.net/package/knopflerfish-osgi

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

  dget -x 
http://mentors.debian.net/debian/pool/main/k/knopflerfish-osgi/knopflerfish-osgi_5.1.0+dfsg1-3.dsc

More information about knopflerfish can be obtained from 
http://www.knopflerfish.org/.

Changes since the last upload:

knopflerfish-osgi (5.1.0+dfsg1-3) unstable; urgency=medium

  * Move to libasm4-java (Closes: #800860)

Thanks and Best Regards,
-- 
Felix Natter

Bug#798900: lintian: false positive: source-is-missing for non-minified JS files

[Ole Streicher]

Sorry, I don't understand this:

Am 10.10.2015 um 22:35 schrieb Paul Wise:
> On Sun, 13 Sep 2015 21:46:37 + Sascha Steinbiss wrote:
>
>> Looks like the JQuery DataTables libraries included are flagged as minified
>> without source on the basis that they have lines longer than 1024 
>> characters: 
>> P: aegean source: source-contains-prebuilt-javascript-object 
>> data/share/vendor/jquery.dataTables.js line length is 1397 characters (>1024)
>> E: aegean source: source-is-missing data/share/vendor/jquery.dataTables.js
>> [...]
> lintian is absolutely correct to flag this file, it is generated from a
> bunch of other JavaScript files using Bash, PHP 5.4+, JSHint 2.1+ and
> the Closure compiler, at least according to the upstream git repos:
>
> https://github.com/DataTables/DataTablesSrc/
> https://github.com/DataTables/DataTables/

The Readme.md states that the files in the DataTables were generated
from the ones in DataTablesSrc, which means that DataTablesSrc contains
the *sources*. Specifically,

https://github.com/DataTables/DataTablesSrc/blob/master/js/DataTables.js

contains a line 25 (> 1024 characters long):

/*globals $,require,jQuery,define,_selector_run, [...] */

which triggers the lintian error in the case of python-astropy. I don't
see why this is real, since:

1. There is no indication that this line was not inserted manually, or
maybe automatically by the editor (emacs f.e. could probably do that
during the edit -- this would not make the file automatically generated),

2. Even if it was inserted by some script, it does not make the file
sourceless, since the source of this line is clearly the file content
itself,

3. there is no use case that you want to not edit this file, its
"source" (whatever this is). The line is a just comment, without any
influence on the semantics of the file. If you disagree here, you should
seriously consider flagging all CVS and SVN tags in source files as
"sourceless", since they are not to be edited manually as well.

--> lintian uses some heuristics here, which does obviously not match
the real life. Until this is improved, I would (again) propose to use
the "experimental" tag here; this is what this tag is for.

I would also propose to consider removing at least the line length test
for comments.

> I'm not sure what the correct heuristics to use are but in the 
> jquery.dataTables.js case the existing ones produced the right result.
>

They don't; at least not in the case of python-astropy.

Best regards

Ole

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

[Daniel Stender]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11.10.2015 10:52, Cornelius Kölbel wrote:
> Hi Daniel,
> 
> thanks a lot for all the valuable feedback.
> 
> I will dive into it later.
> 
> Do you have any further recommendations on finding a sponser (after
> streamlining the package)?
> 
> THanks a lot and kind regards
> Cornelius

Getting it Lintian clean is a major step. That's a rather complicated package, 
and
somebody might wants to discuss issues beyond that like your architecture of 
subpackages.
The flaws must be out of the way for that.

And then, patience ... sponsorship-requests is the right place to seek for a 
sponsor.

Best,
Daniel

- -- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGi3uAAoJEBXgmvTfUYLIXF4QAJRQbQ3HzZ6As8EhizQMMrLX
tATn1Aj5LhB7S2MHuwO6ytkJVkQUbG/3uvIoTqvCCBpEiYzUSp4eTJFsLSa26Wdz
H+bwkYlQlwj7/TWTqjBZ2b6wMPMw0J8dnhRur39CaNT25lJ0HLG69RLpkKeLOv9V
2r/D/eEoHuVDySqM1uncOXP+HQCTsMptlqr6BVR7sN1DYgf0L9ltpyQkj2eMyBPF
Qg1k15lpBkM5EehS5ri0YnGBqse6qxaUkYrrSuTOeOrTekF3QQjCRbq5CN9caqrc
4NCMcwm6YRVKYDZDWSLuK3ZUfrKh/Djo6gMQNalqWiqv0klDsxbayW8ZGDRJQgdT
rVqe4RKb/tKK8BmaFqR3zopJjc3/toACLlRIl5OlAd3B0c1Q1pnwbBRa5zbS0aEp
wXjHkkzZVInpsYNBwa2wo44cBWz3nx3JcozT9D4A6SqNY3s333oRwlobmmzoWiHy
pirb1QLhDTBHIu1xLqjZmiZ8cyjQhmepxY4pJ2oqOsFXkgMKgmlreJwvdKjY7NHF
jCgxLVZo/lMnPnnJU9F/MP4h6tfRlCkF8goSEo2TMGXp36NjIl+OHUl+jEyUfgGV
RIVuadM0I4HeX9qdKQMJqKoCxgaiVRXZMUiRWmfOGQPM3LKHa8h6tJpM8GvRxCBo
QZmBPl4iP7d+QkHDp33y
=8aR4
-END PGP SIGNATURE-

Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[Christian Kastner]

On 2015-10-11 07:54, James Lu wrote:
>> d/copyright:
>>  - The license appears to be GPL-3, not GPL-3+ (at least in the handful
>>of files I checked). This also requires correction of the free-
>>standing license block (the last paragraph)
> 
> I see. Ubuntu's packaging wrote the license as GPL-3+ for both the
> packaging and the source, but I guess the license of the individual
> files must prevail here. Fixed.

Hm, I just realized that I overlooked something here, namely the license
of the packaging that came from Ubuntu :-/

that makes things a bit more complicated, because:
* It is clear that upstream wanted GPL-3 for the upstream source
* It is clear that Ubuntu's packager wanted GPL-3+ for the
packaging, even if this motive was inspired by the erroneous
assumption of the GPL-3+ for the upstream source (asking the
packager directly might resolve that)

IOW, my initial advice was wrong. You need to keep GPL-3+ for the
packaging, and add GPL-3 for the upstream source.

Sorry about the mixup!

>>  - There's a formatting issue in the free-standing license text (line
>>27 is not indented)
> 
> I'm not sure what this means. Is it supposed to be indented to the width
> of "X-Comment: "? That's what I did.

Oh, I see what you meant to do now -- it wasn't lacking indentation, it
was beginning a new field.

However, in that case, the field's name is just "Comment" [1], without
the "X-" prefix.

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#801499: libgit-repository-perl: FTBFS: t/24-errors.t broken by newer versions of git

[Niko Tyni]

Package: libgit-repository-perl
Version: 1.315-1
Severity: serious
Tags: upstream patch
User: debian-p...@lists.debian.org
Usertags: autopkgtest
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=107219

This package fails to build on current sid/amd64:

  #   Failed test 'log -1: died'
  #   at t/24-errors.t line 204.
  #   'fatal: your current branch 'master' does not have any 
commits yet at t/24-errors.t line 203.
  # '
  # doesn't match '(?^:^fatal: bad default revision 'HEAD' )'
  # Looks like you failed 1 test of 65.
  t/24-errors.t .. 
  1..65
  not ok 1 - log -1: died
  [...]
  Test Summary Report
  ---
  t/24-errors.t(Wstat: 256 Tests: 65 Failed: 1)
Failed test:  1
Non-zero exit status: 1

This apparently broke with the git upgrade from 2.5.1-1 to 2.5.3-1. Quoting
 
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.5.2.txt

 * "git init empty && git -C empty log" said "bad default revision 'HEAD'",
   which was found to be a bit confusing to new users.

This is also [rt.cpan.org #107219], which has the attached patch
by Petr Šabata.
-- 
Niko Tyni   nt...@debian.org
>From 05f7008aa3ae32c8556e7907c65d9d16bebaabd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Mon, 21 Sep 2015 16:47:51 +0200
Subject: [PATCH] git-2.5.2 test suite compatibility fix
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The latest version of git altered the error message `git log -1' prints
on empty repositories.  This patch extends the test to deal with this
situation.

Signed-off-by: Petr Šabata 
---
 t/24-errors.t | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/24-errors.t b/t/24-errors.t
index 7d7f2ee..aeb2c58 100644
--- a/t/24-errors.t
+++ b/t/24-errors.t
@@ -56,7 +56,7 @@ my @tests = (
 {   test_repo => [],
 cmd   => [qw( log -1 )],
 exit  => 128,
-dollar_at => qr/^fatal: bad default revision 'HEAD' /,
+dollar_at => qr/^fatal: (?:bad default revision 'HEAD' |your current branch 'master' does not have any commits yet)/,
 },
 
 # create the empty tree
-- 
2.4.3

Bug#801500: libfile-rsync-perl: autopkgtest regression: test failures

[Niko Tyni]

Package: libfile-rsync-perl
Version: 0.48-2
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package started failing its autopkgtest checks on ci.debian.net
between 0.45-1 and 0.48-2.

  # Running [rsync --archive --files-from=- blib destdir]
  # Ret: 0
  Use of uninitialized value in concatenation (.) or string at ./test.pl line 
137.
  # Return $?: 
  Use of uninitialized value in concatenation (.) or string at ./test.pl line 
138.
  # Return exit code: 
  # rsync: link_stat "/tmp/adttmp.jLSQwm/smokek5ffn9/blib/lib/File/Rsync.pm" 
failed: No such file or directory (2)
  # rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1183) [sender=3.1.1]
  not ok 9 - files-from array ref
  #   Failed test 'files-from array ref'
  #   at ./test.pl line 151.
  # Running [rsync --archive --files-from=- blib destdir]
  # Ret: 0
  Use of uninitialized value in concatenation (.) or string at ./test.pl line 
170.
  # Return $?: 
  Use of uninitialized value in concatenation (.) or string at ./test.pl line 
171.
  # Return exit code: 
  # rsync: link_stat "/tmp/adttmp.jLSQwm/smokek5ffn9/blib/lib/File/Rsync.pm" 
failed: No such file or directory (2)
  # rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1183) [sender=3.1.1]
  not ok 10 - files-from infun
  #   Failed test 'files-from infun'
  #   at ./test.pl line 184.
  # Checking [rsync --archive --itemize-changes --omit-dir-times blib destdir]
  ok 11 - ordered args
  # Checking [rsync --archive --omit-dir-times --itemize-changes --no-perms 
--exclude=.*.swp --filter=:- .gitignore --delete blib destdir]
  ok 12 - more ordered args
  1..12
  # Looks like you failed 2 tests of 12.

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

Bug#801491: youtube-dl: does not work on Soundcloud.com, please check

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: youtube-dl
Version: 2015.06.04.1-1
Severity: minor

Dear Maintainer,

I tried to use youtube-dl on Soundcloud.com:

> andrew@a68n:~$ youtube-dl -v
> https://soundcloud.com/gillespeterson/gilles-peterson-dj-set-precious-hall-japan-5th-oct-2015
> [debug] System config: [] [debug] User config: []
> [debug] Command-line args: [u'-v',
> u'https://soundcloud.com/gillespeterson/gilles-peterson-dj-set-precious-hall-japan-5th-oct-2015']
> [debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8 [debug] 
> youtube-dl
> version 2015.06.04.1 [debug] Python version 2.7.9 -
> Linux-4.1.6-adl-x86_64-with-debian-8.2 [debug] exe versions: avconv 11.4-6, 
> avprobe
> 11.4-6, rtmpdump 2.4 [debug] Proxy map: {}
> [soundcloud] 
> gillespeterson/gilles-peterson-dj-set-precious-hall-japan-5th-oct-2015:
> Resolving id [soundcloud]
> gillespeterson/gilles-peterson-dj-set-precious-hall-japan-5th-oct-2015: 
> Downloading
> info JSON ERROR: Unable to download JSON metadata: HTTP Error 401: 
> Unauthorized (caused
> by HTTPError()); please report this issue on https://yt-dl.org/bug . Make 
> sure you are
> using the latest version; see  https://yt-dl.org/update  on how to update. Be 
> sure to
> call youtube-dl with the --verbose flag and include its complete output. File
> "/usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py", line 312, 
> in
> _request_webpage return self._downloader.urlopen(url_or_request) File
> "/usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py", line 1730, in 
> urlopen
> return self._opener.open(req, timeout=self._socket_timeout) File
> "/usr/lib/python2.7/urllib2.py", line 437, in open response = meth(req, 
> response) File
> "/usr/lib/python2.7/urllib2.py", line 550, in http_response 'http', request, 
> response,
> code, msg, hdrs) File "/usr/lib/python2.7/urllib2.py", line 475, in error 
> return
> self._call_chain(*args) File "/usr/lib/python2.7/urllib2.py", line 409, in 
> _call_chain
> result = func(*args) File "/usr/lib/python2.7/urllib2.py", line 558, in
> http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
> 

I's not workable. I used Iceweasel's inspector instead and looked at the 
network-tab,
copied the file-URL from there and could download it with wget:

> wget
> https://ec-media.sndcdn.com/PqqpdYUj66tt.128.mp3?f10880d39085a94a0418a7ef69b03d522cd6dfee9399eeb9a52205986bfeb73fc52f83f573e11f44be4da0fbde89cc04819be69876eb8f071849add4f42ff6024d9b45185f

It works perfectly fine for me, the only problem there is the cryptic filename 
that needs
to be changed, it also didn't download slowly, but at 3+ MB/s.

I really don't know whether this is too difficult to do it by script, if so 
then please
remove Soundcloud from the list of supported sites. 


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

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

Versions of packages youtube-dl depends on:
ii  python2.7.9-1
ii  python-pkg-resources  5.5.1-1
pn  python:any

Versions of packages youtube-dl recommends:
ii  curl7.38.0-4+deb8u2
ii  libav-tools 6:11.4-1~deb8u1
ii  mplayer2 [mplayer]  2.0-728-g2c378c7-4+b1
ii  rtmpdump2.4+20150115.gita107cef-1
ii  wget1.16-1

youtube-dl suggests no packages.

- -- no debconf information
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlYaD9kACgkQ5+rBHyUt5wsvBwCfSvIc0qYFWw7PVFCk7cwFO7ai
1wEAnjJ12cISYvcImi72RZGwqVsGrjpN
=XmQj
-END PGP SIGNATURE-

Bug#801462: POT templates compressed twice

[Camaleón]

El 2015-10-11 a las 07:17 +0200, Christian PERRIER escribió:

> Quoting Camaleón (noela...@gmail.com):
> > Package: debian-i18n
> > Severity: minor
> > Tags: l10n
> > 
> > Hello,
> > 
> > As reported at "debian-l10n-english" mailing list¹, it looks like POT 
> > templates² uploaded here are compressed twice:
> 
> Not really:
> 
> cperrier@mykerinos:~/tmp $ wget -nd 
> http://i18n.debian.org/material/po/unstable/main/d/dyfi/debian/po/dyfi_1.2.0-2_templates.pot.gz
> --2015-10-11 07:12:37--  
> http://i18n.debian.org/material/po/unstable/main/d/dyfi/debian/po/dyfi_1.2.0-2_templates.pot.gz

(...)

> cperrier@mykerinos:~/tmp $ gzip -d dyfi_1.2.0-2_templates.pot.gz 
> cperrier@mykerinos:~/tmp $ file dyfi_1.2.0-2_templates.pot 
> dyfi_1.2.0-2_templates.pot: GNU gettext message catalogue, ASCII text

I see.

> The problem seems to happen when people download these files from their
> web browser.

Curiously, other POT files are downloaded from browser okay:

http://i18n.debian.org/material/templates/unstable/main/d/dyfi/dyfi_1.2.0-2_debian_templates.gz

Mmm... I found this Firefox bug for the issue:

***
Tarball is double gzipped when downloaded with Firefox 
https://bugzilla.mozilla.org/show_bug.cgi?id=610679
***

But as comment #29 and next messages suggest, maybe we can do something 
at server side to avoid this from happening. By reading the comments, 
looks like Apache settings on this regard do make a difference.

Greetings,

-- 
Camaleón 

Bug#800101: libeigen3-dev: CholmodSupport.h uses UF_long which has been removed in SuiteSparse 4.4

[Anton Gladky]

forwarded 800101 http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1086
thanks

Reported upstream.

Anton

Bug#801052: midori: Midori dies with SIGILL right after loading Wikipedia page

[Andreas Neudecker]

Package: midori
Version: 0.5.11-2
Followup-For: Bug #801052

Hi Sergio.

I have now installed the debug-packages for the libs as you requested.

Here is a debug output from LMDE2. Will add the output from my Debian stretch
machine later.

Regards

Andreas


-- 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=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages midori depends on:
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-18+deb8u1
ii  libcairo2   1.14.0-2.1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-3+deb8u1
ii  libgck-1-0  3.14.0-2
ii  libgcr-base-3-1 3.14.0-2
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u2
ii  libglib2.0-02.42.1-1
ii  libgtk2.0-0 2.24.25-3
ii  libjavascriptcoregtk-1.0-0  2.4.8-2
ii  libp11-kit0 0.20.7-1
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0   1.36.8-3
ii  libsoup-gnome2.4-1  2.48.0-1
ii  libsoup2.4-12.48.0-1
ii  libsqlite3-03.8.7.1-1+deb8u1
ii  libwebkitgtk-1.0-0  2.4.8-2
ii  libx11-62:1.6.2-3
ii  libxml2 2.9.1+dfsg1-5
ii  libxss1 1:1.2.2-1
ii  libzeitgeist-2.0-0  0.9.14-2.2

Versions of packages midori recommends:
ii  gnome-icon-theme  3.12.0-1

midori suggests no packages.

-- no debconf information

*** /home/andreas/midori_-g_crashreport_2015-10-11.txt
0xac833655 in ?? ()
#0  0xac833655 in ?? ()
#1  0xb4c4484b in llint_op_call () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#2  0xaa33ad80 in ?? ()
#3  0xb4c4484b in llint_op_call () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#4  0xaa14a600 in ?? ()
#5  0xb4c44907 in llint_op_construct () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#6  0xaa14a780 in ?? ()
#7  0xb4c4484b in llint_op_call () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#8  0xaa13c300 in ?? ()
#9  0xb4c4484b in llint_op_call () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#10 0xaa13c480 in ?? ()
#11 0xb4c4484b in llint_op_call () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#12 0xaa2f9480 in ?? ()
#13 0xb4c412a9 in callToJavaScript () from /usr/lib/i386-linux-
gnu/libjavascriptcoregtk-1.0.so.0
#14 0xaa2f9600 in ?? ()
#15 0xb4bdd786 in JSC::JITCode::execute (this=0xaa35bf00, vm=0xb0be7000,
protoCallFrame=0xbfffe078, topOfStack=0xaaff6ff8) at
.../Source/JavaScriptCore/jit/JITCode.cpp:48
#16 0xb4bc0a13 in JSC::Interpreter::execute (this=0xb0ba5870,
program=0xac84b240, callFrame=0xaab6fa64, thisObj=0xaab8ffe0) at
.../Source/JavaScriptCore/interpreter/Interpreter.cpp:906
#17 0xb4d0d91e in JSC::evaluate (exec=0xaab6fa64, source=..., thisValue=...,
returnedException=0xbfffe5ec) at
.../Source/JavaScriptCore/runtime/Completion.cpp:82
#18 0xb5bd7041 in evaluate (exception=0xbfffe5ec, thisValue=..., source=...,
exec=0xaab6fa64) at ../Source/WebCore/bindings/js/JSMainThreadExecState.h:62
#19 WebCore::ScriptController::evaluateInWorld (this=0x8fbace8, sourceCode=...,
world=...) at ../Source/WebCore/bindings/js/ScriptController.cpp:147
#20 0xb5bd7315 in WebCore::ScriptController::evaluate (this=0x8fbace8,
sourceCode=...) at ../Source/WebCore/bindings/js/ScriptController.cpp:163
#21 0xb5da398c in WebCore::ScriptElement::executeScript (this=0xaa35e624,
sourceCode=...) at ../Source/WebCore/dom/ScriptElement.cpp:310
#22 0xb5da3c76 in WebCore::ScriptElement::prepareScript (this=0xaa35e624,
scriptStartPosition=...,
supportLegacyTypes=WebCore::ScriptElement::DisallowLegacyTypeInTypeAttribute)
at ../Source/WebCore/dom/ScriptElement.cpp:241
#23 0xb5f85c01 in WebCore::HTMLScriptRunner::runScript (this=0xb0c09a00,
script=0xaa35e5f0, scriptStartPosition=...) at
.../Source/WebCore/html/parser/HTMLScriptRunner.cpp:302
#24 0xb5f86573 in WebCore::HTMLScriptRunner::execute (this=0xb0c09a00,
scriptElement=..., scriptStartPosition=...) at
.../Source/WebCore/html/parser/HTMLScriptRunner.cpp:175
#25 0xb5f6f804 in WebCore::HTMLDocumentParser::runScriptsForPausedTreeBuilder
(this=0xb0c43e00) at ../Source/WebCore/html/parser/HTMLDocumentParser.cpp:218
#26 0xb5f6f8b5 in WebCore::HTMLDocumentParser::canTakeNextToken
(this=0xb0c43e00, mode=WebCore::HTMLDocumentParser::AllowYield, session=...) at
.../Source/WebCore/html/parser/HTMLDocumentParser.cpp:237
#27 0xb5f7215a in WebCore::HTMLDocumentParser::pumpTokenizer (this=0xb0c43e00,
mode=WebCore::HTMLDocumentParser::AllowYield) at
.../Source/WebCore/html/parser/HTMLDocumentParser.cpp:293
#28 0xb5f7244c in WebCore::HTMLDocumentParser::pumpTokenizerIfPossible
(this=0xb0c43e00, 

Bug#800370: python3.4: namedtuple does not have __dict__ attr any more

[Matthias Klose]

On 28.09.2015 16:49, James Tocknell wrote:

Package: python3.4
Version: 3.4.3-9
Severity: normal

collections.namedtuple appears to not to create namedtuples which have the
__dict__ attribute any more. Given that the stdlib docs stated that using
vars() (and hence the existence of __dict__) was preferred, it seems odd that
it has disappeared.


which was the last version which had this behaviour?

Bug#801497: docdiff: non-free file "devutil/JIS0208.TXT"

[Dmitry Smirnov]

Source: docdiff
Version: 0.5.0-1
Severity: serious

File "devutil/JIS0208.TXT" appears to be non-free:


#   This file is provided as-is by Unicode, Inc. (The Unicode Consortium).
#   No claims are made as to fitness for any particular purpose.  No
#   warranties of any kind are expressed or implied.  The recipient
#   agrees to determine applicability of information provided.  If this
#   file has been provided on magnetic media by Unicode, Inc., the sole
#   remedy for any claim will be exchange of defective media within 90
#   days of receipt.
#
#   Recipient is granted the right to make copies in any form for
#   internal distribution and to freely use the information supplied
#   in the creation of products supporting Unicode.  Unicode, Inc.
#   specifically excludes the right to re-distribute this file directly
#   to third parties or other organizations whether for profit or not.


Please investigate.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


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

Bug#794311: KiCad 4.0 rc1

[Nick Østergaard]

2015-10-10 19:00 GMT+02:00 Bas Wijnen :

>> - The KiCAD developers have designated their new stable release as 4.0. 
>> Debian
>> currently uses a date+revision version scheme. Should the Debian versioning 
>> be
>> changed to reflect this? What is the proper way to do so? 4.0+bzr is what
>> I currently use. Good/bad idea?
>
> If you're packaging the upstream release, you should use the version without
> revision.  If they are preparing for the release, so you are packaging a
> checkout of code that will be released at some point as 4.0, you should use
> 4.0~revision (which can be called whatever you want, as long as it is
> monotonically increasing).  Using ~ instead of + has the effect that it sorts
> before "4.0", so when that is released it will be the newest version.
>
> If you're packaging a checkout which is based on the released version, you
> should use + (or at least not ~), because then your version should be greater
> than "4.0".
>
> I thought their code was on github?  Using "bzr" sounds strange in that case;
> "git" would make more sense.

The main kicad source is still on bzr on launchpad but there is a
mirror called kicad-source-mirror on github.

Nick

Bug#801503: ansiweather: parse error: Invalid numeric literal at line 1, column 8

[Jakub Wilk]

Package: ansiweather
Version: 1.04-1
Severity: grave
Control: forwarded -1 https://github.com/fcambus/ansiweather/issues/82

ansiweather no longer works:

$ ansiweather
parse error: Invalid numeric literal at line 1, column 8
ERROR : Cannot fetch weather data for the given location


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

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

Versions of packages ansiweather depends on:
ii  bc1.06.95-9
ii  curl  7.45.0-1
ii  jq1.4-2.1
ii  wget  1.16.3-3

--
Jakub Wilk

Bug#801487: introducing xserver-xorg-legacy without telling anybody?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: xorg-server
Version: 2:1.17.2-3

Please either depend or recommend xserver-xorg-legacy. It
is *extremely* painful if you login next morning after the
upgrade and xinit doesn't work anymore and you have no web
interface to find out WTH has been changed.

Sorry to say, but this was *highly* annoying. Please don't
break things by default.


Thanx
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWGgKaAAoJEAqeKp5m04HLRHkH/AsZ+CNc6FjbdJKKn1iwBvVc
cLVNpE1bZlx+3JZ0WJSa+ZgajdAZUMTqcRfNkjfe606Cvs1Xnc4VrL7lpwV1dUN5
K+TUs/U1M7QemVMJxVBPdzMd7ouKKmac0BeCfeZa3H+wNNm0s5uQbSMJJAojTIXk
5p7hVzLPworLx1zF9Md+t2R2moFvIMC9BqZODZTIqWn5eQQ3+xy2aXtFDDMf1vm8
c8Xim3vAjBmfwa2ZSR42moNeqdwboLJDkRauRmI44gpewHiBOadGGUsZkI4pp/03
+uFgpcEJ5Ui37tF1ct7OqK6vHRy5NT/Rja4WgWX1t0lI0v0w7YUekTU3LTWit9w=
=B3wl
-END PGP SIGNATURE-

Bug#801489: htmlcxx: FTBFS on ppc64: Update symbols to build on ppc64

[Hiroyuki Yamamoto]

Source: htmlcxx
Version: 0.85-3.4
Severity: important
Tags: patch
Usertags: ppc64

FTBFS on ppc64, as follows:
https://buildd.debian.org/status/package.php?p=htmlcxx=sid
https://buildd.debian.org/status/fetch.php?pkg=htmlcxx=ppc64=0.85-3.4=1442123463

Please update symbols of debian/libcss-parser-pp0v5.symbols.

Here is a patch attached that was checked building succeeded.

Regards,
-- 
Hiroyuki Yamamoto
A75D B285 7050 4BF9 AEDA  91AC 3A10 59C6 5203 04DC
diff -Nurd htmlcxx-0.85.orig/debian/libcss-parser-pp0v5.symbols htmlcxx-0.85/debian/libcss-parser-pp0v5.symbols
--- htmlcxx-0.85.orig/debian/libcss-parser-pp0v5.symbols	2015-08-16 22:43:07.0 +0900
+++ htmlcxx-0.85/debian/libcss-parser-pp0v5.symbols	2015-10-11 15:46:17.671766720 +0900
@@ -31,12 +31,12 @@
  (optional)_ZNSt6vectorIN7htmlcxx3CSS6Parser8SelectorESaIS3_EED1Ev@Base 0.83
  (optional)_ZNSt6vectorIN7htmlcxx3CSS6Parser8SelectorESaIS3_EED2Ev@Base 0.83
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N7htmlcxx3CSS6Parser9AttributeEESt10_Select1stISC_ESt4lessIS5_ESaISC_EE24_M_get_insert_unique_posERS7_@Base 0.85
- (arch-bits=64|arch=!s390x)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N7htmlcxx3CSS6Parser9AttributeEESt10_Select1stISC_ESt4lessIS5_ESaISC_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorISC_ERS7_@Base 0.85
+ (arch-bits=64|arch=!ppc64 !s390x)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N7htmlcxx3CSS6Parser9AttributeEESt10_Select1stISC_ESt4lessIS5_ESaISC_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorISC_ERS7_@Base 0.85
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N7htmlcxx3CSS6Parser9AttributeEESt10_Select1stISC_ESt4lessIS5_ESaISC_EE7_M_copyINSI_11_Alloc_nodeEEEPSt13_Rb_tree_nodeISC_EPKSM_SN_RT_@Base 0.85
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N7htmlcxx3CSS6Parser9AttributeEESt10_Select1stISC_ESt4lessIS5_ESaISC_EE8_M_eraseEPSt13_Rb_tree_nodeISC_E@Base 0.85
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE24_M_get_insert_unique_posERS7_@Base 0.85
- (arch-bits=64|arch=!s390x)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS8_ERS7_@Base 0.85
+ (arch-bits=64|arch=!ppc64 !s390x)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS8_ERS7_@Base 0.85
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base 0.85
  _ZNSt8_Rb_treeISt6vectorIN7htmlcxx3CSS6Parser8SelectorESaIS4_EESt4pairIKS6_St3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS3_9AttributeESt4lessISF_ESaIS7_IKSF_SG_St10_Select1stISN_ESH_IS6_ESaISN_EE24_M_get_insert_unique_posERS8_@Base 0.85
- (arch-bits=64|arch=!s390x)_ZNSt8_Rb_treeISt6vectorIN7htmlcxx3CSS6Parser8SelectorESaIS4_EESt4pairIKS6_St3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS3_9AttributeESt4lessISF_ESaIS7_IKSF_SG_St10_Select1stISN_ESH_IS6_ESaISN_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorISN_ERS8_@Base 0.85
+ (arch-bits=64|arch=!ppc64 !s390x)_ZNSt8_Rb_treeISt6vectorIN7htmlcxx3CSS6Parser8SelectorESaIS4_EESt4pairIKS6_St3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS3_9AttributeESt4lessISF_ESaIS7_IKSF_SG_St10_Select1stISN_ESH_IS6_ESaISN_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorISN_ERS8_@Base 0.85
  free_rulesets@Base 0.83

Bug#801376: [Reproducible-builds] Depends is non-deterministically python3.5 or python3

[Chris Lamb]

Hi Scott,

> I've fixed this as described above and uploaded to experimental.

Tested it here and it works for me. Thanks, Scott.

In case it saves someone a couple of moments looking it up, this appears
to be the pertinent change:

  
https://alioth.debian.org/scm/loggerhead/pkg-python/python3-defaults-debian/revision/331#debian/py3versions.py


Regards,

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

Bug#801376: [Reproducible-builds] Depends is non-deterministically python3.5 or python3

[Chris Lamb]

Hi Scott,

> I've fixed this as described above and uploaded to experimental.

Tested it here and it works for me. Thanks, Scott.

In case it saves someone a couple of moments looking it up, this appears
to be the pertinent change:

  
https://alioth.debian.org/scm/loggerhead/pkg-python/python3-defaults-debian/revision/331#debian/py3versions.py


Regards,

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

Bug#801494: debian-live: does not include cryptsetup-bin so cannot mount encrypted drives

[Julian Gilbey]

Package: debian-live
Version: 8.2.0
Severity: normal

Hello there!

The disk images allow for detection of encrypted disks, but because
the cryptsetup-bin package is not included, they cannot actually be
mounted.  I wanted to attach an encrypted USB drive to do a backup and
could not do so.  The dependencies of this package are already
included in the images, and the package itself is very small.

Thanks,

   Julian

Bug#800814: Two-stage debootstrap not working in 0.7.0

[Vincent Bernat]

 ❦  3 octobre 2015 23:39 +0200, Vincent Bernat  :

> Starting with 0.7.0, the two-stage bootstrap doesn't work anymore with
> sid (didn't test another suite):
>
> cdebootstrap --foreign --flavour=build sid /var/tmp/sid
> chroot /var/tmp/sid /sbin/cdebootstrap-foreign
>
> [...]
> Unpacking mawk (1.3.3-17) over (1.3.3-17) ...
> dpkg: regarding .../base-files_9.4_amd64.deb containing base-files, 
> pre-dependency problem:
>  base-files pre-depends on awk
>   mawk provides awk but is unpacked but not configured.
>
> dpkg: error processing archive /var/cache/bootstrap/base-files_9.4_amd64.deb 
> (--install):
>  pre-dependency problem - not installing base-files
> [...]
> Errors were encountered while processing:
>  /var/cache/bootstrap/base-files_9.4_amd64.deb
> Failed to run dpkg!
>
> It works fine with cdebootstrap 0.6.5. I didn't investigate more since
> I am not familiar with those pre-dependencies stuff.

Without --foreign, the list of packages used for dpkg --unpack and the
list of packages for dpkg --install is different (no mawk or basefiles
in the second set). With --foreign, the two lists are identical.

I suppose that the paths taken with and without --foreign in
action_install_essential() are different, but I am unable to follow the
logic.

Any hint?
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

[Cornelius Kölbel]

Hi Daniel,

thanks a lot for all the valuable feedback.

I will dive into it later.

Do you have any further recommendations on finding a sponser (after
streamlining the package)?

THanks a lot and kind regards
Cornelius

Am Sonntag, den 11.10.2015, 00:18 +0200 schrieb Daniel Stender:
> Hi Cornelius,
> 
> I can't sponsor an upload of your work, but here are the results of my review
> of your package I was doing for my DD application process (I am CCing this 
> email
> to the application manager and the archives for this purpose).
> 
> Here are some collected suggestions for improvement,
> 
> 1) debian/changelog: the target distribution can't be "jessie". Jessie is the 
> current
> stable release, and new packages are not going to be added to that. If 
> there's no
> special reason to want to get uploaded into experimental you are heading for 
> unstable,
> codename "sid". But "unstable" is the suite resp. target name, which is going 
> to be
> used here [a].
> 
>[a] 
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#distribution
> 
> 2) debian/changelog: you have release information in the changelog entry of 
> your
> package, but debian/changelog is reserved for changes of the Debian version of
> the package [a]. For there are no changes on the package yet, "Initial 
> release"
> is all what's happening with this package.
> 
>[a] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
> 
> 3) debian/changelog: the ITP bug usually gets closed by the initial upload 
> through
> a "Closes:" in the deb/changelog, which should be added to the "Initial 
> release"
> line [a].
> 
>[a] https://lintian.debian.org/tags/new-package-should-close-itp-bug.html
> 
> 4) debian/watch: uscan scan fails because the watch line is missing the actual
> Perl regex pattern matching the tarball. But direct scanning of Pypi for 
> upstream
> tarballs is deprecated, anyway [a]. The Python team maintains a great Pypi
> redirector, which allows easy installation of a proper watch file [b]:
> $ curl -o debian/watch http://pypi.debian.net/privacyidea/watch
> 
>[a] 
> https://lintian.debian.org/tags/debian-watch-file-unsupported-pypi-url.html
> 
>[b] https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch
> 
> 5) debian/control: better is to use the current debhelper (>= 9~), that also 
> needs
> a bump of the compat level to "9" in debian/compat [a].
> 
>[a] 
> https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html
> 
> 6) debian/control: the "X-Python-Version" element doesn't belong in the 
> binary package
> section, but above into the source package section [a]
> 
>[a] 
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
> 
> 7) debian/control: though not mandatory nor recommended by the policy [a], if 
> the
> "Homepage:" field is present in the source package section, it's easy to 
> browse to
> it from the package tracker page.
> 
>[a] https://www.debian.org/doc/debian-policy/ch-controlfields.html
> 
> 8) debian/control: the build-dependency against python-setuptools is 
> redundant, and
> the versioning against >= 0.6b3 is obsolete, even oldstable has 0.6.24.
> 
> 9) debian/rules: since the tarball ships a testsuite, the tests should be run 
> during
> build time (for the package has a lot of dependencies, it would be great if 
> also a
> DEP-8 compatible test setup for Debian CI could be installed, even if you are 
> upstream
> [a,b]).
> 
>[a] 
> http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
> 
>[b] 
> http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debci_and_the_Debian_Continuous_Integration_project.webm
> 
> 10) debian/control: there are some errors in the package descriptions like 
> that
> "python" isn't capitalized, "authenticaion" etc. (please recheck and see the 
> related
> Lintian complaints). The description text looks like it's just a copy of the 
> program's
> documentation, and copyright statements should not be included here [a].
>
>[a] https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions
> 
> 11) debian/control: you've got Breaks and Replaces against a package 
> "privacyidea",
> but which isn't in the archive. I would guess that's a non-official package 
> around
> somewhere? I'm not sure if a use like that could be discussed, but another 
> use (maybe
> you mean the upstream version) would be unwanted, definitely [a].
> 
>[a] https://www.debian.org/doc/debian-policy/ch-relationships.html
> 
> 12) debian/rules: "python_distutils" is usually put by py2dsc/stdeb as 
> buildsystem
> but you might want to use "pybuild" (that's commonly used for new packages). 
> That
> also needs a build-dep on "dh-python" in debian/control (that's recommended 
> anyway
> when you run the dh sequencer "--with python2", see the complaint in the 
> 

Bug#750586: debian-8.2.0-amd64-DVD-1.iso

[Mikaela Suomalainen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I am able to reproduce this issue with debian-8.2.0-amd64-DVD-1.iso
using older desktop PC which is from year 2006.

I thought Debian would be good for a little older PC and I wouldn't
have to worry about it so much, but it appears I must find another
distribution as this bug has been open since 2014.

- -- 
Mikaela Suomalainen
https://mikaela.info
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Homepage: https://mikaela.info/
Comment: Fingerprint = 2910 4A46 C561 5BF9 78A0 83F2 0C20 7F07 B2F3 2B67

iQIcBAEBCgAGBQJWGi81AAoJEAwgfwey8ytnxYsP/30GPL3ypQ3U8XHwvhXDG+Fv
6Df0BaHs+yLdmWdyJiM1b//OHXFz/CdLWq5PWFTLu012OIDeTx+llhowQd3R6ZU8
nrEfwqfdliyGqZQmV331lzfria/revX8cSRICmGNiK3edLZQhOqY3M3OtBTvA+oH
8z5lyh95tDIJho/K1R+d9BRzmsTw9tS9iMoNLK042GfWX1gxqtTq+cnFLU4G6Btw
D7LbwRZWq6ey84aNMWa4PEQlaaHow6aG6PgGINAAdkDqCtAYpUgz+Q+kcMp1uR5A
K5PJkTJCBP7BzZf+um3S6/4p0jqkdZBZrgFC85AWrNF3yHCyRB09dahJKD97LEm/
FlJvhnEavp8BsOIygjat7cFRVj7JCVBQjlAKQzJmUPPH43NuE8D4yaTvAShnf5oD
jrKZgKFuENvYxprAbZFBAQP/0wAa203qFoB7AFklyTqsCpV5cCysKtJDpNtfLQT3
pG6+IQmjElQxLzzohceiSfgTxNiT2a3AA3PIWUGAazdeklxBvyTAevWIKjUwVBM3
5rpCvtw4s3G610XAAxfI7/6MKU0nOCvud5+FiP1NZGt9wAqmVLYGGMDsaU/b0pbT
shRqT54cF3jr+TtwQztZrz7gS0DBisIL4pe0GQTfu93Yk8n+3IQkbhIQJxw8g3oB
iIHo86563OlwE6/sjml1
=HD07
-END PGP SIGNATURE-

Bug#801496: python-cherrypy3: cherrypy ignores ssl encryption request

[Roland Haas]

Package: python-cherrypy3
Version: 3.5.0-2
Severity: normal
Tags: upstream

Dear Maintainer,

when asking for ssl encryption by cherrypy it delivers results using
unencrypted http rather than https. This is known upstream in 
https://bitbucket.org/cherrypy/cherrypy/issues/1298/ssl-not-working
and the workaround in
https://bitbucket.org/cherrypy/cherrypy/issues/1298/ssl-not-working#comment-9209835
works for me, but may affect other things according to the discussion
there.

A stand-alone test (adapted from the discussion in bitbucket) to
reproduce is:

--8<--
#!/bin/bash

openssl req -nodes -newkey rsa:2048 -keyout server.key -x509 \
 -days 3650 -out server.crt -subj "/CN=CherryPy"

(python 

Bug#801502: apt-offline: missing dependency on python-apt in jessie

[Paul Wise]

Package: apt-offline
Version: 1.5
Severity: serious
Control: fixed -1 1.6.1
Tags: patch

apt-offline appears to unconditionally use python-apt in jessie but
doesn't depend on it. The fix is to either depend on python-apt or:

Replace this from jessie:

#Instantiate Apt based on what we have. For now, fall to apt only
AptInst = AptManip(Str_SetArg, Simulate=Bool_TestWindows, 
AptType="python-apt")

With this from stretch:

        #Instantiate Apt based on what we have. For now, fall to apt only
if PythonApt is True:
AptInst = AptManip(Str_SetArg, Simulate=Bool_TestWindows, 
AptType="python-apt")
else:
AptInst = AptManip(Str_SetArg, Simulate=Bool_TestWindows, 
AptType="apt")
        

-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt-offline depends on:
ii  apt1.0.9.8.1
ii  less   458-3
ii  libpython2.7-stdlib [python-argparse]  2.7.9-2
ii  python 2.7.9-1

Versions of packages apt-offline recommends:
pn  python-magic   
ii  python-soappy  0.12.0-4

apt-offline suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#801504: Libreoffice-calc 5 closed after border style selected when used in i3-wm

[n n]

Package: libreoffice-calc
Version: 1:5.0.2-1~bpo8+1
Severity: important

Dear Maintainer,

The same libreoffice used by the same user on the same machine works fine,
when used in Gnome3. When used in i3-wm, after opening new spreadsheet:

1. select any cell,
2. click `border style` icon in menu,
3. from the list select any border style (solid line for example).

Libreoffice will be closed immediately. Recovery will be possible
after relaunch.

=
I've tried to report bug using bugreport but error occurs:

SMTP send failure: {'debian-backpo...@lists.debian.org': (550, 'relay
not permitted')}.
=

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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc32.8.12-1
ii  coinor-libcoinmp1 1.7.6+dfsg1-1
ii  libboost-iostreams1.55.0  1.55.0+dfsg-3
ii  libboost-system1.55.0 1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libicu52  52.1-8+deb8u3
ii  liblcms2-22.6-3+b3
ii  libodfgen-0.1-1   0.1.1-2
ii  libreoffice-base-core 1:5.0.2-1~bpo8+1
ii  libreoffice-core  1:5.0.2-1~bpo8+1
ii  librevenge-0.0-0  0.0.1-3
ii  libstdc++64.9.2-10
ii  libxml2   2.9.1+dfsg1-5
ii  lp-solve  5.5.0.13-7+b1
ii  uno-libs3 5.0.2-1~bpo8+1
ii  ure   5.0.2-1~bpo8+1
ii  zlib1g1:1.2.8.dfsg-2+b1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
pn  ocl-icd-libopencl1  

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.3
ii  fonts-opensymbol  2:102.6+LibO5.0.2-1~bpo8+1
ii  libatk1.0-0   2.14.0-1
ii  libboost-date-time1.55.0  1.55.0+dfsg-3
ii  libc6 2.19-18+deb8u1
ii  libcairo2 1.14.0-2.1
ii  libclucene-contribs1  2.3.3.4-4
ii  libclucene-core1  2.3.3.4-4
ii  libcups2  1.7.5-11+deb8u1
ii  libcurl3-gnutls   7.38.0-4+deb8u2
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libeot0   0.01-3
ii  libexpat1 2.1.0-6+deb8u1
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u2
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglew1.10   1.10.0-3
ii  libglib2.0-0  2.42.1-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgraphite2-31.2.4-3
ii  libgtk2.0-0   2.24.25-3
ii  libharfbuzz-icu0  0.9.35-2
ii  libharfbuzz0b 0.9.35-2
ii  libhunspell-1.3-0 1.3.3-3
ii  libhyphen02.8.8-1
ii  libice6   2:1.0.9-1+b1
ii  libicu52  52.1-8+deb8u3
ii  libjpeg62-turbo   1:1.3.1-12
ii  liblangtag1   0.5.1-3
ii  liblcms2-22.6-3+b3
ii  libldap-2.4-2 2.4.40+dfsg-1+deb8u1
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.1-1
ii  libnspr4  2:4.10.7-1
ii  libnss3   2:3.17.2-1.1+deb8u2
ii  libodfgen-0.1-1   0.1.1-2
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpng12-01.2.50-2+b2
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:5.0.2-1~bpo8+1
ii  librevenge-0.0-0  0.0.1-3
ii  libsm62:1.2.2-1+b1
ii  libssl1.0.0   1.0.1k-3+deb8u1
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.1+dfsg1-5
ii  libxrandr22:1.4.2-1+b1
ii  libxrender1   1:0.9.8-1+b1
ii  libxslt1.11.1.28-2+b2
ii  libxt61:1.1.4-1+b1
ii  uno-libs3 5.0.2-1~bpo8+1
ii  ure   5.0.2-1~bpo8+1
ii  zlib1g1:1.2.8.dfsg-2+b1

-- no debconf information

Bug#801493: game-data-packager: print list of missing files when --package is specified

[Alexandre Detiste]

Package: game-data-packager
Version: 2
Severity: normal

Dear maintainers,

When --package is specified, but the packaging fails
because some file(s) is/are a missing;
a list of missing files, with their possibles files/checksums
(when handling alternatives) should be printed so
that users know which files are missing.

In other cases, they'll have a file by the same name
but with different size/hashes; these are maybe extra
versions that should be documented in the .YAML files.

Alexandre



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/6 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)

Bug#570377: Aptitude removals

[Vincent Lefevre]

On 2015-10-11 21:36:19 +1300, Chris Tillman wrote:
> I bought a new (used) computer, and installed a new system. This annoying
> behaviour came back, of course, because I had set the old one up to get rid
> of it.
> 
> For anyone being affected by these bugs, or annoyed by removals being
> offered first, I'd suggest trying this in your ~/.aptitude/config file:
> 
> Aptitude "";
> Aptitude::ProblemResolver "";
> Aptitude::ProblemResolver::Remove-Level "10001";
[...]

In https://lists.debian.org/debian-user/2014/07/msg00398.html
Andrei POPESCU suggested:

  Aptitude::ProblemResolver::SolutionCost "removals";

but this can lead to downgrades:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762932

How does your solution behave compared to this one?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

[Alex Vong]

Hi Cornelius,

I recommend reading
 if you
haven't. The guide mentions suggestions 1), 2) and 3) mentioned by
Daniel and more.

Cheers,
Alex

On 11/10/2015, Cornelius Kölbel 
wrote:
> Hi Daniel,
>
> thanks a lot for all the valuable feedback.
>
> I will dive into it later.
>
> Do you have any further recommendations on finding a sponser (after
> streamlining the package)?
>
> THanks a lot and kind regards
> Cornelius
>
> Am Sonntag, den 11.10.2015, 00:18 +0200 schrieb Daniel Stender:
>> Hi Cornelius,
>>
>> I can't sponsor an upload of your work, but here are the
results of my
>> review
>> of your package I was doing for my DD application process (I am
 CCing this
>> email
>> to the application manager and the archives for this purpose).
>>
>> Here are some collected suggestions for improvement,
>>
>> 1) debian/changelog: the target distribution can't be "jessie".
 Jessie is
>> the current
>> stable release, and new packages are not going to be added to
that. If
>> there's no
>> special reason to want to get uploaded into experimental you
are heading
>> for unstable,
>> codename "sid". But "unstable" is the suite resp. target name,
which is
>> going to be
>> used here [a].
>>
>>[a]
>>
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#distribution
>>

>> 2) debian/changelog: you have release information in the
changelog entry
>> of your
>> package, but debian/changelog is reserved for changes of the
Debian
>> version of
>> the package [a]. For there are no changes on the package yet,
"Initial
>> release"
>> is all what's happening with this package.
>>
>>[a]
>>
http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
>>
>> 3) debian/changelog: the ITP bug usually gets closed by the
initial upload
>> through
>> a "Closes:" in the deb/changelog, which should be added to the
"Initial
>> release"
>> line [a].
>>
>>[a]
>>
https://lintian.debian.org/tags/new-package-should-close-itp-bug.html
>>
>> 4) debian/watch: uscan scan fails because the watch line is
missing the
>> actual
>> Perl regex pattern matching the tarball. But direct scanning of
 Pypi for
>> upstream
>> tarballs is deprecated, anyway [a]. The Python team maintains a
 great
>> Pypi
>> redirector, which allows easy installation of a proper watch
file [b]:
>> $ curl -o debian/watch http://pypi.debian.net/privacyidea/watch
>>
>>[a]
>>
https://lintian.debian.org/tags/debian-watch-file-unsupported-pypi-url.html
>>

>>[b]
https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch
>>
>> 5) debian/control: better is to use the current debhelper
(>= 9~), that
>> also needs
>> a bump of the compat level to "9" in debian/compat [a].
>>
>>[a]
>>
https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html
>>

>> 6) debian/control: the "X-Python-Version" element doesn't
belong in the
>> binary package
>> section, but above into the source package section [a]
>>
>>[a]
>>
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
>>

>> 7) debian/control: though not mandatory nor recommended by the
policy [a],
>> if the
>> "Homepage:" field is present in the source package section,
it's easy to
>> browse to
>> it from the package tracker page.
>>
>>[a]
https://www.debian.org/doc/debian-policy/ch-controlfields.html
>>
>> 8) debian/control: the build-dependency against
python-setuptools is
>> redundant, and
>> the versioning against >= 0.6b3 is obsolete, even oldstable
has 0.6.24.
>>
>> 9) debian/rules: since the tarball ships a testsuite, the tests
 should be
>> run during
>> build time (for the package has a lot of dependencies, it would
 be great
>> if also a
>> DEP-8 compatible test setup for Debian CI could be installed,
even if you
>> are upstream
>> [a,b]).
>>
>>[a]
>>
http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
>>

>>[b]
>>
http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debci_and_the_Debian_Continuous_Integration_project.webm
>>

>> 10) debian/control: there are some errors in the package
descriptions like
>> that
>> "python" isn't capitalized, "authenticaion" etc. (please
recheck and see
>> the related
>> Lintian complaints). The description text looks like it's just a
 copy of
>> the program's
>> documentation, and copyright statements should not be included
here [a].
>>
>>[a]
>>
https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions
>>
>> 11) debian/control: you've got Breaks and Replaces against a
package
>> "privacyidea",
>> but which isn't in the archive. I would guess that's a
non-official
>> package around
>> somewhere? I'm not sure if a use like that could be discussed,
but another
>> use (maybe
>> you mean the upstream version) would be unwanted, definitely
[a].
>>
>>[a]

Bug#800769: pbuilder: conffiles not removed

[Wouter Verhelst]

On Sat, Oct 10, 2015 at 04:30:28PM +, Mattia Rizzolo wrote:
> Hi fellows debian-devel@ lurkers!
> 
> On Sat, Oct 03, 2015 at 09:03:46PM +, Mattia Rizzolo wrote:
> > On Sat, Oct 03, 2015 at 02:33:09PM +0200, Paul Wise wrote:
> > > The recent upgrade did not deal with obsolete conffiles properly.
> > > Please use the dpkg-maintscript-helper support provided by dh_installdeb
> > > to remove these obsolete conffiles on upgrade.
> > > 
> > > https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
> > > http://manpages.debian.org/man/1/dh_installdeb
> > > 
> > > $ pkg=pbuilder ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
> > > grep obsolete
> > > pbuilder: obsolete-conffile /etc/pbuilder/pbuilder-uml.conf
> > >  /etc/pbuilder/pbuilder-uml.conf ce1832f09d721efe29b92ec153fa4410 obsolete
> > 
> > oh, gosh
> > All this just for fucking up with the arch:all buildd :\
> > 
> > This happened because the 0.217 was the first version being built by the
> > arch:all autobuilder, but the code that moved that file away was run
> > only for arch-indep builds, so it did not run there; the 0.218 was
> > uploaded exactly to fix that issue, but 0.217 was already in the wild
> > with that bogus file.
> > 
> > That file is supposed to be only on pbuilder-uml binary, so I can't just
> > use rm_conffiles to remove it in pbuilder, as that would blindly remove
> > it while pbuilder-uml might be using it.
> > 
> > How do you suggest to handle this?
> 
> Do you happen to have ides?
> What actually needs to happen is to hand a conffile over to another
> package, but neither me or pabs have a clue on how to do that.

The only way to hand a file (any file) over to another package is by way of
'Replaces:', *without* the Conflicts: and Provides:.

Since this is a single packaga version, you could put the file in pbuilder-uml
and have that 'Replaces: pbuilder (= 0.217)', that way the possible damage in
case you have other (accidental) file conflicts would be limited.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Bug#800370: python3.4: namedtuple does not have __dict__ attr any more

[Matthias Klose]

Control: forwarded -1 http://bugs.python.org/issue24931
Control: tags -1 + upstream

On 11.10.2015 12:06, Matthias Klose wrote:

which was the last version which had this behaviour?

Bug#709754: Erlang runtime implicitly starts a epmd daemon

[Philipp Huebner]

Hi

Am 10.10.2015 um 07:26 schrieb Sergei Golovan:
> The epmd daemon is still masked by default, so I'll not close this bug
> yet. I'm thinking about unmasking it but I'm afraid it'll confuse
> users who don't need and never use any distributed Erlang application.

AFAICT it's not masked, but simply disabled, at least on the Sid systems
where I installed erlang-base.

So it's not automatically started via systemd, but when another service
like ejabberd requires it, it is.

ejabberd.service contains:
 After=epmd.service network.target
 Requires=epmd.service


The only question that remains: what happens if other apps want to start
epmd? Is it always caught through epmd.socket and started via systemd or
is epmd then started again under an untrusted user?


Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#801498: rakudo: Native libraries and paths

[gregor herrmann]

Package: rakudo
Version: 2015.09-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Maybe this is a user error, or maybe there's something wrong around
NativeCall and the paths it looks in ...

* rakudo, moarvm, nqp from unstable as of today
* panda from git (2015.09 tag)

% /home/gregoa/.perl6/2015.09/bin/panda install Linenoise
==> Fetching Linenoise  
   
==> Building Linenoise
gcc -c -fPIC -Wdeclaration-after-statement -Werror=declaration-after-statement 
-O3 -DNDEBUG -g3  -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-o linenoise.o linenoise.c
gcc -shared -fPIC  -O3 -DNDEBUG -g3 -Wl,-rpath,/usr/lib/moar 
-Wl,-rpath,/usr/lib/perl6/site/lib -Wl,-z,relro -Wl,-z,now -ltommath 
-latomic_ops -lm -lpthread -lrt -ldl -o 
/home/gregoa/src/git-pkg-perl/meta/packages/libperl-apireference-perl/.panda-work/1444559283_1/blib/lib/liblinenoise.so
 linenoise.o
gcc -o constant-helper -Wdeclaration-after-statement 
-Werror=declaration-after-statement -O3 -DNDEBUG -g3  -D_REENTRANT 
-D_FILE_OFFSET_BITS=64 -fPIC -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 constant-helper.c
perl6 fill-constants.pl < lib/Linenoise.pm.in > lib/Linenoise.pm
==> Testing Linenoise
==> Installing Linenoise
Copying blib/lib/Linenoise.pm to /home/gregoa/.perl6/2015.09/lib/Linenoise.pm
Copying blib/lib/Linenoise.pm.in to 
/home/gregoa/.perl6/2015.09/lib/Linenoise.pm.in
Copying blib/lib/liblinenoise.so to 
/home/gregoa/.perl6/2015.09/lib/liblinenoise.so
==> Successfully installed Linenoise

So far so good. But calling perl6 ends with:

% perl6
===SORRY!===
Cannot locate native library 'liblinenoise.so': liblinenoise.so: cannot open 
shared object file: No such file or directory


Using strace we see that /home/gregoa/.perl6/2015.09/lib/Linenoise.pm
is opened, and then NativeCall looks everywhere but not in
/home/gregoa/.perl6/2015.09/lib/ where liblinenoise.so would be:

open("/home/gregoa/.perl6/2015.09/lib/Linenoise.pm", O_RDONLY|O_CLOEXEC) = 13
open("/usr/share/perl6/lib/NativeCall.pm.moarvm", O_RDONLY|O_CLOEXEC) = 13
open("/usr/share/perl6/lib/NativeCall/Types.pm.moarvm", O_RDONLY|O_CLOEXEC) = 13
open("/usr/share/perl6/lib/NativeCall/Compiler/GNU.pm.moarvm", 
O_RDONLY|O_CLOEXEC) = 13
open("/usr/share/perl6/lib/NativeCall/Compiler/MSVC.pm.moarvm", 
O_RDONLY|O_CLOEXEC) = 13
open("/usr/lib/moar/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/moar/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 13
open("/lib/x86_64-linux-gnu/tls/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/tls/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/liblinenoise.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/lib/tls/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
open("/lib/tls/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
open("/lib/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/lib/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/tls/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/x86_64/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/moar/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/moar/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 13
open("/lib/x86_64-linux-gnu/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
open("/usr/lib/x86_64-linux-gnu/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
open("/lib/liblinenoise.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)

Bug#801501: libqt5sql5: libQt5 segfault when computer resumes from standby

[Xavier Guimard]

Package: libqt5sql5
Version: 5.4.2+dfsg-9
Severity: normal

Hi all,

When my laptop (MacBook AIr) resumes from standby, KDE crashes if it was
opened before standby. No problem when kdm is closed. If session is
closed but kdm open, sometimes it works fine, sometimes not.
Looking logs, I found each time the following line in kern.log:

[  948.387826] kactivitymanage[1515]: segfault at 7f458c022cd0 ip
7f458695f1b1 sp 7ffd92065b18 error 4 in
libQt5Sql.so.5.4.2[7f458694b000+3f000]]

I had a look at #796708, but patch seems not to be compliant with
testing/unstable version

Best regards,
Xavier

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

Kernel: Linux 4.2.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)

Versions of packages libqt5sql5 depends on:
ii  libc62.19-22
ii  libqt5core5a [qtbase-abi-5-4-2]  5.4.2+dfsg-9
ii  libstdc++6   5.2.1-21

Versions of packages libqt5sql5 recommends:
ii  libqt5sql5-sqlite  5.4.2+dfsg-9

libqt5sql5 suggests no packages.

-- no debconf information

Bug#801486: smartmontools: please upload smartmontools 6.4 version or 6.4+svn4136 in debian

[shirish शिरीष]

Package: smartmontools
Version: 6.3+svn4002-2+b3
Severity: wishlist

Dear Maintainer,
Please upload smartmontools 6.4 version or the latest bleeding edge
6.4+svn4136 in Debian. You can get the stable released version 6.4 as
seen at http://www.smartmontools.org/browser/tags/RELEASE_6_4/smartmontools/NEWS
. Can we have that at the very least . The bugfixes for 6.4 can be
seen at http://www.smartmontools.org/query?milestone=Release+6.4

The other way is to get the bleeding edge which has these fixes
http://www.smartmontools.org/query?status=closed=resolution=Release+6.5

Maybe one of those fixes some of the important issues reported in
smartmontools.

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

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


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#800590: game-data-packager: support for multi-CD games

[Alexandre Detiste]

Le jeudi 1 octobre 2015, 23:17:27 Stephen Kitt a écrit :
> On Thu, 01 Oct 2015 13:43:26 +0200, Alexandre Detiste
>  wrote:
> > Currently when someone package a multi-CD game
> > (e.g. Zork Inquisitor, Grim Fandango, Broken Sword);
> > user must either:
> > - have # CD reader where # = number of CD's to read
> > - copy all data from all CD somewhere (e.g. /tmp)
> >   before startging G-D-P
> > - mix the two, copy some data somewhere and
> >   read the rest from the CD
> 
> Some games are worse than that, e.g. for Discworld 2 you need to copy files
> from CD 1, rename some of them, and copy files from CD 2, and rename them
> (files share the same name across both CDs but have different content).
> 
> > G-D-P should allow user to scan a whole disk and
> > then process to the next one to locate remaining missing files.
> > ( many shared assets are duplicated across disks)
> 
> That would be fantastic!
> 
> Regards,
> 
> Stephen

I've added some minimalistic support for this;
it doesn't automate anything, but at least tell users how to do it manually.

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=76d26194fb44f410cee826539c57ccd08c241e4d

Can you add "disks:" tag for the other multi-CD games you know of ?

---

The "Quake CD + Expansion CD1 + Expansion CD2" *bundles* doesn't count as 
multi-CD games,
because they all can be packaged without the "copy all the data from all disks 
somewhere first" step.

The Quake CD would benefit from a new "--new" command line switch that would 
only package
new games not already installed on local system.

Without this the base Quake game would be packaged 3 times.

Regards,

Alexandre

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

Bug#788315: same problem in stretch

[Heiko Ernst]

can someone add this bug to stretch ?

Bug#801495: chromium looses all its saved passwords after kwalletd5 upgrade

[Jan Eringa]

Package: chromium
Version: 45.0.2454.101-1
Severity: important

Dear Maintainer,


   * What led up to the situation?
  plasma(kde5?) upgrade of kwalletmanager & kwalletd5

   * What exactly did you do (or not do) that was effective (or ineffective)?
  Moved the old kwallet kwl & salt files out of the way & allow chrome to 
rebuild the kwalle; no good as new kwallet manager can't open old kwallet 
versions so restore of data imposible

   * What was the outcome of this action?
  ~100 accounts and passwords which I can't find the passwords for, even 
the xml extract from the upgraded kwallet is no good as chrome mangles the data 
(pickled?)

   * What outcome did you expect instead?
  Even if chrome & kwallet can't agree on versions, it would be nice to be 
able to see what the data that chome stuffed into kwallet actually was, that 
way I could manually re-enter the accounts & passwords



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

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

Versions of packages chromium depends on:
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libavcodec-ffmpeg56   7:2.7.2-2+b1
ii  libavformat-ffmpeg56  7:2.7.2-2+b1
ii  libavutil-ffmpeg547:2.7.2-2+b1
ii  libc6 2.19-22
ii  libcairo2 1.14.2-2
ii  libcups2  2.1.0-4
ii  libdbus-1-3   1.10.0-3
ii  libexpat1 2.1.0-7
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgdk-pixbuf2.0-02.32.0-1
ii  libglib2.0-0  2.46.0-2
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.28-1
ii  libjpeg62-turbo   1:1.4.1-2
ii  libnspr4  2:4.10.9-2
ii  libnspr4-0d   2:4.10.9-2
ii  libnss3   2:3.20-1
ii  libpango-1.0-01.38.0-3
ii  libpangocairo-1.0-0   1.38.0-3
ii  libpci3   1:3.3.1-1
ii  libspeechd2   0.8-7
ii  libspeex1 1.2~rc1.2-1
ii  libsrtp0  1.4.5~20130609~dfsg-1.1
ii  libstdc++65.2.1-17
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxcursor1   1:1.1.14-1+b1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxi62:1.7.4-1+b2
ii  libxml2   2.9.2+zdfsg1-4
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.8-1+b1
ii  libxslt1.11.1.28-2+b2
ii  libxss1   1:1.2.2-1
ii  libxtst6  2:1.2.2-1+b1
ii  x11-utils 7.7+3
ii  xdg-utils 1.1.0~rc3+git20150922-1

chromium recommends no packages.

Versions of packages chromium suggests:
ii  chromium-l10n  45.0.2454.101-1

-- no debconf information

Bug#788315: same problem in stretch

[Ian Campbell]

On Sun, 2015-10-11 at 09:58 +0200, Heiko Ernst wrote:
> can someone add this bug to stretch ?

Please write another mail to 788...@bugs.debian.org with this
directive, before any other text (including quotes "On Sun... wrote"
etc):

Control: found -1 

e.g. if you tested 4.1.6-1 then write:

Control: found -1 4.1.6-1

This will tell the BTS what is going on and it will then know that
Stretch is affected.

Be sure to use the kernel package version and not the ABI version (the
latter of which will look like 4.1.6-2-amd64 or something like that).

"-1" is a shorthand for whichever nnn...@bugs.debian.org the mail is
addressed to, you can also spell it out in full.

You can also use the bts(1) from the devscripts package to do the same
thing. See https://www.debian.org/Bugs/ for more information on
manipulating bugs in the Debian BTS.
Ian.

Bug#788315: Control: found -1 4.2.0-1

[Heiko Ernst]

Control: found -1 4.2.0-1

Bug#801488: aptitude: crash when removing package which apt-get can remove without problem

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Nick,

2015-10-11 07:51 Nick Black:

Package: aptitude
Version: 0.7.3-1
Severity: important

Dear Maintainer,

Aptitude crashes when removing certain packages (not all), whether using
remove or purge, command line or curses UI. Apt-get can remove the same
package just fine. The issue seems possibly related to multiarch.

I ran:

sudo dpkg --add-architecture i386
sudo aptitude update

I then installed wine32:i386. I already had wine:amd64 and wine64:amd64
installed. I removed wine64:amd64 and wine64-bin:amd64 without problems.
Attempting to run

sudo aptitude -v -v -v purge wine

or

sudo aptitude -v -v -v purge wine32:i386

crashes with no output, just status 139, SIGSEGV. This is true whether I
use "purge" or "remove". No entry is made in
/var/log/aptitude/aptitude.log.


Can you please run the last step with (when it crashes) with valgrind or
gdb, and post the backtrace (automatic with valgrind, 'bt' inside gdb
after crashing)?

Also, can you post root's ~/.aptitude/config?


I suspect that it's a duplicate of #801430.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[James Lu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Hi everyone,

(Hoping this is the right list for this)

Recently I've been trying to get lightdm-gtk-greeter-settings into
Debian, since it's a nifty utility! Right now, my packaging work has an
RFS (request for sponsorship) bug at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790104. If there's
anyone interested in reviewing, the source is at mentors.d.n
 and Git
at
https://anonscm.debian.org/cgit/collab-maint/lightdm-gtk-greeter-settings.git.

Best,
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQIcBAEBCAAGBQJWGf0rAAoJEC7D9g3nHAudm/0P/iXi6JNQ40EF8N1gq+DfSUOz
Z3CJIoN0yvZ3ajj3sqWDFiwUmfvUoJJDAt6s4gxUw5YlPVY1Nr1/Qp+1RJGzidXG
nlduRVbzKUDj9dmwoK2EL+fehhHvK62SNjeDa1lXNcqJwdMtYUlfFqBFxMBPrVpM
UGY+ZwKPjkrBFfitHeJdRm1Qb1ytfmbhYXq1Hq4kLD7OxUUIOfWCjxRLVj3PLeaY
lex2EmGxH+qor5lvx40EwuP6+qtuXGQ/QQTmcBBy02ScqgIT5F/W+HxQxToOGqK5
PPoR3kCduACfadeNjOrFzJ3HfmUNx5mgd2Qb0BEytEQ398aBlzCWFn5+9GHQtnhw
+cgsmU4I318W6rS0AmkMStAGjI4rkHVTe2M56ZqOiAoHBTMBAwicU1bfP9gFpoLw
NE0HVzNLlnLjW1ktp6VaEVvJLfwHvRxOs1H05AkYCJKvA018BQlkNdAGwYkHSVw3
WZxt7oQfuYYA9H7HqE7D7TgU+4xKqZ9PQIw9CvioQb/gptbKFOqejcb+w8yeof5c
pd+6i8StGybuIvyBt/fEMobBSPEFb2YKnTtB8s1bQ8Wt5pYqqT8K3HrGWNNkc1xs
6Q6rBLdX+KEk1TqRfaU6nOYVxY2jdm9LqUS/ghByRnS6StichxFBt9Y7a2GEqN4R
y7Gyz7s4D2C8TIXZo1DJ
=2Iyo
-END PGP SIGNATURE-

Bug#799861: lintian: false positive in "source-is-missing" when dealing with .js

[Mechtilde]

Package: lintian
Version: 2.5.38
Followup-For: Bug #799861

I got the same messages when I built calendar-exchange-provider.

I use lintian -c -E -I --pedantic

here the output:

P: calendar-exchange-provider source: source-contains-prebuilt-javascript-
object components/erAutoDiscoverySOAP.js line length is 259 characters (>256)
E: calendar-exchange-provider source: source-is-missing
components/erAutoDiscoverySOAP.js
P: calendar-exchange-provider source: source-contains-prebuilt-javascript-
object components/erGetDelegateRequest.js line length is 557 characters (>256)
E: calendar-exchange-provider source: source-is-missing
components/erGetDelegateRequest.js
P: calendar-exchange-provider source: source-contains-prebuilt-javascript-
object chrome/content/exchangeSettings.js line length is 338 characters (>256)
E: calendar-exchange-provider source: source-is-missing
chrome/content/exchangeSettings.js
P: calendar-exchange-provider source: source-contains-prebuilt-javascript-
object chrome/content/messenger_task_delegation.js line length is 313
characters (>256)
E: calendar-exchange-provider source: source-is-missing
chrome/content/messenger_task_delegation.js



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

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

Versions of packages lintian depends on:
ii  binutils   2.25.1-3
ii  bzip2  1.0.6-8
ii  diffstat   1.60-1
ii  file   1:5.25-2
ii  gettext0.19.6-1
ii  hardening-includes 2.7
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.29+b3
ii  libarchive-zip-perl1.53-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.38-1
ii  libdpkg-perl   1.18.3
ii  libemail-valid-perl1.196-1
ii  libfile-basedir-perl   0.07-1
ii  libipc-run-perl0.94-1
ii  liblist-moreutils-perl 0.413-1
ii  libparse-debianchangelog-perl  1.2.0-8
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.69-1
ii  man-db 2.7.3-1
ii  patchutils 0.3.4-1
ii  perl [libdigest-sha-perl]  5.20.2-6
ii  t1utils1.38-4
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg1.18.3
ii  libperlio-gzip-perl 0.18-3+b1
ii  perl5.20.2-6
ii  perl-modules [libautodie-perl]  5.20.2-6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.3
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   

Bug#801506: 413 Client Error: Request Entity Too Large on SSL site where curl works

[Enrico Zini]

Package: python-requests
Version: 2.7.0-3
Severity: normal

Hello,

thank you for maintaining python requests.

When I run the attached script and test file, using python2 and python3,
I get:

   $ ./test_post Traceback (most recent call last):
 File "./test_post", line 33, in 
   res.raise_for_status()
 File "/usr/lib/python3/dist-packages/requests/models.py", line 851, in 
raise_for_status
   raise HTTPError(http_error_msg, response=self)
   requests.exceptions.HTTPError: 413 Client Error: Request Entity Too Large

...but if I post it with curl, it works:

   $ curl https://contributors.debian.org/contributors/test_post -F 
source=bugs.debian.org -F data=@test.json.xz -F data_compression=xz -k
   {
 "records_parsed": 3, 
 "contributions_created": 0, 
 "code": 200, 
 "contributions_updated": 0, 
 "errors": [], 
 "identifiers_skipped": 0, 
 "contributions_processed": 0, 
 "records_skipped": 0, 
 "contributions_skipped": 0
   }

I suspect that python-requests is getting confused with ssl
renegotiation that was introduced when we implemented client certificate
authentication[1], although it's hard for me to track that down. The
best I can do is to provide a test case for reproducing the behaviour,
that does not require any debian credentials to be run[2].


Thank you,

Enrico


[1] https://wiki.debian.org/DebianSingleSignOn#Debian_SSO_documentation
[2] I have just implemented a test submission url on
contributors.debian.org and a random submission generator, so that I
could post this bug report: it was yak shaving morning

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

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

Versions of packages python-requests depends on:
ii  ca-certificates  20150426
ii  python-chardet   2.3.0-1
ii  python-urllib3   1.11-2
pn  python:any   

python-requests recommends no packages.

Versions of packages python-requests suggests:
ii  python-ndg-httpsclient  0.4.0-1
ii  python-openssl  0.15.1-2
ii  python-pyasn1   0.1.8-2

-- no debconf information

Bug#798343: libbcprov-java-doc: Package does not contain docs, api folder empty

[Markus Koschany]

On Sun, 11 Oct 2015 12:48:45 +1000 dean  wrote:
> Tags: patch
> 
> Greetings all,
> 
> I have confirmed this bug is related to source file encoding.
> I believe I have fixed this in the attached patch.
> 
> Please review - this is my first debian bug fix.

Hi dean,

thanks for your patch. I think there is even a simpler way to change the
source encoding. In Debian we normally use an ant.properties file for
that. A line like encoding=UTF-8 or compile.encoding=UTF-8 should do the
trick. It should be even possible to drop the 01_build.patch but I
haven't tested this yet.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#798900: [Debian-med-packaging] Bug#798900: lintian: false positive: source-is-missing for non-minified JS files

[Sascha Steinbiss]

Hi,

>> For the time being, would it be enough to add the DataTablesSrc repo
>> content (and a README) to aegean’s debian/missing-sources to comply
>> with DFSG until a DataTables package gets into the archive?
> 
> Better than nothing but I think it still violates ftpmaster policy
> since it might not be possible to build DataTablesSrc because JSHint
> isn't in Debian yet.

It looks like JSHint is not a hard requirement but will just not be used if it’s
not there:
https://github.com/DataTables/DataTablesSrc/blob/master/build/make.sh#L58
Otherwise I wouldn't mind patching the build script to not use it.

> Their policy is that things must be buildable from
> source but not that the source package has to build from source.
> Personally I think the only way to prove that you can build from source
> is to actually build from source, every time you build.

In principle I agree here.

>> I’m asking because the existing but apparently never uploaded draft
>> DataTables package [1] does not build DataTables from ‘source’ either
>> but just gets and repacks the built distribution from
>> https://github.com/DataTables/DataTables/. So I guess I would need to
>> start from scratch...
> 
> I see, yeah. If you do work on it, please replace the existing repo
> instead of starting a new repo.

Sure. Could you probably give me access to collab-maint then? As a DM I only 
have a
guest account on Alioth and someone has to approve me. I have sent a request via
the Alioth web interface quite some time ago but received no response.

Thanks,
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#799123: Debug::pkgAcquire::Worker output is percent-encoded incorrectly

[David Kalnischkies]

Hi,

On Wed, Sep 16, 2015 at 03:18:34AM +0300, Evgeny Kapun wrote:
> Debug::pkgAcquire::Worker option causes APT to produce debug output, some of 
> which is percent-encoded. Bytes with values greater than or equal to 128 are 
> encoded incorrectly: for example, the value 128 should be encoded as %80, but 
> is actually encoded as %ff80.

The precent encoding is done on characters, not on bytes. I presume you
are trying this on an amd64 machine, which has a signed char, so the
valid range is from -128 (or -127) to 127 only.


I am a bit at a lost here as I don't understand what the problem is…
maybe you can give us an idea how and why you are trying to sent bytes
instead of characters in our textinterface here?


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#801510: fdroidserver: Hardcoded openJDK7

[Hans Joachim Desserud]

Package: fdroidserver
Version: 0.4.0-1

Dear maintainer,

Fdroidserver has a patch to use a hardcoded path to openJDK7's
keytool [1]. There's some discussion of this in the Ubuntu bug
tracker, see [2] for details.

We wonder what sort of issues alternative keytools caused and whether
those issues still persist in the latest version of fdroidserver? :)

[1] 
https://anonscm.debian.org/cgit/collab-maint/fdroidserver.git/tree/debian/patches/hard-code-path-to-openjdk-7.patch

[2] https://bugs.launchpad.net/ubuntu/+source/fdroidserver/+bug/1489584
--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#801401: cannot start X from the console command line

[Julien Cristau]

On Fri, Oct  9, 2015 at 18:26:01 +0200, Giuseppe Bilotta wrote:

> Package: xserver-xorg
> Version: 1:7.7+12
> Severity: important
> 
> I normally boot to console and then manually launch X if/when I need it.
> With the latest update to Xorg, trying to start X fails with the error
> 
>  (EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
> 
> Interestingly, the error is about /dev/tty0 regardless of whether I try
> to start it from the first VT or from a different one (see attached
> logs).
> 
How exactly are you starting X?  'startx' is supposed to do the right
thing.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#740998: closed by Michael Gilbert <mgilb...@debian.org> (Bug#740998: fixed in ndisc6 1.0.1-2)

[Dominic Hargreaves]

On Sat, Feb 14, 2015 at 01:36:05AM +, Debian Bug Tracking System wrote:

>  ndisc6 (1.0.1-2) unstable; urgency=medium
>  .
>* QA upload.
>* Set maintainer to the Debian QA Group (see #713004).
>* Add conflicts between rdnssd and network-manager (closes: #740998).

This bug just hit me in Debian stable (as it happens, it appeared to
be a particularly severe form where /etc/resolv.conf was wiped out
altogether; perhaps some sort of race condition?)

I'm not sure why rdnssd was installed at all. I can't see any mention
of it in debian-installer, and not a single package Depends or Recommends
it. Morever it was installed without resolvconf (which I suspect would
have mitigated this issue), despite it recommending resolvconf, and no
change to the default of installing recommends having taken place.

Release team; would you consider a QA upload of this package targetted
at stable, fixing this bug in the same way that Michael fixed it in
unstable - this will hopefully stop others having the experience of
having networking break on a freshly installed Debian system every 20
minutes or so.

Dominic.

Bug#801498: rakudo: Native libraries and paths

[Dominique Dumont]

Le dimanche 11 octobre 2015, 12:50:07 12:50:07 gregor herrmann a écrit :
> Is this a problem of rakudo, of panda, of Linenoise, or am I just
> missing some setup/variable/...?
uh... You're pretty far ahead of me playing with panda...

Anyway, /usr/bin/perl6 is actually:
exec /usr/bin/moar  --execname="$0" --libpath="/usr/share/nqp/lib" --
libpath="/usr/lib/nqp/lib" --libpath="/usr/share/perl6/lib" --
libpath="/usr/share/perl6/runtime" --libpath="/usr/lib/perl6/runtime" --
libpath="/usr/lib/perl6/runtime/dynext" /usr/share/perl6/runtime/perl6.moarvm 
"$@"

Could you try to add a --libpath option pointing to the directory containing 
liblinenoise.so ?

let see what happens then...

HTH
-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

Bug#800769: pbuilder: conffiles not removed

[Mattia Rizzolo]

On Sun, Oct 11, 2015 at 11:03:09AM +0200, Wouter Verhelst wrote:
> The only way to hand a file (any file) over to another package is by way of
> 'Replaces:', *without* the Conflicts: and Provides:.
> 
> Since this is a single packaga version, you could put the file in pbuilder-uml
> and have that 'Replaces: pbuilder (= 0.217)', that way the possible damage in
> case you have other (accidental) file conflicts would be limited.

Though this way if a person install pbuilder 0.217, then removes it the
conffile would stay there, and that's the whole point of the bug.
I agree the Replaces is needed, but I don't see it as being enough to
deal with this... :(

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#801517: lintian: broken link to Debian Packaging Policy for Vim

[Jakub Wilk]

Package: lintian
Version: 2.5.38
Severity: minor

https://lintian.debian.org/tags/vim-addon-within-vim-runtime-path.html 
links to http://pkg-vim.alioth.debian.org/vim-policy.html/, but the 
pkg-vim.alioth.debian.org domain doesn't exist.


Dear vim maintainers, would it possible to make Debian Packaging Policy 
for Vim available online again? (Perhaps 
https://www.debian.org/doc/devel-manuals would be a safer place to host 
it than Alioth.)


--
Jakub Wilk

Bug#801505: texlive-latex-extra: complaint about weong file in dpkg trigger

[Norbert Preining]

On Sun, 11 Oct 2015, Michal Suchanek wrote:
> I tried to ugrade libstdc++ and as a result I also needed to upgrade
> TeX.
...
>   APT prefers stable

Are you running stable? If yes, then you cannot do a partial
upgrade. You need also to update lmodern and all other packages
to the versions in testing/unstable.

Which version of lmodern do you have installed?

Norbert


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

Bug#794723: Policykit crashes systemd

[Simon McVittie]

On Wed, 05 Aug 2015 at 19:37:47 -0400, Carlos Kosloff wrote:
> I am installing a fresh version of testing, no desktop, just standard system
> utilities in a VM, the underlying software is virtualbox (from Oracle)
> Version 5.0.0r101573.
> After a dist-upgrade I installed xserver-xorg and then proceeded to install
> e17, which completely crashed systemd, I could not even reboot or poweroff
> the VM.
> I went back to the initial snapshot, which wiped out the previous install,
> and tried with xfce4, obtaining same results.
> I am posting a link to a snapshot because I could not capture text in the
> VM. it might have been possible using only keyboard but I did not try.
> http://i.imgur.com/w5jD2Xw.png

Transcribing that image for reference, since it will probably expire:

8<
Error getting authority: Error initializing authority: Error calling 
StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached 
(g-io-error-quark, 24)
Failed to execute operation: Connection timed out
dpkg: error processing package systemd (--unpack):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@testing:/home/ckosloff# poweroff
Error getting authority: Error initializing authority: Error calling 
StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached 
(g-io-error-quark, 24)
Failed to start poweroff.target: Connection timed out

Broadcast message from ckosloff@testing on tty1 (Wed 2015-08-05 17:40:36 EDT):

The system is going down for power-off NOW!

root@testing:/home/ckosloff#
8<

I can reproduce something very like this in a smaller stretch VM, and
it's quite tangled. At this stage I'm not sure whether to blame dbus,
policykit-1 or systemd, which is why I'm cc'ing the other packages'
maintainers. This is potentially related to
 and
.

I'm currently on mobile Internet using an incompletely pre-populated
apt-cacher-ng, but luckily it's reproducible with a subset of the
XFCE packages (I installed xserver-xorg, policykit-1 and lightdm onto
a VM with a minimal d-i installation). I ran dbus-monitor --system
as root on tty1, using systemd-cat to redirect it to the Journal;
ran apt on tty2, using systemd-cat again; and watched the Journal on
tty3 to guess when I needed to switch back to tty2 and press Enter.

Unpacking all the packages goes fine, until apt starts processing
triggers:

Oct 11 12:25:45 debian apt[708]: Processing triggers for systemd (226-4) ...

This runs systemctl, which runs the polkit tty agent (:1.2 on the
system bus) to handle password prompting; you can see it do
some D-Bus method calls. You can tell it's the polkit agent and
not systemctl itself, because its error messages (as quoted above)
mention GIO error handling, and systemd doesn't use GIO.

One of its method calls prompts dbus-daemon to start polkit:

Oct 11 12:25:45 debian dbus[642]: [system] Activating via systemd: service 
name='org.freedesktop.PolicyKit1' unit='polkitd.service'
Oct 11 12:25:45 debian systemd[1]: Starting Authenticate and Authorize Users to 
Run Privileged Tasks...
Oct 11 12:25:45 debian dbus-monitor[664]: signal time=1444562745.547491 
sender=org.freedesktop.DBus -> destination=org.freedesktop.systemd1 serial=19 
path=/org/freedesktop/DBus; interface=org.freedesktop.systemd1.Activator; 
member=ActivationRequest
Oct 11 12:25:45 debian dbus-monitor[664]: string "polkitd.service"
Oct 11 12:25:45 debian dbus-monitor[664]: method call time=1444562745.547506 
sender=:1.2 -> destination=org.freedesktop.DBus serial=5 
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; 
member=StartServiceByName
Oct 11 12:25:45 debian dbus-monitor[664]: string "org.freedesktop.PolicyKit1"
Oct 11 12:25:45 debian dbus-monitor[664]: uint32 0

systemd, which was the first thing on the bus (:1.0), adds a match
rule:

Oct 11 12:25:45 debian dbus-monitor[664]: method call time=1444562745.547634 
sender=:1.0 -> destination=org.freedesktop.DBus serial=17 
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
Oct 11 12:25:45 debian dbus-monitor[664]: string 
"type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.freedesktop.PolicyKit1'"
Oct 11 12:25:45 debian dbus-monitor[664]: method return time=1444562745.547644 
sender=org.freedesktop.DBus -> destination=:1.0 serial=20 reply_serial=17

then it starts polkit, which says hello:

Oct 11 12:25:45 debian dbus-monitor[664]: method call time=1444562745.576313 
sender=:1.3 -> destination=org.freedesktop.DBus serial=1 
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
Oct 11 12:25:45 debian dbus-monitor[664]: method return time=1444562745.576327 
sender=org.freedesktop.DBus -> destination=:1.3 

Bug#801514: firmware-realtek: Please include rtl8821a_fw.bin

[Ulrich Klauer]

Package: firmware-realtek
Version: 0.44
Severity: wishlist

There is an rtl_bt/rtl8821a_fw.bin file in the upstream linux-firmware
repository (added in commit 8e181320b11de501046cf75c8c30915cd09a1e39),
but it is not yet included in the firmware-realtek Debian package. On
the other hand, the newest kernel package already contains the
corresponding changes to make use of this firmware, so when I upgraded
the kernel, my bluetooth controller stopped working. Excerpt from
dmesg:

Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000a lmp_ver=06 
lmp_subver=8821
Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_fw.bin
bluetooth hci0: firmware: failed to load rtl_bt/rtl8821a_fw.bin (-2)
bluetooth hci0: Direct firmware load for rtl_bt/rtl8821a_fw.bin failed with 
error -2
Bluetooth: hci0: Failed to load rtl_bt/rtl8821a_fw.bin

Please include this file in the next package release. For good measure
and in the interest of people using different hardware, the other
firmware blobs from that commit should probably be added, too.

Ulrich

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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.120

-- no debconf information

Bug#799779: integrate autopkgtest/DEP8 specification into debian-policy

[Bill Allombert]

On Tue, Sep 22, 2015 at 03:55:17PM +0200, Stefano Zacchiroli wrote:
> Package: debian-policy
> Severity: wishlist
> Tags: patch
> 
> I'm filing this bug report to avoid losing track of the discussion we've had 
> in
> July 2014 about merging the autopkgtest/DEP8 specification into Debian Policy.
> The thread is archived starting from here:
> 
>   https://lists.debian.org/debian-policy/2014/07/msg00057.html
> 
> I've posted draft patches implementing what was discussed in the thread at the
> time; I'm attaching them to this message as patches.

Hello Stefano, I have created a git branch bug799779-bill with your
patch. I needed to change a little, please review (in attachment).

> There have been some requested format changes (see thread), which I didn't 
> have
> time to implement. They're now up for grabs, hurry up! :-)

If I do the conversion, would you review the new version for translation
error ?

Thanks for moving forward with this,
-- 
Bill. 

Imagine a large red swirl here. 
>From 7a6d9d92f52c2a8728db87409e0d1dcd6e6dc910 Mon Sep 17 00:00:00 2001
From: Bill Allombert 
Date: Sun, 11 Oct 2015 17:54:38 +0200
Subject: [PATCH] autopkgtest.desc: replace reference to packages-tests by
 autopkgtest

---
 autopkgtest.desc |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/autopkgtest.desc b/autopkgtest.desc
index dc7ea40..7d3fa3e 100644
--- a/autopkgtest.desc
+++ b/autopkgtest.desc
@@ -2,12 +2,12 @@ Document: autopkgtest
 Title: automatic as-installed package test specification
 Author: The Debian Project
 Abstract: Specification for automatic as-installed (AKA "autopkgtest",
-  or DEP-8) tests for Debian packages
+ or DEP-8) tests for Debian packages
 Section: Debian
 
 Format: text
-Files: /usr/share/doc/debian-policy/package-tests.txt.gz
+Files: /usr/share/doc/debian-policy/autopkgtest.txt.gz
 
 Format: HTML
-Index: /usr/share/doc/debian-policy/package-tests.html
-Files: /usr/share/doc/debian-policy/package-tests.html
+Index: /usr/share/doc/debian-policy/autopkgtest.html
+Files: /usr/share/doc/debian-policy/autopkgtest.html
-- 
1.7.10.4

Bug#799036: openspecfun: please build everywhere

[Jonas Smedegaard]

Benefit of targeting any arch instead of known succesful ones is to help 
porters identify where work is needed - a.k.a. not hide problems, as 
we're all abiding to in our Social Contract.

You need not be concerned about FTBFS on strange archs affecting the 
package migrating to testing: Only FTBFS on archs already in testing are 
treated as severe - i.e. only regressions count.

Only if this package lacks a proper testsuite and you know that builds 
on some archs even though technically succeeding will produce broken 
code.  If that's the case I urge you to make it more visible e.g. to 
porters - one way could be to add arch checks in debian/rules that 
checks for build architecture and fails with a suitably descriptive 
error message that porters can see in build logs for those archs.

Hope that helps,

 - Jonas

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

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


signature.asc
Description: signature

Bug#789567: Help?

[Salvo Tomaselli]

Hello,

Do you have any clue on how to fix this?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789567

Thanks

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#801507: openssh-server: Logins to SSH are slow (not DNS)

[Victor Porton]

Package: openssh-server
Version: 1:6.0p1-4+deb7u2
Severity: normal

Dear Maintainer,

Here is timing (in seconds per line of debug output) log for login to
my SSHD server at host which I denote XXX.org.
Keys are replaced with YYY. It is way too slow.

$ ssh -v r...@xxx.org 'echo -n' 2>&1| perl -MTime::HiRes=time -p -e 
'$oldtime//=time; print time-$oldtime, " "' 
4.05311584472656e-06 OpenSSH_6.9p1 Debian-2, OpenSSL 1.0.2d 9 Jul 2015
3.31401824951172e-05 debug1: Reading configuration data /etc/ssh/ssh_config
4.1961669921875e-05 debug1: /etc/ssh/ssh_config line 19: Applying options for *
0.0155961513519287 debug1: Connecting to XXX.org [104.236.49.103] port 22.
0.17785906791687 debug1: Connection established.
0.178133964538574 debug1: identity file /home/porton/.ssh/id_rsa type 1
0.178153991699219 debug1: key_load_public: No such file or directory
0.178158044815063 debug1: identity file /home/porton/.ssh/id_rsa-cert type -1
0.17829704284668 debug1: identity file /home/porton/.ssh/id_dsa type 2
0.178317070007324 debug1: key_load_public: No such file or directory
0.178322076797485 debug1: identity file /home/porton/.ssh/id_dsa-cert type -1
0.178330183029175 debug1: key_load_public: No such file or directory
0.178335189819336 debug1: identity file /home/porton/.ssh/id_ecdsa type -1
0.178340196609497 debug1: key_load_public: No such file or directory
0.178344011306763 debug1: identity file /home/porton/.ssh/id_ecdsa-cert type -1
0.178415060043335 debug1: key_load_public: No such file or directory
0.178436040878296 debug1: identity file /home/porton/.ssh/id_ed25519 type -1
0.178440093994141 debug1: key_load_public: No such file or directory
0.178444147109985 debug1: identity file /home/porton/.ssh/id_ed25519-cert type 
-1
0.178505182266235 debug1: Enabling compatibility mode for protocol 2.0
0.178516149520874 debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Debian-2
0.346481084823608 debug1: Remote protocol version 2.0, remote software version 
OpenSSH_6.7p1 Debian-5
0.34649395942688 debug1: match: OpenSSH_6.7p1 Debian-5 pat OpenSSH* compat 
0x0400
0.346500158309937 debug1: Authenticating to XXX.org:22 as 'root'
0.348556041717529 debug1: SSH2_MSG_KEXINIT sent
0.507776021957397 debug1: SSH2_MSG_KEXINIT received
0.507788181304932 debug1: kex: server->client chacha20-poly1...@openssh.com 
 none
0.507797002792358 debug1: kex: client->server chacha20-poly1...@openssh.com 
 none
0.51166296005249 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
0.695590019226074 debug1: Server host key: YYY
0.699064970016479 debug1: Host 'XXX.org' is known and matches the ECDSA host 
key.
0.69907808303833 debug1: Found key in /home/porton/.ssh/known_hosts:30
0.705465078353882 debug1: SSH2_MSG_NEWKEYS sent
0.705478191375732 debug1: expecting SSH2_MSG_NEWKEYS
0.705487966537476 debug1: SSH2_MSG_NEWKEYS received
0.705492973327637 debug1: Roaming not allowed by server
0.705497026443481 debug1: SSH2_MSG_SERVICE_REQUEST sent
1.06489396095276 debug1: SSH2_MSG_SERVICE_ACCEPT received
1.23194813728333 debug1: Authentications that can continue: publickey,password
1.23197102546692 debug1: Next authentication method: publickey
1.23197507858276 debug1: Offering RSA public key: /home/porton/.ssh/id_rsa
1.39787101745605 debug1: Server accepts key: pkalg ssh-rsa blen 279
1.58550310134888 debug1: Authentication succeeded (publickey).
1.58552598953247 Authenticated to XXX.org ([104.236.49.103]:22).
1.58553504943848 debug1: channel 0: new [client-session]
1.58554410934448 debug1: Requesting no-more-sessi...@openssh.com
1.58556413650513 debug1: Entering interactive session.
1.74791097640991 debug1: Sending environment.
1.74793004989624 debug1: Sending env LC_PAPER = en_US.UTF-8
1.74793696403503 debug1: Sending env LC_MONETARY = en_US.UTF-8
1.74794602394104 debug1: Sending env LC_NUMERIC = en_US.UTF-8
1.74797606468201 debug1: Sending env LANG = en_US.utf8
1.74798607826233 debug1: Sending env LC_MEASUREMENT = en_US.UTF-8
1.7480221313 debug1: Sending env LC_TIME = en_US.UTF-8
1.74802112579346 debug1: Sending command: echo -n
1.9185950756073 debug1: client_input_channel_req: channel 0 rtype exit-status 
reply 0
1.91861510276794 debug1: client_input_channel_req: channel 0 rtype 
e...@openssh.com reply 0
1.91863608360291 debug1: channel 0: free: client-session, nchannels 1
1.91869902610779 debug1: fd 1 clearing O_NONBLOCK
1.91870999336243 Transferred: sent 3564, received 1788 bytes, in 0.3 seconds
1.91871905326843 Bytes per second: sent 10698.4, received 5367.2
1.91872715950012 debug1: Exit status 0

Note that this seems NOT to be a DNS issue as I have "UseDNS no" in
/etc/ssh/sshd_config

/etc/ssh/sshd_config follows:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey 

Bug#799030: make: Normalize path before matching against targets

[Alex Vong]

Package: make
Followup-For: Bug #799030

Hi Celelibi,

I am not the maintainer of GNU Make but I think I know how to solve
your problem.

According to 
,
there is a function `$(abspath names…)', which returns an absolute
name that does not contain any . or .. components, nor any repeated
path separators (/).

I guess that the reason GNU Make is not doing the name conversion
automatically is because that it is a platform-specific thing. It may
not be desired to *always* do it, so the GNU Make devs introduce the
`$(abspath names…)' function.

Hopefully, this resolves your problem. If this is the case, please
consider closing the bug report or tell me to do so.

Cheers,
Alex


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

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

Versions of packages make depends on:
ii  libc6  2.19-22

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#794311: KiCad 4.0 rc1

[Gregor Riepl]

Hi Bas

>> - UI plugins (_cvpcb.kiface, _eeschema.kiface, _gerbview.kifacem
>> _pcb_calculator.kiface, _pcbnew.kifacem _pl_editor.kiface) are currently
>> installed to /usr/bin. Should I report this upstream and request they be
>> installed to /usr/lib/kicad instead? Or write a patch specifically for 
>> Debian?
>> They are dynamically loaded libraries and not executables, so in my opinion,
>> they should definitely not live in /usr/bin.
> 
> Yes, both.  Report upstream and patch it in Debian until they fix it.  
> /usr/bin
> should only contain executables, nothing else.

I reported the problem upstream, but it looks like it will be addressed
post-release as it's not a critical issue.

Fixing it with a Debian patch will require some insight into the KiCad plugin
loading code, which I do not have (yet). If someone could point me in the
right direction (i.e. which sources/makefiles to patch), that would be very
helpful.

> Python programs look in the directory of their executable for private modules.
> I've seen packages solve that by installing them to /usr/share/packagename/ 
> and
> making a symlink from /usr/bin to there.  That works because Python will
> dereference the symlink when checking in which directory the executable is.
> KiCAD probably doesn't do this, so in that case that approach doesn't work.

You're still referring to the plugin locations, yes?
There are a bunch of example Python scripts shipped with KiCad, which are
currently installed into /usr/share/doc/kicad/scripts and not symlinked to
/usr/bin. I don't think it would make much sense to do so, as they're more of
an exemplary nature.

>> - Would it be better to pass -DCMAKE_INSTALL_PREFIX=/usr to cmake, so all
>> built binaries use /usr/* for their data paths by default?
> 
> I am not familiar with cmake, but most likely, yes.

Already done. Works better than manually redirecting all paths, IMHO.

>> - Should the libraries be moved to a new package, like kicad-libraries 
>> instead
>> of kicad-common? They have become quite large, and the Github repository 
>> seems
>> to be updated regularly. This also begs the question if such a package should
>> be built separately from kicad.
> 
> I don't know about this.  What is the purpose of kicad-common?  You mean there
> should be a new source package, so they can be updated without triggering a
> KiCAD rebuild on the buildds?  That sounds reasonable.

kicad-common previously contained all the libraries (symbols, modules and 3D
packages), icons, file type associations, examples, i18n, scripts and templates.

i18n and all the libraries live in their own repositories now, and they are
updated independently from the main KiCad code base. So, stuffing the
libraries into kicad-common package will tag them with the main KiCad package
version, which does not accurately reflect their actual revisions.

> If you're packaging the upstream release, you should use the version without
> revision.  If they are preparing for the release, so you are packaging a
> checkout of code that will be released at some point as 4.0, you should use
> 4.0~revision (which can be called whatever you want, as long as it is
> monotonically increasing).  Using ~ instead of + has the effect that it sorts
> before "4.0", so when that is released it will be the newest version.
> 
> If you're packaging a checkout which is based on the released version, you
> should use + (or at least not ~), because then your version should be greater
> than "4.0".

Ah, that is a very good suggestion. I'll incorporate it.

If you would like to help, you can check my packaging scripts at the github
link I posted previously. Note that compiling KiCad takes a while, and partial
rebuilds do not work very well. On the other hand, parallel builds are
supported, but there may still be bugs in the kicad-docs part. Upstream is
working on that.



signature.asc
Description: OpenPGP digital signature

Bug#794311: KiCad 4.0 rc1

[Nick Østergaard]

2015-10-11 15:30 GMT+02:00 Gregor Riepl :

> If you would like to help, you can check my packaging scripts at the github
> link I posted previously. Note that compiling KiCad takes a while, and partial
> rebuilds do not work very well. On the other hand, parallel builds are
> supported, but there may still be bugs in the kicad-docs part. Upstream is
> working on that.

That should be working now IIRC, two commits were made to fix that issue.

Bug#801511: installation-report: no graphics on HP t5550 thin-client w/ stretch-testing

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Package: installation-reports
Version: 2.60
Severity: minor

Dear Maintainer,

graphics are still not workable, see attached file [Xorg.0.log.xz].
I was using a DVI-to-VGA adapter here, because only my main screen is digital, 
the others
are VGA only.
I installed Jessie-stable for someone else on an IGEL-m300c thin-client, he 
said, he had
graphics there only with a DVI-VGA adapter, but he wanted digital output. In 
the end he
was quite happy with the VESA-graphics driver, it'S OK on some devices, when 
you don't
have special needs regarding performance. 
Concerning this I did some research and found the VIA-linux portal, it seems 
they offer
linux-drivers there for newer devices, also including source-code, it might 
work on this
one with VX900-chipset, I'll have to try that out.


- -- Package-specific info:

Boot method: USB
Image version:
http://saimei.acc.umu.se/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso,
2015-10-05
Date: 2015-10-11, about 14.00h to 15.00h.

Machine: HP t 5550 thin-client
Partitions: 
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs 10240   0 10240   0% /dev
tmpfs  tmpfs   1783885008173380   3% /run
/dev/sdb1  btrfs 13670400 4323396   7497436  37% /
tmpfs  tmpfs   445968  92445876   1% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs   445968   0445968   0% /sys/fs/cgroup
tmpfs  tmpfs89196   8 89188   1% /run/user/116
tmpfs  tmpfs89196   0 89196   0% /run/user/0


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o]
Detect network card:[o]
Configure network:  [o]
Detect CD:  [o]
Load installer modules: [o]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives:  [o]
Install base system:[o]
Install tasks:  [o]
Install boot loader:[o]
Overall install:[n][no graphics]

Comments/Problems:

I did this installation only for testing-purposes, I want to try out the 
graphics-driver
from VIA. When that is done, I am going to install FreeBSD on it, that worked 
well enough
for me on HP t5540, so it should work on this one as well.
I hope FreeBSD and ZFS are able to couple an SATA-harddrive and a USB-hdd into 
one
RAID-device, because that's exactly the plan for building my own NAS-box 
without the
danger of data-loss, and retry it as CUPS-printserver.
When that is done, I am planning to do a 64-bit version of DEWP, I am waiting 
for the
backport of LXC 1.1 in fact, it would allow for an implementation, that is 
independent
from oldstable, if that doesn't come in time, maybe take the version from 
testing
directly??.

- -- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20151005-00:03"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux t5550 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VX900 Host 
Bridge: Host
Control [1106:0410] (rev 80) lspci -knn:Subsystem: VIA Technologies, 
Inc. VX900
Host Bridge: Host Control [1106:0410] lspci -knn: 00:00.1 Host bridge [0600]: 
VIA
Technologies, Inc. VX900 Error Reporting [1106:1410] lspci -knn:
Subsystem: VIA
Technologies, Inc. VX900 Error Reporting [1106:1410] lspci -knn: 00:00.2 Host 
bridge
[0600]: VIA Technologies, Inc. VX900 CPU Bus Controller [1106:2410] lspci -knn:
Subsystem: VIA Technologies, Inc. VX900 CPU Bus Controller [1106:2410] lspci 
-knn:
00:00.3 Host bridge [0600]: VIA Technologies, Inc. VX900 DRAM Bus Control 
[1106:3410]
lspci -knn: Subsystem: VIA Technologies, Inc. VX900 DRAM Bus Control 
[1106:3410]
lspci -knn: 00:00.4 Host bridge [0600]: VIA Technologies, Inc. VX900 Power 
Management and
Chip Testing Control [1106:4410] lspci -knn:Subsystem: VIA Technologies, 
Inc.
VX900 Power Management and Chip Testing Control [1106:4410] lspci -knn: 00:00.5 
Host
bridge [0600]: VIA Technologies, Inc. VX900 APIC and Central Traffic Control 
[1106:5410]
lspci -knn: Subsystem: VIA Technologies, Inc. VX900 APIC and Central Traffic
Control [1106:5410] lspci -knn: 00:00.6 Host bridge [0600]: VIA Technologies, 
Inc. VX900
Scratch Registers 

Bug#780062: lircrcd segfaults

[fld]

On Sun, 8 Mar 2015 22:09:00 + John Williams  wrote:
> Package: lirc
> Version: 0.9.0~pre1-1.2
> 
> I have just updated from wheezy to jessie (i386)
> 
> At random intervals my lirc configuration stops working; I can see that
> the lircrcd program has disappeared, and /var/log/syslog contains this:
> 
> lircrcd[843]: segfault at e975f324 ip 0804942b sp bfac5c90 error 7 in
> lircrcd[8048000+4000]
> 
> I have the current latest jessie version of every package. My lirc
> configuration files have not changed and were working fine in wheezy.
> 
> 
Hi,

Just upgraded from Wheezy->Jessie and I also started getting these random 
segfaults:
$ dmesg | grep segm
[ 4235.019558] traps: lircrcd[969] trap stack segment ip:401a87 sp:7ffd5ab61bc0 
error:0 in lircrcd[40+4000]
[16587.897038] traps: lircrcd[17175] trap stack segment ip:401a87 
sp:7ffc39fb23e0 error:0 in lircrcd[40+4000]
[16604.362987] traps: lircrcd[17364] trap stack segment ip:401a87 
sp:7ffeefdd7fa0 error:0 in lircrcd[40+4000]
[16645.638990] traps: lircrcd[17611] trap stack segment ip:401a87 
sp:7fff7cc04b20 error:0 in lircrcd[40+4000]
[16652.761130] traps: lircrcd[17947] trap stack segment ip:401a87 
sp:7ffc13236300 error:0 in lircrcd[40+4000]
[97933.168463] traps: lircrcd[3988] trap stack segment ip:401a87 
sp:7ffd60e72a90 error:0 in lircrcd[40+4000]
[97940.655398] traps: lircrcd[26463] trap stack segment ip:401a87 
sp:7ffe29c07fb0 error:0 in lircrcd[40+4000]
[191015.136621] traps: lircrcd[29975] trap stack segment ip:401a87 
sp:7ffd56ac76f0 error:0 in lircrcd[40+4000]

$ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
Driver mceusb, table rc-rc6-mce
Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC SHARP other 
Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC SHARP other 
Name: Media Center Ed. eHome Infrared 
bus: 3, vendor/product: 045e:006d, version: 0x0200
Repeat delay = 500 ms, repeat period = 125 ms

$ ps aux | grep lirc
root 28584  0.0  0.0  21044  1480 ?Ss   16:32   0:00 
/usr/sbin/lircd --driver=default --device=/dev/lirc0
root 28589  0.0  0.0   6288  1224 ?Ss   16:32   0:00 lircrcd 
/etc/lirc/lircrc
root 28590  0.0  0.0   627696 ?Ss   16:32   0:00 
/usr/bin/irexec -d /etc/lirc/lircrc

The current workaround that I'm using:
/bin/sh -c 'while true; do while pgrep lircrcd; do sleep 1s; done; 
/etc/init.d/lirc restart; done' &> /dev/null &

This bug should be escalated to 'Serious / Release Critical' classification?

Bug#786873: More info on Chrome-graphics

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


see a new report there:

801...@bugs.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlYad84ACgkQ5+rBHyUt5wtgZwCcDitk0YeGr5sYrldIJEupWrnm
luAAoKNtre1wLJ/irjJ8KcSQMUZcylyP
=yECd
-END PGP SIGNATURE-

Bug#801156: dpkg: sometimes does not pass old version to postinst on upgrade

[Guillem Jover]

Hi!

On Sat, 2015-10-10 at 16:13:11 +0200, Guillem Jover wrote:
> Thanks for the recipe. I was going through the code to see why this
> might be happening and realized that it is most probably caused by
> systemd being in triggers-pending state, which the code was not taking
> into account. I've prepared a patch, but I've not yet setup the test
> environment, if you have it ready, could you try to test a dpkg with
> this patch to see if it fixed it for you?

> I think I might instead create a reduced test case for the dpkg-tests
> functional test suite, which should be faster to reproduce and retest.

I've done this now, and I can reproduce it, and the previously attached
patch fixes the issue. I'll push the fix later today, and queue it for
all the supported stable releases. The test case is:

  


Knowing that it also fixes the issues in piuparts would be valuable I
guess, but I'd be very happy if someone else could check that out. :)

Thanks,
Guillem

Bug#801347: reportbug/querybts display mime encoded text instead of something humans parse

[Jakub Wilk]

* Douglas Calvert , 2015-10-08, 16:59:

$ querybts 773321

<>
<>
What do you want to do now? [N|x|o|r|b|e|q|?]?
<>

Followup 1 - must depend on the same irssi version it was built against

Date: Wed, 17 Dec 2014 00:10:04 +0100
From: 
Subject: Re: Bug#773321: irssi-plugin-otr segfaults unexpectedly

Y29udHJvbDogdGFncyAtMSArIG1vcmVpbmZvCgpIaSBBbnRvaW5lLAoKT24gRGllbnN0YWcsIDE2LiBEZXplbWJlciAyMDE0LCBBbnRvaW5lIEJlYXVwcsOpIHdyb3RlOgo+IFNldmVyaXR5OiBjcml0aWNhbAoKPiB0aGUgb3RyIHBsdWdpbiBpcyBzZXZlcmx5IGRhbWFnZWQsIGJvdGggaW4gamVzc2llIGFuZAo+IHdoZWV6eS1iYWNrcG9ydHMuCj4gCj4gaW4gd2hlZXp5LCBpcnNzaSBjb21wbGV0ZWx5IGNyYXNoZXMgYWZ0ZXIgaSAiL2xvYWQgb3RyIi4gdGhpcyBpcyBldmVuCj4gd2l0aG91dCB0aGUgeG1wcCBwbHVnaW4gbG9hZGVkLCBzbyBpdCdzIGRpZmZlcmVudCBmcm9tICM0OTkyMjkuCgpJIGNhbm5vdCBjb25maXJtIHRoaXMsIGl0IHdvcmtzIGZvciBtZSBuaWNlbHkgYW5kIGRhaWx5IHNpbmNlIG1vcmUgdGhhbiBhIAp5ZWFyLiAoU28gaW4gYSB3YXkgSSdtIHRlbXB0ZWQgdG8gZG93bmdyYWRlIHRoaXMgYnVnLiBPbmNlIHRoZXJlIGFyZSAKYXV0b3JlbW92YWwgd2FybmluZ3MgSSdsbCBkbyBzby4pCgpJIG5ldmVyIHVzZSB0aGUgeG1wcCBwbHVnaW4gKG5vciBoYXZlIGl0IGluc3RhbGxlZCkuLi4KCgpjaGVlcnMsCglIb2xnZXI=


Sounds similar to #799528.

--
Jakub Wilk

Bug#799717: stress: ships /usr/share/info/dir.gz on arm64

[Eriberto Mota]

tags 799717 jessie
thanks

Hi Uwe,

Thanks for your report. Currently, this issue is found in Jessie, not
in Sid. So, I added a tag 'jessie'.

I will try to fix this problem. Thanks.

Regards,

Eriberto


2015-09-21 16:06 GMT-03:00 Uwe Kleine-König :
> Package: stress
> Version: 1.0.1-1
> Severity: serious
> Justification: Policy 12.2
>
> Hello,
>
> according to
>
> https://packages.debian.org/jessie/arm64/stress/filelist
>
> the stress package ships a file /usr/share/info/dir.gz on arm64.
> Installing this package overwrites the index of installed info pages
> making these inaccessible. Policy specifies "[/usr/share/info/dir] must
> not be included in packages other than install-info." in 12.2.
>
> I guess the relevant difference between arm64 and the others is that the
> arm64 build server has install-info installed while the others don't.
>
> At least the armhf build log[1] contains
>
>  /usr/bin/install -c -m 644 './stress.info' 
> '/build/buildd-stress_1.0.1-1-armhf-sqCEbI/stress-1.0.1/debian/stress/usr/share/info/stress.info'
>  install-info 
> --info-dir='/build/buildd-stress_1.0.1-1-armhf-sqCEbI/stress-1.0.1/debian/stress/usr/share/info'
>  
> '/build/buildd-stress_1.0.1-1-armhf-sqCEbI/stress-1.0.1/debian/stress/usr/share/info/stress.info'
> install-info: warning: nothing done since /usr/bin/install-info 
> doesn't exist,
> install-info: warning: you might want to install an info-browser 
> package.
>
> while for arm64[2] the two last lines are not there.
>
> Best regards
> Uwe
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=stress=armhf=1.0.1-1=1322275548
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=stress=arm64=1.0.1-1=1408261104

Bug#801518: xserver-xorg: Display freezes with two X servers, switching TTYs no longer possible

[Simon Ruderich]

Package: xserver-xorg
Version: 1:7.7+12
Severity: important

Hello,

I use the following commands to start two X servers (the
`runuser` command is only used to spawn a new systemd session):

runuser --login --command='/usr/bin/startx -- :0 -nolisten tcp -novtswitch 
vt7' user1
runuser --login --command='/usr/bin/startx -- :1 -nolisten tcp -novtswitch 
vt8' user2

This worked fine in 1:7.7+9, but since 1:7.7+12 this setup causes
a freeze once I switch from the first X on vt7 to vt8. Now I
can't switch back to either vt7 or any other TTY and also can't
enter anything in the TTY. The system isn't locked up though,
e.g. sound is still working. The logs contain no additional
information (the log below is from 1:7.7+9 though), except the
following (which is always displayed when switching TTYs also in
the working version).

[ 19275.504] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 19281.595] (II) AIGLX: Resuming AIGLX clients after VT switch

I've tried it with the compat wrapper which uses a setuid binary.
I've no idea how to debug this issue. Some pointers would be very
appreciated.

Regards
Simon

-- Package-specific info:
VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U 
Integrated Graphics [8086:1616] (rev 09)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 240 Oct  4 04:16 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# Try to prevent tearing for Intel graphics.
Section "Device"
Identifier  "Intel Graphics"
Driver  "intel"
Option  "AccelMethod"   "sna"
Option  "TearFree"  "true"
EndSection

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 
(Debian 4.9.3-4) ) #1 SMP Debian 4.2.3-1 (2015-10-06)

Contents of most recent Xorg X server log file (/var/log/Xorg.1.log):
-
[   246.944] 
X.Org X Server 1.17.1
Release Date: 2015-02-10
[   246.944] X Protocol Version 11, Revision 0
[   246.944] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[   246.944] Current Operating System: Linux blood-stain-child 4.2.0-1-amd64 #1 
SMP Debian 4.2.3-1 (2015-10-06) x86_64
[   246.944] Kernel command line: BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 
root=/dev/mapper/blood--stain--child-root ro intel_iommu=on,igfx_off
[   246.944] Build Date: 04 May 2015  11:22:06PM
[   246.944] xorg-server 2:1.17.1-2 (http://www.debian.org/support) 
[   246.944] Current version of pixman: 0.33.2
[   246.944]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   246.944] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   246.944] (==) Log file: "/var/log/Xorg.1.log", Time: Fri Oct  9 23:04:44 
2015
[   246.944] (==) Using config file: "/etc/X11/xorg.conf"
[   246.944] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   246.944] (==) No Layout section.  Using the first Screen section.
[   246.944] (==) No screen section available. Using defaults.
[   246.944] (**) |-->Screen "Default Screen Section" (0)
[   246.944] (**) |   |-->Monitor ""
[   246.944] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[   246.944] (**) |   |-->Device "Intel Graphics"
[   246.944] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   246.944] (==) Automatically adding devices
[   246.944] (==) Automatically enabling devices
[   246.944] (==) Automatically adding GPU devices
[   246.944] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   246.944]Entry deleted from font path.
[   246.944] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   246.944] (==) ModulePath set to "/usr/lib/xorg/modules"
[   246.944] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   246.944] (II) Loader magic: 0x55a80ebf3d80
[   246.944] (II) Module ABI versions:
[   246.944]X.Org ANSI C Emulation: 0.4
[   246.944]X.Org Video Driver: 19.0
[   246.944]X.Org XInput driver : 21.0
[   246.944]X.Org Server Extension : 9.0
[   246.945] (II) xfree86: Adding drm device (/dev/dri/card0)
[   246.945] 

Bug#801505: texlive-latex-extra: complaint about weong file in dpkg trigger

[Michal Suchanek]

Package: texlive-latex-extra
Version: 2015.20150917-1
Severity: normal

Hello,

I tried to ugrade libstdc++ and as a result I also needed to upgrade
TeX.

The TeX dpkg trigger complains about wrong file.

Is this expected transitional state until some packages are rebuilt or
is something broken?

Thanks

Michal

Processing triggers for tex-common (6.03) ...


Warning: Old configuration style found in /etc/texmf/updmap.d
Warning: For now these files have been included, 
Warning: but expect inconsistencies.
Warning: These packages should be rebuild with tex-common.
Warning: Please see /usr/share/doc/tex-common/NEWS.Debian.gz
Warning: found file: /etc/texmf/updmap.d/10lmodern.cfg
Warning: found file: /etc/texmf/updmap.d/10texlive-latex-extra.cfg



##
 List of ls-R files

-rw-r--r-- 1 root root 1498 Oct 11 13:17 /var/lib/texmf/ls-R
-rw-rw-r-- 1 root staff 80 Oct 17  2013 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 Sep  3 02:24 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Sep 17 06:57 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Sep 17 06:57 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 2966 Oct 16  2014 /usr/share/texlive/texmf/ls-R
##
 Config files
-rw-r--r-- 1 root root 838 Oct 11 13:12 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 4030 Oct 11 12:58 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 32 Sep 17 06:57 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2763 Oct 11 13:17 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 27  2011 mktex.cnf
-rw-r--r-- 1 root root 838 Oct 11 13:12 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
1df66bc319cec731e202eaf39f5d85e1  /etc/texmf/texmf.d/96JadeTeX.cnf

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable'), (171, 'unstable'), (151, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 texlive-latex-extra depends on:
ii  preview-latex-style11.87-3+deb8u1
ii  tex-common 6.03
ii  texlive-base   2015.20150917-1
ii  texlive-binaries   2015.20150524.37493-6
ii  texlive-latex-recommended  2015.20150917-1
ii  texlive-pictures   2015.20150917-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2015.20150917-1
ii  texlive-latex-extra-doc2015.20150917-1

Versions of packages texlive-latex-extra suggests:
ii  libfile-which-perl  1.09-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.0.1+dfsg-1.1

Versions of packages tex-common depends on:
ii  dpkg  1.17.25
ii  ucf   3.0030

Versions of packages tex-common suggests:
ii  debhelper  9.20150101

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.03
ii  texlive-binaries  2015.20150524.37493-6

-- Configuration Files:
/etc/texmf/tex/latex/contour/contour.cfg 81b59058e250cbe26694be3c10a3fbc1 
[Errno 2] No such file or directory: u'/etc/texmf/tex/latex/contour/contour.cfg 
81b59058e250cbe26694be3c10a3fbc1'
/etc/texmf/updmap.d/10texlive-latex-extra.cfg a7e327c9ad8c69f7fbabd7101047ad13 
[Errno 2] No such file or directory: 
u'/etc/texmf/updmap.d/10texlive-latex-extra.cfg 
a7e327c9ad8c69f7fbabd7101047ad13'

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:

Bug#800509: LLVM default to 3.6 transition ?

[Sylvestre Ledru]

Le 30/09/2015 11:38, Emilio Pozuelo Monfort a écrit :
>
>> FYI, LLVM 3.7 has been released.
>> The safe way would be to do 3.5 => 3.6 now and 3.6 => 3.7 once 3.7.1 is
>> released (in one or two months)
>> or the fun way would be to skip 3.6 in the transition.
>> I would prefer the first option but I don't mind if you prefer to avoid
>> a transition.
> Going through 3.6 first is fine. Have you done a test rebuild for the rdeps? I
> have created a tracker, does it look good?
>
> https://release.debian.org/transitions/html/llvm-defaults-3.6.html
>
Looks good besides llvm-toolchain-3.5 being in this list. :)
I upload llvm-defaults into unstable and start having a look to the rest

S

Bug#800875: resolved / no action required

[Bryan Jurish]

This is (as suspected) not a problem with pm-utils; in fact, pm-utils
enabled me to solve the problem with a 1-liner (yay pm-utils!). I'm
reporting the solution in case anyone else has similar issues.

I was able to isolate the bug by following the instructions under
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt : it
turns out that freeze-ups occurred whenever my soundcard module
(snd_ice1712) was loaded.  The card is an M-Audio Delta 1010LT, and has a
record of strange behavior with this board. After adding the module to the
pm-utils SUSPEND_MODULES list, suspend/resume works as before.
Specifically, I added a file /etc/pm/config.d/modules containing the line:

 PM_SUSPEND_MODULES="snd_ice1712"

... and it's all good.  Apologies for the noise, feel free to close the
issue.

marmosets,
  Bryan

-- 
Bryan Jurish   "There is *always* one more bug."
moocow.bov...@gmail.com -Lubarsky's Law of Cybernetic Entomology

Bug#800567: nvidia-graphics-drivers: CVE-2015-5950 Memory corruption due to an unsanitized pointer in the NVIDIA display driver

[Luca Boccassi]

Hi,

I have updated the legacy-304xx SVN branch for 304.128 and tested that
the kernel module builds on all kernel versions currently in Debian,
including the 4.3 RC, on both amd64 and i386. Unfortunately I do not
have any hardware supported by the 304 series, so I cannot do any
runtime testing.

Kind regards,
Luca Boccassi


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

Bug#801487: introducing xserver-xorg-legacy without telling anybody?

[Julien Cristau]

On Sun, Oct 11, 2015 at 08:33:03 +0200, Harald Dunkel wrote:

> Package: xorg-server
> Version: 2:1.17.2-3
> 
> Please either depend or recommend xserver-xorg-legacy. It
> is *extremely* painful if you login next morning after the
> upgrade and xinit doesn't work anymore and you have no web
> interface to find out WTH has been changed.
> 
> Sorry to say, but this was *highly* annoying. Please don't
> break things by default.
> 
We didn't.  Login managers should still work, and startx should still
work.  But you didn't provide any details as to what broke...

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#801512: kblackbox build-depends on libkdegames-dev (>= 4:14.12.2) which is no longer built.

[peter green]

Package: kblackbox
Version: 4:15.08.0-1
Severity: serious
Tags: patch

kblackbox build-depends on libkdegames-dev (>= 4:14.12.2) . 
libkdegames-dev is no longer build by the kdegames source package.


In raspbian stretch simply changing the build-dep resulted in a 
successful build, I assume it will in Debian too.

Bug#801513: RFP: OpenRedAlert - Remake engine of "Red Alert" and Command-n-Conquer with very few depends

[PICCORO McKAY Lenz]

Package: wnpp
Severity: wishlist


* Package name: openredalert
  Version : 2010
  Upstream Author : Damien Carol 
* URL : https://github.com/damiencarol/openredalert
* License : GPL
  Description : Remake engine of an old game "Red Alert" from
Westwood studio

OpenRedAlert is a game engine rebuild of the game
red alert 1.

Unless OpenRA, this engine only need few dependences and make layable
in all supported hardware older or newer..

This makes more suichtable to package and mantaint in debian way.

-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#801515: mouse clicks are ignored

[Stéphane Glondu]

Package: gnome-shell
Version: 3.16.3-2
Severity: important

Dear Maintainer,

I've just upgraded and rebooted my system, and now mouse clicks have
no effect in gnome-shell. For example, I cannot close a window by
clicking on the top left right hand button, I cannot focus a window or
a desktop in overview mode. Everything that involves a click (left or
right) and should be handled by gnome-shell doesn't work. Clicks still
work in applications (e.g. gnome-terminal and gitk).

Cheers,

-- 
Stéphane

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

Kernel: Linux 4.2.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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  evolution-data-server3.16.5-2
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.18.0-1
ii  gir1.2-caribou-1.0   0.4.18.1-1
ii  gir1.2-clutter-1.0   1.24.0-1
ii  gir1.2-freedesktop   1.44.0-1+b2
ii  gir1.2-gcr-3 3.16.0-1
ii  gir1.2-gdesktopenums-3.0 3.18.0-1
ii  gir1.2-gdm3  3.14.2-2
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.44.0-1+b2
ii  gir1.2-gnomebluetooth-1.03.18.0-1
ii  gir1.2-gnomedesktop-3.0  3.16.2-2
ii  gir1.2-gtk-3.0   3.16.6-1
ii  gir1.2-gweather-3.0  3.18.0-1
ii  gir1.2-ibus-1.0  1.5.10-1
ii  gir1.2-mutter-3.03.16.3-1
ii  gir1.2-networkmanager-1.01.0.6-1
ii  gir1.2-nmgtk-1.0 1.0.6-2
ii  gir1.2-pango-1.0 1.38.0-3
ii  gir1.2-polkit-1.00.105-12
ii  gir1.2-soup-2.4  2.52.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1
ii  gir1.2-telepathylogger-0.2   0.8.1-1
ii  gir1.2-upowerglib-1.00.99.3-1+b2
ii  gjs  1.43.3-2
ii  gnome-backgrounds3.16.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.16.3-1
ii  gnome-shell-common   3.16.3-2
ii  gnome-themes-standard3.18.0-1
ii  gsettings-desktop-schemas3.18.0-1
ii  libatk-bridge2.0-0   2.18.0-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo21.14.2-2
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.24.0-1
ii  libcogl-pango20  1.22.0-1
ii  libcogl201.22.0-1
ii  libcroco30.6.8-3+b1
ii  libdbus-glib-1-2 0.102-1
ii  libecal-1.2-18   3.16.5-2
ii  libedataserver-1.2-203.16.5-2
ii  libgcr-base-3-1  3.16.0-1
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgirepository-1.0-11.44.0-1+b2
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.43.3-2
ii  libglib2.0-0 2.46.0-2
ii  libgstreamer1.0-01.6.0-1
ii  libgtk-3-0   3.16.6-1
ii  libical1a1.0.1-0.1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libmozjs-24-024.2.0-3
ii  libmutter0f  3.16.3-1
ii  libnm-glib4  1.0.6-1
ii  libnm-util2  1.0.6-1
ii  libpango-1.0-0   1.38.0-3
ii  libpangocairo-1.0-0  1.38.0-3
ii  libpolkit-agent-1-0  0.105-12
ii  libpolkit-gobject-1-00.105-12
ii  libpulse-mainloop-glib0  7.0-1
ii  libpulse07.0-1
ii  libsecret-1-00.18.3-1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  226-4
ii  libtelepathy-glib0   0.24.1-1
ii  libx11-6 2:1.6.3-1
ii  

Bug#801516: dh-exec-filter-arch corrupts input that contains [] by itself

[Evgeni Golov]

Package: dh-exec
Version: 0.19
Severity: normal

Ohai,

given the following foo.install:

#!/usr/bin/dh-exec
[linux-any] foo-linux
blah[a-z]*
blub

dh-exec-filter-arch will generate the following on Linux:

foo-linux
blub

and blah[a-z] is missing from it.

While dh_install(1) does not document the use of regex inside of install
files, it works just fine w/o dh-exec.

Greets

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

Kernel: Linux 4.2.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 dh-exec depends on:
ii  debhelper 9.20151005
ii  libc6 2.19-22
ii  libdpkg-perl  1.18.3
ii  libpipeline1  1.4.1-1
ii  perl  5.20.2-6

dh-exec recommends no packages.

dh-exec suggests no packages.

-- no debconf information

Bug#462063: [Aptitude-devel] Bug#462063: aptitude: please add a "See homepage" action for packages

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> > with the new field for a packages homepage, it would be nice to have a menu
> > entry and hotkey to open a "sensible-browser" with the Homepage URL of the
> > current package (with no action, if there is no Homepage specified).
> 
> I am marking this bug as +wontfix, mainly because it's been for 7+ years
> without being implemented, so I don't see it happening any time soon.
> 
> Also, because implementing this kind of features with a package that
> often runs as root and sometimes remotely is tricky because:
[...]
>  - running the browser as root is even more problematic

This is IMHO the main point, although that may be less of an issue if
aptitude runs as user.

This is very similar to aptitude's "B" keybinding which runs reportbug
on the selected package. That feature exists, but it has been
requested to be removed (!) for multiple reasons.

If used as root, reportbug clearly warns that running it as root may
be a security issue.

> So I don't really think that it's a good idea to implement this, because
> it's like opening a can of worms; and even if it was it means a
> considerable amount of work, and I think that at the moment the scarce
> time would be better spent in other more pressing problems.

I think both those features (opening home page in a browser as well as
reporting a bug on a package), both should be accessible if aptitude
does not run as root, if at all.

I'm not sure how many aptitude users use the Aptitude TUI as non-root
at all. While it is probably a good idea security-wise, I use aptitude
as user basically only with querying options (search, show, version,
etc.) on the commandline.

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

Bug#801451: syslinux: Error dist-upgrade by syslinux package

[Daniel Baumann]

severity 801451 minor
close 801451 3:6.03+dfsg-5
thanks

On 10/10/2015 11:58 AM, Singer Michael wrote:
> in an "apt-get dist-upgrade" the following error occurs:

you're dist-upgrading from oldstable directly to testing which is not
supported. we support oldstable->stable, and stable->testing only.

Regards,
Daniel

Bug#801508: sflphone: diff for NMU version 1.4.1-0.4

[Laurent Bigonville]

Package: sflphone
Version: 1.4.1-0.3
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for sflphone (versioned as 1.4.1-0.4). The diff
is attached to this message.

Regards.
diff -Nru sflphone-1.4.1/debian/changelog sflphone-1.4.1/debian/changelog
--- sflphone-1.4.1/debian/changelog 2015-09-12 12:56:25.0 +0200
+++ sflphone-1.4.1/debian/changelog 2015-10-11 14:19:12.0 +0200
@@ -1,3 +1,12 @@
+sflphone (1.4.1-0.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix building on new Cmake (From Ubuntu, thanks to Jean-Louis Dupond
+, Closes: #800652) 
+  * Update config.{sub, guess} to fix FTBFS for ppc64el port (Closes: #756735)
+
+ -- Laurent Bigonville   Sun, 11 Oct 2015 14:16:49 +0200
+
 sflphone (1.4.1-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sflphone-1.4.1/debian/patches/fix_cmake.patch 
sflphone-1.4.1/debian/patches/fix_cmake.patch
--- sflphone-1.4.1/debian/patches/fix_cmake.patch   1970-01-01 
01:00:00.0 +0100
+++ sflphone-1.4.1/debian/patches/fix_cmake.patch   2015-10-11 
13:32:54.0 +0200
@@ -0,0 +1,8 @@
+--- sflphone-1.4.1.orig/kde/po/CMakeLists.txt
 sflphone-1.4.1/kde/po/CMakeLists.txt
+@@ -1,3 +1,5 @@
++set_property(GLOBAL PROPERTY ALLOW_DUPLICATE_CUSTOM_TARGETS ON)
++
+ add_subdirectory( bs )
+ add_subdirectory( ca )
+ add_subdirectory( cs )
diff -Nru sflphone-1.4.1/debian/patches/series 
sflphone-1.4.1/debian/patches/series
--- sflphone-1.4.1/debian/patches/series2015-09-12 12:52:11.0 
+0200
+++ sflphone-1.4.1/debian/patches/series2015-10-11 13:47:19.0 
+0200
@@ -4,3 +4,4 @@
 remove-nonexistant-kde-include-dir.patch
 gcc-5.patch
 gcc-5-2.patch
+fix_cmake.patch
diff -Nru sflphone-1.4.1/debian/rules sflphone-1.4.1/debian/rules
--- sflphone-1.4.1/debian/rules 2015-07-23 19:41:37.0 +0200
+++ sflphone-1.4.1/debian/rules 2015-10-11 14:09:25.0 +0200
@@ -6,7 +6,7 @@
 PJPROJECT_VERSION := 2.2.1
 
 %:
-   dh $@ 
+   dh $@ --with autotools_dev
 
 override_dh_auto_configure:
 #  cd daemon/libs/ && ./compile_pjsip.sh

Bug#801509: Extra data before HTTP response data in uwsgi 2.0.7-1 in stable

[Tom van Dijk]

Package: libapache2-mod-proxy-uwsgi
Version: 2.0.7-1
Severity: important



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

Kernel: Linux 3.18.12 (SMP w/2 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 libapache2-mod-proxy-uwsgi depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.10-10+deb8u3
ii  libapr1 1.5.1-3
ii  libaprutil1 1.5.4-1
ii  libc6   2.19-18+deb8u1

Versions of packages libapache2-mod-proxy-uwsgi recommends:
ii  uwsgi-core  2.0.7-1

Versions of packages libapache2-mod-proxy-uwsgi suggests:
pn  uwsgi  

-- no debconf information

This issue is solved by version above 2.0.9. Using version 2.0.11 from debian 
unstable solves the issue.

Bug#798097: Restarting logind kills Xserver

[Michael Biebl]

Control: severity -1 important

On Sat, 05 Sep 2015 17:40:32 +0200 Michael Biebl  wrote:
> Package: xserver-xorg-core
> Version: 2:1.17.2-2
> Severity: serious
> 
> I installed gdm3 from experimental which brought xserver-xorg-core from
> experimental along with it.
> This version has support for logind enabled, which apparently is
> required to run gdm successfully.
> 
> There is one particular issue though: Atm, we do restart systemd-logind
> on upgrades in systemd.postinst. This kills your running X session
> though, due to [1].
> 
> I'm not yet sure, how to address this, i.e. if we can revert this Xorg
> patch and find a solution in X or stop restarting systemd-logind as part
> of the upgrade process.
> 
> I've decided to make this bug RC, since we need to fix that one way or
> another.

We dropped the logind restart in systemd_226-4 for now and the
xserver-xorg-core package gained a  Breaks against older systemd versions.

This is not a real fix yet, but it should be sufficient to not be RC.

Thus downgrading to important. We still should change both logind and
Xorg so logind can be restarted safely without wreaking havoc.

-- 
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#797942: sentinella: build-depends on obsolete kdebase-workspace-dev

[Eriberto Mota]

tags 797942 upstream
thanks


Hi Felix,

Initially, sorry for my long delay.

I think that the removal from testing is the best way at this time
because the upstream is active. I added the upstream in Cc.


Hi Carlos,

Can you send us a light about this issue[1] and your future plans?

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

Thanks a lot in advance.

Regards,

Eriberto



2015-10-02 12:52 GMT-03:00 Felix Geyer :
> Control: severity -1 serious
>
> Raising severity to serious as kde-workspace is finally going away.
>
> sentinella doesn't seem to build without it so maybe removal is the right 
> option?
> Unless it's being ported of course.
>
> Cheers,
> Felix

Bug#801517: lintian: broken link to Debian Packaging Policy for Vim

[Jason Pleau]

Hi

On 10/11/2015 11:48 AM, Jakub Wilk wrote:
> Package: lintian
> Version: 2.5.38
> Severity: minor
> 
> https://lintian.debian.org/tags/vim-addon-within-vim-runtime-path.html
> links to http://pkg-vim.alioth.debian.org/vim-policy.html/, but the
> pkg-vim.alioth.debian.org domain doesn't exist.
> 
> Dear vim maintainers, would it possible to make Debian Packaging Policy
> for Vim available online again? (Perhaps
> https://www.debian.org/doc/devel-manuals would be a safer place to host
> it than Alioth.)
> 

http://pkg-vim.alioth.debian.org/vim-policy.html/ works for me here

jason ~ ping pkg-vim.alioth.debian.org
PING pkg-vim.alioth.debian.org (5.153.231.21) 56(84) bytes of data.
64 bytes from moszumanska.debian.org (5.153.231.21): icmp_seq=1 ttl=51
time=102 ms
64 bytes from moszumanska.debian.org (5.153.231.21): icmp_seq=2 ttl=51
time=103 ms


-- 
Jason Pleau

Bug#801528: lintian: package-contains-timestamped-gzip false positive

[Bill Allombert]

Package: lintian
Version: 2.5.38
Severity: normal

Dear Debian Lintian Maintainers,

the tags package-contains-timestamped-gzip is documented as:

N:   The package contains a gzip-compressed file that has timestamps. Such
N:   files make the packages unreproducible, because their contents depend
N:   on the time when the package was built.

This of course only apply to files that are generated at build-time, not to 
files 
that are taken directly from the source package.
Lintian should not emit a warning in the later case, whether the file
is already compressed in the original source, or not.

Thanks for maintaining lintian!
-- 
Bill. 

Imagine a large red swirl here. 

Bug#801524: Seg Fault - failure loading gnome in virtualbox VMs

[jnqnfe]

Control: reassign -1 virtualbox-guest-x11 5.0.6-dfsg-1
Control: retitle -1 Dependency on new pkg xserver-xorg-legacy needed
Control: severity -1 grave


On Sun, 2015-10-11 at 19:57 +0200, Julien Cristau wrote:
> On Sun, Oct 11, 2015 at 18:13:31 +0100, jnqnfe wrote:
> 
> > Package: xserver-xorg
> > Version: 1:7.7+12
> > Priority: Important
> > 
> > Since installing updates last night in some VMs, I can no longer
> > load
> > gnome in those VMs.
> > 
> > They load to a terminal login (normally would auto-load gnome),
> > which
> > is flashing on and off the screen rapidly, with text input to login
> > being very difficult/impossible. This  flashing stops after about a
> > minute, leaving you at a stable/usable login prompt. After login,
> > startx fails to load gnome. The xorg log (below) lists a segfault.
> > 
> > Edit: Actually, while retrieving copies of the log files, I ran
> > startx
> > as root, which worked fine, it just doesn't load as the normal
> > user.
> > 
> try installing xserver-xorg-legacy.
> 
> Cheers,
> Julien

Yes, that solves it. Thanks. Moving to virtualbox...

Increasing severity partly due to concern that flashing login prompt
may negatively affect people with epilepsy.

Bug#801520: libapache2-mod-perl2: make the generated documentation not vary with filesystem ordering

[Niko Tyni]

Package: libapache2-mod-perl2
Version: 2.0.9-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering

As seen at
 
https://reproducible.debian.net/dbd/unstable/amd64/libapache2-mod-perl2_2.0.9-1.debbindiff.html

the generated file /usr/share/doc/libapache2-mod-perl2-doc/index.html
currently varies with the file system ordering via File::Find. This can
be easily tested with the disorderfs package. The attached patch fixes
the issue.
-- 
Niko Tyni   nt...@debian.org
>From 8aa026dec3a3572dabff99b9c5c1a3db579798fa Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 11 Oct 2015 18:56:37 +0300
Subject: [PATCH] Make the generated documentation not vary with filesystem
 ordering

If the order of the generated HTML depends on the filesystem ordering,
it's possible that it varies between build systems, breaking build
reproducibility.
---
 debian/transform_pod2html.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/transform_pod2html.pl b/debian/transform_pod2html.pl
index 44d8497..329af9a 100644
--- a/debian/transform_pod2html.pl
+++ b/debian/transform_pod2html.pl
@@ -25,7 +25,7 @@ croak "No destination directory: $DEST_DIR" if not -d $DEST_DIR;
 # the pod in the form expected by HTML::Template.
 my %data = (pod=>[],sections=>[]);
 
-find( \_pod2html, $SRC_DIR );
+find( { wanted => \_pod2html, preprocess => sub { sort @_ }}, $SRC_DIR );
 my $template = HTML::Template->new(filename=>"$CUR_DIR/debian/index.tmpl", die_on_bad_params=>0);
 $template->param(%{$data{sections}->[0]->{sections}->[0]});
 open my $fh,'>', "$CUR_DIR/$DEST_DIR/index.html";
-- 
2.5.1

Bug#801517: lintian: broken link to Debian Packaging Policy for Vim

[James McCoy]

On Sun, Oct 11, 2015 at 05:48:37PM +0200, Jakub Wilk wrote:
> https://lintian.debian.org/tags/vim-addon-within-vim-runtime-path.html links
> to http://pkg-vim.alioth.debian.org/vim-policy.html/, but the
> pkg-vim.alioth.debian.org domain doesn't exist.

Yes, it does.

$ HEAD pkg-vim.alioth.debian.org
200 OK
Connection: close
Date: Sun, 11 Oct 2015 16:56:58 GMT
Server: Apache/2.2.22 (Debian)
Vary: Accept-Encoding
Content-Type: text/html;charset=UTF-8
Client-Date: Sun, 11 Oct 2015 16:57:04 GMT
Client-Peer: 5.153.231.21:80
Client-Response-Num: 1

> Dear vim maintainers, would it possible to make Debian Packaging Policy for
> Vim available online again? (Perhaps
> https://www.debian.org/doc/devel-manuals would be a safer place to host it
> than Alioth.)

The policy (and supporting tools) need a major revision to make storing
addons in their own directory the default.  I'll look into moving it to
a more official place when that's completed.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#801523: perl: make PPPort.so not vary with file system ordering

[Niko Tyni]

Package: perl
Version: 5.22.0-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

As seen at
 https://reproducible.debian.net/rb-pkg/experimental/amd64/perl.html
 
https://reproducible.debian.net/dbd/experimental/amd64/perl_5.22.0-4.debbindiff.html

the compiled file 
 usr/lib/x86_64-linux-gnu/perl/5.22.0/auto/Devel/PPPort/PPPort.so

varies with file system ordering, because PPPort_xs.PL uses readdir()
to generate the list of files to process.

This breaks build reproducibility, as readdir() ordering can vary
between file systems. It's easy to test with the disorderfs package,
recently added to the reproducible.debian.net setup.

The attached patch fixes the issue. The reproducible.debian.net logs
have a size cutoff so we can't know if this was the only issue of its
kind. I was expecting more of them, but my test didn't turn up any.
-- 
Niko Tyni   nt...@debian.org
>From c01f602d1926b0671fd2c8d91f7e52c4e4c9fb24 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 11 Oct 2015 19:27:56 +0300
Subject: [PATCH] Sort the list of XS code files when generating RealPPPort.xs

all_files_in_dir() uses readdir() ordering to make the list of
input files. This can vary between build systems, breaking build
reproducibility.
---
 cpan/Devel-PPPort/PPPort_xs.PL | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpan/Devel-PPPort/PPPort_xs.PL b/cpan/Devel-PPPort/PPPort_xs.PL
index 5f18940..149f2fe 100644
--- a/cpan/Devel-PPPort/PPPort_xs.PL
+++ b/cpan/Devel-PPPort/PPPort_xs.PL
@@ -38,7 +38,7 @@ END
 my $file;
 my $sec;
 
-for $file (all_files_in_dir('parts/inc')) {
+for $file (sort(all_files_in_dir('parts/inc'))) {
   my $spec = parse_partspec($file);
 
   my $msg = 0;
-- 
2.5.1

Bug#801524: Seg Fault - failure loading gnome in virtualbox VMs

[jnqnfe]

Package: xserver-xorg
Version: 1:7.7+12
Priority: Important

Since installing updates last night in some VMs, I can no longer load
gnome in those VMs.

They load to a terminal login (normally would auto-load gnome), which
is flashing on and off the screen rapidly, with text input to login
being very difficult/impossible. This  flashing stops after about a
minute, leaving you at a stable/usable login prompt. After login,
startx fails to load gnome. The xorg log (below) lists a segfault.

Edit: Actually, while retrieving copies of the log files, I ran startx
as root, which worked fine, it just doesn't load as the normal user.

VMs are sid installs, fully up to date, with a handful of core gnome
packages from experimental (gdm3, gnome-shell, gnome-session, mutter,
gnome-setting-daemon, nautilus).

Things were working fine the previous day, prior to the latest updates.
The updates installed resulting in the breakage are as follows:

Install: libsctp1:amd64 (1.0.16+dfsg-3, automatic)
Upgrade: libpython2.7-stdlib:amd64 (2.7.10-4, 2.7.10-5), libpangomm-
1.4-1v5:amd64 (2.36.0-2+b1, 2.38.1-1), librsvg2-2:amd64 (2.40.10-1,
2.40.11-1), os-prober:amd64 (1.67, 1.68), xorg:amd64 (7.7+9, 7.7+12),
xserver-xorg-input-all:amd64 (7.7+9, 7.7+12), xwayland:amd64 (1.17.2-
1.1, 1.17.2-3), libpam-systemd:amd64 (226-4, 227-2), python2.7:amd64
(2.7.10-4, 2.7.10-5), xserver-xorg-core:amd64 (1.17.2-1.1, 1.17.2-3),
openjdk-7-jdk:amd64 (7u85-2.6.1-4, 7u85-2.6.1-5), udev:amd64 (226-4,
227-2), gir1.2-gcr-3:amd64 (3.16.0-1, 3.18.0-1), xserver-xorg-video-
all:amd64 (7.7+9, 7.7+12), xserver-common:amd64 (1.17.2-1.1, 1.17.2-3), 
w3m:amd64 (0.5.3-24, 0.5.3-25), librsvg2-bin:amd64 (2.40.10-1, 2.40.11-
1), baobab:amd64 (3.18.0-1, 3.18.1-1), openjdk-7-jre-headless:amd64
(7u85-2.6.1-4, 7u85-2.6.1-5), libudev1:amd64 (226-4, 227-2),
binutils:amd64 (2.25.1-5, 2.25.1-6), libmm-glib0:amd64 (1.4.10-1,
1.4.12-1), gcr:amd64 (3.16.0-1, 3.18.0-1), libpython2.7:amd64 (2.7.10-
4, 2.7.10-5), librsvg2-common:amd64 (2.40.10-1, 2.40.11-1), xserver-
xephyr:amd64 (1.17.2-1.1, 1.17.2-3), libgck-1-0:amd64 (3.16.0-1,
3.18.0-1), libencode-locale-perl:amd64 (1.03-1, 1.05-1), systemd-
sysv:amd64 (226-4, 227-2), libcairomm-1.0-1v5:amd64 (1.10.0-1.2,
1.12.0-1), openjdk-7-jre:amd64 (7u85-2.6.1-4, 7u85-2.6.1-5),
modemmanager:amd64 (1.4.10-1, 1.4.12-1), systemd:amd64 (226-4, 227-2),
libjetty8-java:amd64 (8.1.17-2, 8.1.18-1), libsigc++-2.0-0v5:amd64
(2.6.1-1, 2.6.1-2), python2.7-minimal:amd64 (2.7.10-4, 2.7.10-5),
xserver-xorg:amd64 (7.7+9, 7.7+12), libgtkmm-3.0-1v5:amd64 (3.16.0-
2+b1, 3.18.0-1), libnss-myhostname:amd64 (226-4, 227-2), gir1.2-gck-
1:amd64 (3.16.0-1, 3.18.0-1), libsystemd0:amd64 (226-4, 227-2), x11-
common:amd64 (7.7+9, 7.7+12), libgcr-base-3-1:amd64 (3.16.0-1, 3.18.0-
1), libpython2.7-minimal:amd64 (2.7.10-4, 2.7.10-5), libgcr-3-
common:amd64 (3.16.0-1, 3.18.0-1), libgcr-ui-3-1:amd64 (3.16.0-1,
3.18.0-1)

Upgrade: gir1.2-gdm3:amd64 (3.14.2-2, 3.17.92-1), gdm3:amd64 (3.14.2-2, 
3.17.92-1), libgdm1:amd64 (3.14.2-2, 3.17.92-1)

Edit: Just FYI, the latest updates from a few moments ago, updating
mutter and gdm3 to 3.18 stable versions along with a few other updates
made no difference.

Xorg.0.log file:

[   546.135] 
X.Org X Server 1.17.2
Release Date: 2015-06-16
[   546.136] X Protocol Version 11, Revision 0
[   546.137] Build Operating System: Linux 4.2.0-1-amd64 x86_64 Debian
[   546.138] Current Operating System: Linux debian 4.2.0-1-amd64 #1
SMP Debian 4.2.3-1 (2015-10-06) x86_64
[   546.138] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-
amd64 root=UUID=b58dcb99-f1c3-4e69-9817-8375e226945d ro quiet
[   546.139] Build Date: 06 October 2015  07:27:47AM
[   546.139] xorg-server 2:1.17.2-3 (http://www.debian.org/support) 
[   546.139] Current version of pixman: 0.33.2
[   546.140]    Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   546.140] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   546.143] (==) Log file: "/home/test/.local/share/xorg/Xorg.0.log",
Time: Sun Oct 11 18:00:34 2015
[   546.143] (==) Using system config directory
"/usr/share/X11/xorg.conf.d"
[   546.144] (==) No Layout section.  Using the first Screen section.
[   546.144] (==) No screen section available. Using defaults.
[   546.144] (**) |-->Screen "Default Screen Section" (0)
[   546.144] (**) |   |-->Monitor ""
[   546.144] (==) No monitor specified for screen "Default Screen
Section".
Using a default monitor configuration.
[   546.144] (==) Automatically adding devices
[   546.144] (==) Automatically enabling devices
[   546.144] (==) Automatically adding GPU devices
[   546.144] (WW) The directory "/usr/share/fonts/X11/cyrillic" does
not exist.
[   546.144]    Entry deleted from font path.
[   546.144] (==) FontPath set to:

Bug#792594: libqt5qml5 requires SSE2 on i386

[Lisandro Damián Nicanor Pérez Meyer]

Uups! This kind of changes should now go to the 5.6 branch upstream. When I 
tried to apply it to that branch I got:

$ patch -p1 < /tmp/qml-jit-on-sse2.patch 
patching file src/qml/qml/v8/qv8engine.cpp
Hunk #1 FAILED at 58.
Hunk #2 succeeded at 123 (offset 2 lines).
1 out of 2 hunks FAILED -- saving rejects to file 
src/qml/qml/v8/qv8engine.cpp.rej
patching file src/qml/jit/qv4isel_masm.cpp
Hunk #1 succeeded at 259 (offset 61 lines).
patching file src/qml/jsruntime/qv4engine.cpp
Hunk #1 succeeded at 218 (offset 35 lines).
patching file tools/qmljs/qmljs.cpp
patching file src/qml/jit/qv4isel_masm_p.h
Hunk #1 succeeded at 53 (offset 11 lines).
Hunk #2 succeeded at 66 (offset 11 lines).

I looked at src/qml/qml/v8/qv8engine.cpp and changed quite a lot.

I'm afraid I would need to take this into account to be able to upstream this 
patch :-( Can you take a look at it?

JFTR the upstream repo is git://code.qt.io/qt/qtdeclarative.git branch 5.6.

Thanks!

-- 
17: Cual es la funcion inicial de un antivirus
* Desarrollar virus para vender el producto
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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


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

Bug#790104: Fwd: Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[James Lu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
(This was supposed to go to the maintainers for lightdm-gtk-greeter in
Debian, not the upstream list; sorry for the noise.)

Hi everyone,

Recently I've been trying to get lightdm-gtk-greeter-settings into
Debian, since it's a nifty utility! Right now, my packaging work has an
RFS (request for sponsorship) bug at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790104. If there's
anyone interested in reviewing, the source is at mentors.d.n
 and Git
at
https://anonscm.debian.org/cgit/collab-maint/lightdm-gtk-greeter-settings.git.

Best,
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQIcBAEBCAAGBQJWGptZAAoJEC7D9g3nHAudT14P/2zF0ZoiOJQPqCO/o54qrGU6
ph4bQxdbWNtA7uGk3QMad0yNh6TXYapKAodTVaEGDsevDSvqVYsT9FC6bEi0fI5/
EcY89ImAg11/Zx1Mcj0UouF6hbURrDFp5K9xB+31vOET5sZoXJnfQQLaoNLwB804
QCPA6L7fsaYhfnqcf4NVE+PcILbJ1dH1/AtufFccvPii2tIAi/5eFA5/NdhsnZue
04y6G1LBTiPLHk2Eetrm4PWMZo21GbhmxouLPYKEiUL20gTR6lvh/fp8qLbTKuxu
9gIeZ/1qy64+/SHf8Fxf/xtsXXQ3K5ZeTx1V3Aw57SSdE2MnPK3P2lwl0LW8G387
Ywq6d3M8Nj8+GCEvM+aKOXb2is3VU1zT67823cUjtWosaLx19k+q0wEJCoXJFuL6
cbCsgFWUBn5kuvB9xVuJzxroGSX8HJz0BEbt4t9BJKEr7RjA9ZP6T6vfy1E+owo5
NX0bsWcD3EiunPbZumcOGPapym++JdA/1N8ddBva4+yGMqJdx4KXk5d77j425XAC
H0NslF2zU3mVZoWVnavivWZpJsGMg/Yl6NcgDF3OhKyRH3BvLFv/IVAGahrOd5Kz
wZzOol9yW97T5RpkwnjERgF/SqBmnMTdAuCD4PRV42ySxBuCHMJo4Y4BAF5O92bD
tsaGLpVbqTDOxNH0qyvO
=ys49
-END PGP SIGNATURE-

Bug#801525: systemd: incorrect boot timestamps in wtmp, last reports negative duration

[René Wagner]

Package: systemd
Version: 215-17+deb8u2
Severity: normal

Dear maintainers,

I'm not perfectly sure which package generates the "reboot" entries in
wtmp. I believe in jessie to which I recently upgraded this is systemd,
but please rassign this if that is not the case.

Since the upgrade to jessie the boot time reported by "last" is off by
two hours, e.g., in the following entry it should have been 21:36. The
shutdown time is correct.

reboot   system boot  3.16.0-4-amd64   Sat Oct 10 23:36 - 22:32  (-1:-4)

Perhaps this is caused by a confusion of local time vs. UTC? CEST is at
UTC+2.

$ cat /etc/timezone
Europe/Berlin

$ tail -n1 /etc/adjtime
LOCAL

Cheers,

Rene

Bug#800712: #800712: Added support for Baldur's Gate 2

[Markus Koschany]

Control: tags -1 patch pending

I added support for Baldur's Gate 2, English Linux installer from gog.com

Markus



signature.asc
Description: OpenPGP digital signature

Bug#801471: cryptsetup: Update remote unlocking documentation following the dropbear 2015.68-1 release

[Guilhem Moulin]

On Sat, 10 Oct 2015 at 21:42:27 +0200, Guilhem Moulin wrote:
> However, perhaps the material found in 
> /usr/share/doc/cryptsetup/README.remote.gz
> should be shipped by dropbear-initramfs instead?  The only purpose of
> that package is to install drobpear to the initrd, which might have other
> uses than remote cryptroot unlocking.  This would also be easier for us
> dropbear maintainers to update the documentation.

By the way, if you agree with the above please let me know before the next
cryptsetup upload, so I have time to update the patch and prepare a dropbear
upload.

(If #782024 is rejected I can also amend the patch to drop references to the
'unlock' executable.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#801526: gnome-maps: missing dependency on gir1.2-gweather-3.0

[nodiscc]

Package: gnome-maps
Version: 3.18.0.1-1
Severity: normal

Dear Maintainer,

gnome-maps is missing a dependency on gir1.2-gweather-3.0.

running maps without this package installed results in an error (refusing to 
launch):

$ gnome-maps 

(org.gnome.Maps:13124): Gjs-WARNING **: JS ERROR: Error: Requiring GWeather, 
version none: Typelib file for namespace 'GWeather' (any version) not found
@resource:///org/gnome/Maps/js/sendToDialog.js:23
@resource:///org/gnome/Maps/js/mapBubble.js:32
@resource:///org/gnome/Maps/js/placeBubble.js:28
@resource:///org/gnome/Maps/js/placeMarker.js:25
@resource:///org/gnome/Maps/js/mapView.js:36
@resource:///org/gnome/Maps/js/mainWindow.js:37
@resource:///org/gnome/Maps/js/application.js:35
@resource:///org/gnome/Maps/js/main.js:43
start@resource:///org/gnome/gjs/modules/package.js:176
@/usr/bin/gnome-maps:5

JS_EvaluateScript() failed



I have manually installed gir1.2-gweather-3.0:amd64 (3.18.0-1) and maps works 
fine now.

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

Kernel: Linux 4.2.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: sysvinit (via /sbin/init)

Versions of packages gnome-maps depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  geoclue-2.0  2.3.0-2
ii  gir1.2-champlain-0.120.12.11-1
ii  gir1.2-clutter-1.0   1.24.0-1
ii  gir1.2-cogl-1.0  1.22.0-1
ii  gir1.2-gdkpixbuf-2.0 2.32.0-1
ii  gir1.2-geocodeglib-1.0   3.18.0-1
ii  gir1.2-gfbgraph-0.2  0.2.3-1
ii  gir1.2-glib-2.0  1.44.0-1+b2
ii  gir1.2-goa-1.0   3.18.0-1
ii  gir1.2-gtk-3.0   3.16.6-1
ii  gir1.2-gtkchamplain-0.12 0.12.11-1
ii  gir1.2-gtkclutter-1.01.6.4-1
ii  gjs  1.43.3-2
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libchamplain-0.12-0  0.12.11-1
ii  libclutter-1.0-0 1.24.0-1
ii  libcogl-pango20  1.22.0-1
ii  libcogl-path20   1.22.0-1
ii  libcogl201.22.0-1
ii  libdrm2  2.4.64-1
ii  libegl1-mesa [libegl1-x11]   10.6.8-1
ii  libfolks25   0.11.1-2
ii  libgbm1  10.6.8-1
ii  libgdk-pixbuf2.0-0   2.32.0-1
ii  libgee-0.8-2 0.18.0-1
ii  libgeocode-glib0 3.18.0-1
ii  libglib2.0-0 2.46.0-2
ii  libgtk-3-0   3.16.6-1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libpango-1.0-0   1.38.0-3
ii  libpangocairo-1.0-0  1.38.0-3
ii  libwayland-client0   1.9.0-1
ii  libwayland-cursor0   1.9.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]   10.6.8-1
ii  libwayland-server0   1.9.0-1
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxkbcommon00.5.0-1
ii  libxrandr2   2:1.5.0-1

gnome-maps recommends no packages.

gnome-maps suggests no packages.

-- no debconf information

Bug#801472: sa-update: Can't locate HTTP/Date.pm as line 88

[Noah Meyerhans]

On Sat, Oct 10, 2015 at 11:12:18PM +0200, Mikhael Anisimov wrote:
> Severity: grave
> Justification: renders package unusable

"minor" would be more appropriate, since this bug has a trivial
workaround, a trivial fix, and does not affect the default installation
(curl or w3m must be previously installed)

> The package cannot be installed due to sa-update finishes with error.
> There is a missing dependency on libhttp-date-perl (and probably other 
> modules)

In the normal configuration, libhttp-date-perl is installed by
libwww-perl, which is the first in a short list of optional
dependencies. In the case where curl or w3m is installed before
spamassassassin, though, libwww-perl isn't installed, so neither is
libhttp-date-perl. However, since sa-update does directly use HTTP::Date
directly, the missing dependency is indeed a bug, and is fixed in svn.

noah



signature.asc
Description: Digital signature