Bug#801404: mikutter: A lot of Japanese text not translated to English

[dai]

Control: severity -1 minor
Control: tags -1 l10n upstream
Control: reopen -1
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#801456: Package: RPM

[Sławomir Kosowski]

Package: RPM
Version:  4.11.3

When I invoke #valgrind rpm -i --test  I
get the Segfault (attached)

Can you please advise, if this is a security issue?

I am using current Debian Stable x64
# valgrind rpm -i --test
id\:08\,sig\:11\,src\:000219\,op\:havoc\,rep\:2
==4876== Memcheck, a memory error detector
==4876== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4876== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==4876== Command: rpm -i --test id:08,sig:11,src:000219,op:havoc,rep:2
==4876==
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
==4876== Use of uninitialised value of size 8
==4876==at 0x4C2C1A2: strlen (vg_replace_strmem.c:412)
==4876==by 0x4E49CEC: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E4BAD9: headerPut (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E4969A: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7E208: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7E64C: headerConvert (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E6307E: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E6370D: rpmReadPackageFile (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7006E: rpmInstall (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4018C9: ??? (in /usr/bin/rpm)
==4876==by 0x5715B44: (below main) (libc-start.c:287)
==4876==
==4876== Invalid read of size 1
==4876==at 0x4C2C1A2: strlen (vg_replace_strmem.c:412)
==4876==by 0x4E49CEC: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E4BAD9: headerPut (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E4969A: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7E208: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7E64C: headerConvert (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E6307E: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E6370D: rpmReadPackageFile (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7006E: rpmInstall (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4018C9: ??? (in /usr/bin/rpm)
==4876==by 0x5715B44: (below main) (libc-start.c:287)
==4876==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4876==
==4876==
==4876== Process terminating with default action of signal 11 (SIGSEGV)
==4876==  Access not within mapped region at address 0x0
==4876==at 0x4C2C1A2: strlen (vg_replace_strmem.c:412)
==4876==by 0x4E49CEC: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E4BAD9: headerPut (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E4969A: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7E208: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7E64C: headerConvert (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E6307E: ??? (in /usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E6370D: rpmReadPackageFile (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4E7006E: rpmInstall (in
/usr/lib/x86_64-linux-gnu/librpm.so.3.2.2)
==4876==by 0x4018C9: ??? (in /usr/bin/rpm)
==4876==by 0x5715B44: (below main) (libc-start.c:287)
==4876==  If you believe this happened as a result of a stack
==4876==  overflow in your program's main thread (unlikely but
==4876==  possible), you can try to increase the size of the
==4876==  main thread stack using the --main-stacksize= flag.
==4876==  The main thread stack size used in this run was 8388608.
==4876==
==4876== HEAP SUMMARY:
==4876== in use at exit: 218,301 bytes in 2,901 blocks
==4876==   total heap usage: 4,753 allocs, 1,852 frees, 1,494,281
bytes allocated
==4876==
==4876== LEAK SUMMARY:
==4876==definitely lost: 0 bytes in 0 blocks
==4876==indirectly lost: 0 bytes in 0 blocks
==4876==  possibly lost: 30,951 bytes in 111 blocks
==4876==still reachable: 187,350 bytes in 2,790 blocks
==4876== suppressed: 0 bytes in 0 blocks
==4876== Rerun with --leak-check=full to see details of leaked memory
==4876==
==4876== For counts of detected and suppressed errors, rerun with: -v
==4876== Use --track-origins=yes to see where uninitialised values come from
==4876== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault

id_08,sig_11,src_000219,op_havoc,rep_2
Description: Binary data

Bug#801457: vlc: Segmentation fault playing a DVD with vdpau

[Arthur Marsh]

Package: vlc
Version: 2.2.1-4
Followup-For: Bug #801457

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

When I removed the vdpau libraries for the GPU in use (r600 libraries for
RS780 GPU), the video played alright, but did give these error messages:

Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: 
No such file or directory
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 1 0
[mpeg2video @ 0x7fffc81b8660] skipped MB in I frame at 24 9
[mpeg2video @ 0x7fffc81b8660] skipped MB in I frame at 17 18
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 32 25
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 13 32
[mpeg2video @ 0x7fffc81b8660] Warning MVs not available
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 23 11
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 25 22
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 29 35
[mpeg2video @ 0x7fffc81b8660] invalid cbp 0 at 4 8
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 4 10
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 15 12
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 9 14
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] invalid cbp -1 at 1 16
[mpeg2video @ 0x7fffc81b8660] invalid cbp -1 at 6 17
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 10 18
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 9 24
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 5 26
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 13 29
[mpeg2video @ 0x7fffc81b8660] invalid mb type in P Frame at 15 30
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 3 31
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 29 33
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] Warning MVs not available
[mpeg2video @ 0x7fffc81b8660] invalid mb type in B Frame at 17 9
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 35 24
[mpeg2video @ 0x7fffc81b8660] Warning MVs not available
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 19 3
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 38 10
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 16 18
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 16 25
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 28 32
[mpeg2video @ 0x7fffc81b8660] Warning MVs not available
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 25 25
[mpeg2video @ 0x7fffc81b8660] Warning MVs not available
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 36 11
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 0 25
[mpeg2video @ 0x7fffc81b8660] Warning MVs not available
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 40 4
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 24 13
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 19 27
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 20 35
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 4 12
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 4 14
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 3 15
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 2 16
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 8 17
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 40 18
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 2 19
[mpeg2video @ 0x7fffc81b8660] invalid mb type in P Frame at 6 20
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 1 21
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 4 22
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 8 23
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 9 24
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 20 25
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 2 27
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 8 28
[mpeg2video @ 0x7fffc81b8660] invalid cbp -1 at 16 29
[mpeg2video @ 0x7fffc81b8660] invalid cbp -1 at 6 30
[mpeg2video @ 0x7fffc81b8660] 00 motion_type at 5 31
[mpeg2video @ 0x7fffc81b8660] mb incr damaged
[mpeg2video @ 0x7fffc81b8660] ac-tex damaged at 1 33
[mpeg2video @ 0x7fffc81b8660] invalid mb type in P Frame at 14 9
[mpeg2video @ 0x7fffc81b8660] slice mismatch
[mpeg2video @ 0x7fffc81b8660] invalid cbp -1 at 20 11
[mpeg2video @ 0x7fffc81b8660] invalid mb type in P Frame at 1 12
[mpeg2video @ 0x7fffc81b8660] invalid mb type in P Frame at 1 13
[mpeg2video @ 0x7fffc81b8660] slice mismatch

Bug#801182: lintian: dep5-copyright-license-name-not-unique triggers on having both GPL-2 and GPL-2+

[Stephen Kitt]

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

Dear Maintainer,

Mednafen's copyright file also triggers the warnings seen by Andreas,
without the "and other-GPL" explanation given by Jakub:

W: mednafen source: dep5-copyright-license-name-not-unique (paragraph at line 
453)
W: mednafen source: missing-license-paragraph-in-dep5-copyright gpl-2 
(paragraph at line 396)

The paragraph at line 396 is

Files:
 src/snes/*
Comment: bsnes (see http://byuu.org/articles/emulation-3 for the
 license information)
Copyright: 2004-2011 byuu
   2006-2007 Shay Green
   2008-2010 byuu and nevksti
License: GPL-2

and the paragraph at line 453 is

License: GPL-2
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 2 as
 published by the Free Software Foundation.
 .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 .
 You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc.,
 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 .
 On Debian systems, the complete text of the GNU General Public License
 version 2 can be found in /usr/share/common-licenses/GPL-2

which is followed by a "License: GPL-2+" paragraph.

I'm attaching the full copyright file for reference.

Regards,

Stephen


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

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

Versions of packages 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  libdigest-sha-perl 5.95-2
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  libautodie-perl 2.29-1
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:
ii  binutils-multiarch 2.25.1-3
ii  dpkg-dev   1.18.3
ii  libhtml-parser-perl3.71-2
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.13-1

-- no debconf information
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0
Upstream-Name: mednafen
Source: http://mednafen.sf.net
Copyright: 2005-2013 Mednafen Team
License: GPL-2+
Files-Excluded: tests/psx/*.exe

Files: *
Copyright: 2005-2013 Mednafen Team
License: GPL-2+

Files: debian/*
Copyright: 2005-2008 Ryan Schultz
   2010-2014 Stephen Kitt
License: GPL-2+

Files: src/mpcdec/*
Comment: libmpcdec 
Copyright: 2005 The Musepack Development Team
License: BSD-3-clause-Musepack
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are
 met:
 .
 * Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer.
 .
 * Redistributions in binary form must reproduce the above
 copyright notice, this list of conditions and the following
 disclaimer in the documentation and/or other materials provided
 with the distribution.
 .
 * Neither the name of the The Musepack Development Team nor the
 names of its contributors may be used to endorse or promote
 products derived from this software without specific prior
 written permission.
 .
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 

Bug#801464: redis-server: Socket placed at /tmp/systemd-private-$ subfolder

[Chris Lamb]

Hi Chris,

> unixsocket /tmp/redis.sock

So, I'm not sure "/tmp" is really a suitable location for a system-wide
socket file.

Would you be okay if I changed the (commented-out) default to somewhere
in, say, /var/run? That would seem to match most other daemons that use
UNIX sockets like this (MySQL, PostgreSQL, etc. etc.)

I don't really want to disable PrivateTmp=True as it's quite an easy
security measure and -- as a bonus -- prevents multiple instances of
Redis from conflicting with each other.


Regards,

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

Bug#801466: ITP: fastd -- Fast and Secure Tunneling Daemon

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: "Steffen Möller" 

* Package name: fastd
  Version : 17
  Upstream Author : Matthias Schiffer
* URL : https://projects.universe-factory.net/projects/fastd
* License : custom
  Programming Lang: C
  Description : Fast and Secure Tunneling Daemon

Fastd came to fame in the Freifunk WLAN communities. Debian
is frequently seen as a bridge between the public Internet
and the individual comnunities. The cross-platformness of
Debian renders Debian's adoption of this developer-maintained
package to be of particular interest, preparing for the
encrypted information exchange also between embedded devices.

Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here

[Manuel A. Fernandez Montecelo]

Control: severity -1 serious


2015-10-10 18:16 张敬强:

The bug is caused by libxmlrpc-lite-perl and libsoap-lite-perl
libsoap-lite-perl depends libxmlrpc-lite-perl, while the latter one
recommends the previous one. 
The step to reproduce:
1.Install libsoap-lite-perl, make sure libxmlrpc-lite-perl is marked as
auto-installed 2.Select package libsoap-lite-perl, Press 'M'
3.Press 'g'
4.Select libxmlrpc-lite-perl or libsoap-lite-perl, press '_'
5.crash

 
I cannot reproduce it as it is, maybe because I have devscripts
installed, which recommends libsoap-lite-perl.

Today I uninstalled maint-guide and devscripts on my work computer and found 
this.

 
But interested to know, do you have ::Purge-Unused enabled in (user or
root's) ~/.aptitude/config ?  Can you post that file?

On my old laptop, aptitude crash when "_" or "-" pkg postgresql-9.4 with the 
same backtrace.
/root/.aptitude/config content on this machine:

aptitude "";
aptitude::Keep-Unused-Pattern "";
aptitude::Delete-Unused-Pattern "";
aptitude::UI "";
aptitude::UI::Menubar-Autohide "true";
aptitude::UI::Package-Display-Format "%c%a%M%S %p %Z %t %v %V";
aptitude::UI::Package-Status-Format "%d %t";
aptitude::UI::Advance-On-Action "false";
aptitude::AutoClean-After-Update "true";


I can not reproduce both of them on my new laptop, on which two more lines
in /root/.aptitude/config:

APT "";
APT::Install-Recommends "false";

If I remove these two lines, the bug can be reproduced on my new laptop.


OK, thanks.

Marking as serious so this doesn't propagate to testing.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#801468: Cannot be required and misses a dep

[Julien Puydt]

Package: node-jquery
Version: 1.6.3-1
Severity: important

Hi,

I tried to install node-jquery, then to "require('jquery');" in nodejs,
but it failed because it didn't find the cssstyle package.

So I installed node-cssstyle ; but then require fails because the package
did not self-register.

This probably means the package is unusable, though I'd be happy to be
proven wrong.

Snark on #debian-js

Bug#801471: cryptsetup: Update remote unlocking via SSH due following the dropbear 2015.68-1 release.

[Guilhem Moulin]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: normal
Tags: patch

Dear Maintainer,

Since 2015.68-1 (which has just been uploaded in the NEW queue) [0] the
‘dropbear’ package is now a transitional dummy package for

  dropbear-bin - command line tools
  dropbear-initramfs - initramfs integration
  dropbear-run - startup scripts

Hence /usr/share/doc/cryptsetup/README.Debian.gz section 8, as well as
/usr/share/doc/cryptsetup/README.remote.gz, have to be updated to point
to the new package name (dropbear-initramfs) and to mention the new
features and configuration options.  Patch enclosed.

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.

Cheers,
-- 
Guilhem.

[0] https://bugs.debian.org/790125
From bcd0590f3a0b097602bda4ce76550cee77131aaf Mon Sep 17 00:00:00 2001
From: Guilhem Moulin 
Date: Sat, 10 Oct 2015 21:38:25 +0200
Subject: [PATCH] Update remote unlocking via SSH due following the dropbear
 2015.68-1 release.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since 2015.68-1 the ‘dropbear’ package is now a transitional dummy package for

dropbear-bin - command line tools
dropbear-initramfs - initramfs integration
dropbear-run - startup scripts
---
 cryptsetup/trunk/debian/README.Debian |  61 
 cryptsetup/trunk/debian/README.remote | 128 --
 2 files changed, 74 insertions(+), 115 deletions(-)

diff --git a/cryptsetup/trunk/debian/README.Debian b/cryptsetup/trunk/debian/README.Debian
index cf4927b..238212f 100644
--- a/cryptsetup/trunk/debian/README.Debian
+++ b/cryptsetup/trunk/debian/README.Debian
@@ -202,68 +202,35 @@ nor in askpass.
 8. Remotely unlock encrypted rootfs
 ---
 
- Thanks to Chris  it's possible to install a dropbear ssh
-server into the initramfs, connect to this ssh server during execution of
+ Thanks to Chris  it's possible to install a dropbear SSH
+server into the initramfs, connect to this SSH server during execution of
 initramfs early in the boot process, and unlock encrypted devices - even the
 root device - before the boot process continues.
 
  This way it is possible to use an encrypted root filesystem on headless
 systems where no physical access is available during boot process.
 
- Dropbear 0.52-1 is required for this to work. Thankfully this version
-configures everything automatically, so all you have to do after installing
-dropbear on the remote system, is to copy the root ssh keyfile from
-/etc/initramfs/root/ssh/id_rsa to your local system:
+ Dropbear 0.52-1 or later is required for this to work. (Since 2015.68-1 the
+functionality has its own binary package 'dropbear-initramfs'.) Consult
+/usr/share/doc/cryptsetup/README.remote for information how to install and
+configure the dropbear SSH server into the initramfs.
 
-$ scp remote.system.com:/etc/initramfs/root/ssh/id_rsa remote_rsa
+ You can then unlock the disk remotely via SSH with
 
- The remote system should start dropbear automatically during the boot
-process's initramfs execution making it possible to ssh to the remote
-system and supply the rootfs passphrase.  Because the initramfs is
-kept in an unencrypted partition the default dropbear configuration
-uses a different host key in the initramfs than the remote system's
-normal host key.  This means some care must be taken when connecting
-to the remote system so that host key checking does not interfere with
-ssh connection establishment.  When using the OpenSSH client either
-the "-o StrictHostKeyChecking=no" or the "-o
-UserKnownHostsFile=alternate_known_hosts" options are some available
-choices.
+$ ssh -tF ~/.luks/ssh.conf r...@remote.system.com unlock
 
- You can login into the initramfs via ssh (modified per above)
+ Or, using a local gpg-encrypted key file:
 
-$ ssh -i remote_rsa -l root remote.system.com
-
- and echo the passphrase to a fifo file on the remote system:
-
-# echo -n "my_secret_passphrase" > /lib/cryptsetup/passfifo
+$ gpg --decrypt ~/.luks/remote.key.gpg | ssh -TF ~/.luks/ssh.conf r...@remote.system.com unlock
 
  That's it. Now that the encrypted root device is unlocked, the remote system
 should continue with the boot process.
 
- If the remote system has a network configuration at boot (via ip= on the
-kernel command line) which differs from the network configuration normally
-used, the network interfaces will need to be brought down after the rootfs is
-mounted.  Without this step the normal boot process will be unable to properly
-reconfigure the network interfaces. To do this take the following steps.
-
-# mkdir -p 

Bug#798866: (no subject)

[Копцев Антон]

sorry..
my wrong..
after restart - there is no error

Bug#801462: POT templates compressed twice

[Camaleón]

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:

***
sm01@stt008:~$ file Escritorio/dyfi_1.2.0-2_templates.pot.gz 
Escritorio/dyfi_1.2.0-2_templates.pot.gz: gzip compressed data, from Unix

sm01@stt008:~$ gunzip Escritorio/dyfi_1.2.0-2_templates.pot.gz 

sm01@stt008:~$ file Escritorio/dyfi_1.2.0-2_templates.pot 
Escritorio/dyfi_1.2.0-2_templates.pot: gzip compressed data, was 
"templates.pot", from Unix, last modified: Mon Sep 21 16:28:31 2015, max 
compression

sm01@stt008:~$ mv Escritorio/dyfi_1.2.0-2_templates.pot Escritorio/
dyfi_1.2.0-2_templates.pot.gz
 
sm01@stt008:~$ gunzip Escritorio/dyfi_1.2.0-2_templates.pot.gz

sm01@stt008:~$ file Escritorio/dyfi_1.2.0-2_templates.pot 
Escritorio/dyfi_1.2.0-2_templates.pot: GNU gettext message catalogue, ASCII 
text 
***

¹https://lists.debian.org/msgid-search/pan.2015.10.06.16.25...@gmail.com
²https://www.debian.org/international/l10n/po-debconf/pot

Cheers,

-- 
Camaleón 

Bug#801461: outdated mirrors.*.kernel.org entries in mirrorlist

[Michael Meier]

Package: mirrors

mirrors.nl.kernel.org and mirrors.se.kernel.org do not exist anymore -
all names are now just an alias for mirrors.us.kernel.org (which is in
the list as mirrors.kernel.org).
It seems that for "Archive" these nonexistant mirrors have already been
unlisted, but they are still in Mirrors.masterlist as CDImage mirrors.
These should either be removed or at least disabled like the Archive
entries.

Bug#801458: FTBFS with OCaml 4.02.3

[Ralf Treinen]

On Sat, Oct 10, 2015 at 05:44:15PM +0200, Stéphane Glondu wrote:
> Package: src:misery
> Version: 0.2-1
> Severity: serious
> Control: block 789133 by -1
> 
> Dear Maintainer,
> 
> misery fails to build on all architectures:
> 
>   https://buildd.debian.org/status/package.php?p=misery=sid

This seems to be not related to ocaml 4.02 :

$ ocaml -version
The OCaml toplevel, version 4.01.0

$ dpkg-buildpackage -uc -us
dpkg-buildpackage: warning: debian/changelog(l6): invalid abbreviated month 
name 'June'
LINE:  -- Wookey   Mon, 11 June 2012 01:36:40 +0100
dpkg-buildpackage: warning: debian/changelog(l6): cannot parse 
non-comformant date '11 June 2012 01:36:40 +0100'
LINE:  -- Wookey   Mon, 11 June 2012 01:36:40 +0100
dpkg-buildpackage: source package misery
dpkg-buildpackage: source version 0.2-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Wookey 
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build misery-0.2
dpkg-source: warning: misery-0.2/debian/changelog(l6): invalid abbreviated 
month name 'June'
LINE:  -- Wookey   Mon, 11 June 2012 01:36:40 +0100
dpkg-source: warning: misery-0.2/debian/changelog(l6): cannot parse 
non-comformant date '11 June 2012 01:36:40 +0100'
LINE:  -- Wookey   Mon, 11 June 2012 01:36:40 +0100
 fakeroot debian/rules clean
dh clean --with ocaml
Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.20/Time/Piece.pm line 
469.
debian/rules:15: recipe for target 'clean' failed
make: *** [clean] Error 255
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2


-Ralf.

Bug#794311: KiCad 4.0 rc1

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

On Fri, Sep 18, 2015 at 04:20:15PM +0100, matt.notting...@zen.co.uk wrote:
> Going by the current blockages due to the GCC5 transition, even if you
> had it packaged now, it wouldn't be available!

Yes, I recently updated my system and had to remove KiCAD to get the update
through.  Now it's uninstallable.  If there's anything I can do to speed up the
process of getting the new package in, let me know.

Probably no longer relevant, but here are answers to some questions:

On Wed, Sep 16, 2015 at 04:25:31PM +0200, Gregor Riepl wrote:
> - 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.

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.

> - 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.

> - 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.

> - 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.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWGUQ2AAoJEJzRfVgHwHE6dSAP/1aPWixrLWaBZxE9N2GhOlG8
BFLBMbpP+IA65Y1MIKT9OnElfHi7bthmRhW3qCKMJiq8ypN/0qCzLtXdo69FW1IH
tajMozgER1eVZNKw4+i9vVUOzmqagpyAVzEfOIRVfrx/B4fqmIg66gMOfrPrdN1a
3R7sX0s9rev6WbV2QRsGJGxkUpx7lSnUMRrEXXkvw+XcTQtsKggn5RNEVxUteQsQ
ndM0ZYX8QFbGmr8pfK5lgAEv6dvAIEbfGbBm8Csoa8Z1oVZv4wEBxBdDeKL7hbjs
08N2BifPiotMzoD7hvIpkFmLODj62X/iYO648YJP41QQ2Hmg/JlVuEFIOUwhYt/N
eelzmhEEFK/4NK/d7+x6yYjtqUrBhGGYa+O9kDsZHwbq3RwDMPi2FYfLOkqNFlB2
rEtfRDOlBhhwNDtVl5eyPMI+flppCUjQsk51X2UHvlXtMYYJij7p+dA5rbNiY+L9
KmHVDOH1c7kEO0qHrQ4rGj2LEHSRrHDHleapoQbhGkzhHgsRTyytN617sjA5sZpF
hDS2AuNWL6oYsu5tvqRIjstwjBnlzoxmIiLhoMxK8Rmjc2t6d4h5rw+9WOov+2Qj
1rKcsKdzb2hxfW8yaF1yfA3slBybfoWwFLhqEJg9370yMB0fI9fT+CBF+pbfvLh4
Vqw3OImoXdbnKVckJ+wq
=2J3Y
-END PGP SIGNATURE-

Bug#798855: josm: Download from OSM... gives just a blank window

[Jonas Smedegaard]

Quoting Sebastiaan Couwenberg (2015-10-10 15:58:42)
> On 14-09-15 00:23, Sebastiaan Couwenberg wrote:
>> On 14-09-15 00:07, Jonas Smedegaard wrote:
>>> Quoting Jonas Smedegaard (2015-09-14 00:00:23)
 Quoting Sebastiaan Couwenberg (2015-09-13 22:09:11)
> Your debug output doesn't show anything out of the ordinary.
> So I still have no clue what's different on your system to
> break josm. Maybe a GPU driver issue that fumbles drawing the
> new windows.
 
 My machine is a Lenovo Edge 145 laptop with AMD Radeon HD 8240 
 GPU using the free driver.
 
 A possible difference - if you tested with both those DEs 
 installed - might be some package dependency missing from josm
 or a java library which gets pulled in by larger DEs and
 therefore often unnoticed.  I use Awesome and mostly GTK-based 
 applications, avoiding both KDE and GNOME as much as I can.  I
 do generally respect recommends, however - attached is the list
 of unsatisfied reverse recommends (too long, as some are
 satisfied by alternative packages).
>> 
>> Awesome doesn't appear to be a good choice of DE. I can reproduce
>> the problem with josm under awesome. This issue should probably be 
>> reassigned to awesome, this isn't an issue with josm.
>
> I've tested this issue with the new JOSM 8800 from experimental, which
> still has this issue.
> 
> Interestingly the 'Download from OSM' window does work, new tiles get
> downloaded when zooming with the scroll wheel and hitting enter
> downloads the area in question, it just doesn't get rendered.
> 
> Jonas, do you think it's worthwhile to reassign this issue to awesome?

Is it perhaps related to bug#508650?  If so (or similar) I find it wrong 
to file it against each specific window managers - perhaps reassing to 
openjdk instead?

 - 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#801463: BUG: unable to handle kernel NULL pointer dereference at 00000001 in smp_apic_timer_interrupt

[Richard Kettlewell]

Package: src:linux
Version: 3.16.7-ckt11-1+deb8u4
Severity: important

Dear Maintainer,

   * What led up to the situation?

My kernel has started crashing every few days, since 2015-09-09.

The system was upgraded to this kernel (linux-image-3.16.0-4-586
3.16.7-ckt11-1+deb8u4) on 2015-09-20, so it's not a regression in that
particular version.

I retrieved kernel output from the most recent crash, which replaces
the kernel log section below.


-- Package-specific info:
** Version:
Linux version 3.16.0-4-586 (debian-ker...@lists.debian.org) (gcc version 4.8.4 
(Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19)

** Command line:
BOOT_IMAGE=/vmlinuz-3.16.0-4-586 root=/dev/sda3 ro console=ttyS0,115200n8

** Not tainted

** Kernel log:
[587090.909477] inbound: IN=eth2 OUT= 
MAC=00:04:a7:08:af:b0:00:1f:27:c0:08:01:08:00 SRC=221.3.105.106 DST=86.9.121.8 
LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=62653 DF PROTO=TCP SPT=39416 DPT=23 
WINDOW=5808 RES=0x00 SYN URGP=0 
[587134.548195] BUG: unable to handle kernel NULL pointer dereference at 
0001
[587134.548195] IP: [] smp_apic_timer_interrupt+0x24/0x50
[587134.548195] *pde =  
[587134.548195] Oops: 0002 [#1] 
[587134.548195] Modules linked in: tcp_diag inet_diag xt_nat xt_addrtype 
ipt_MASQUERADE ip6t_REJECT xt_multiport ipt_REJECT xt_LOG xt_limit xt_tcpudp 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip6table_mangle iptable_mangle 
ip6table_raw iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 
nf_nat_ipv4 nf_nat nf_conntrack ip6table_filter ip6_tables iptable_filter 
cpufreq_stats cpufreq_conservative ip_tables x_tables cpufreq_userspace 
cpufreq_powersave nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache 
sunrpc sit tunnel4 ip_tunnel evdev iTCO_wdt iTCO_vendor_support video 
drm_kms_helper processor pcspkr serio_raw drm thermal_sys i2c_i801 i2c_algo_bit 
lpc_ich rng_core i2c_core shpchp w83627hf hwmon_vid bridge stp llc loop slip 
slhc tun fuse autofs4 ext4 crc16 mbcache jbd2 sg sd_mod crc_t10dif 
crct10dif_generic crct10dif_common ata_generic 8139too ata_piix ehci_pci 
uhci_hcd ahci libahci ehci_hcd libata scsi_mod 8139cp r8169 mii usbcore 
usb_common
[587134.548195] CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.0-4-586 #1 Debian 
3.16.7-ckt11-1+deb8u4
[587134.548195] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To 
be filled by O.E.M., BIOS 080012  12/22/2008
[587134.548195] task: c1592500 ti: c1584000 task.ti: c1584000
[587134.548195] EIP: 0060:[] EFLAGS: 00210896 CPU: 0
[587134.548195] EIP is at smp_apic_timer_interrupt+0x24/0x50
[587134.548195] EAX: 0001 EBX: c158beec ECX: c1585f4c EDX: c1585f4c
[587134.548195] ESI: c1584001 EDI: c1585fed EBP: c1585f94 ESP: c1585f48
[587134.548195]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[587134.548195] CR0: 8005003b CR2: 0001 CR3: 34b8a000 CR4: 0790
[587134.548195] Stack:
[587134.548195]  c1425474 c1585fec  c1584000 c1584000 c1585fec c1585f94 

[587134.548195]  0002007b 08be007b 08be 00e0 ff10 c102f1a2 0060 
00200246
[587134.548195]  c1009d74 c1585fec c1584000 c1585f9c c100a54e c1585fd8 c1066b40 
c1585fec
[587134.548195] Call Trace:
[587134.548195]  [] ? apic_timer_interrupt+0x34/0x40
[587134.548195]  [] ? native_safe_halt+0x2/0x10
[587134.548195]  [] ? default_idle+0x14/0x90
[587134.548195]  [] ? arch_cpu_idle+0xe/0x10
[587134.548195]  [] ? cpu_startup_entry+0x230/0x370
[587134.548195]  [] ? start_kernel+0x3f2/0x3f7
[587134.548195]  [] ? set_init_arg+0x3f/0x45
[587134.548195] Code: ff ff eb 80 66 90 90 55 89 e5 53 3e 8d 74 26 00 8b 0d 00 
ee 59 c1 31 d2 8b 1d 48 39 59 c1 a3 48 39 59 c1 b8 b0 00 00 00 ff 91 a4 <00> 00 
00 e8 d4 a4 c1 ff e8 df f6 bf ff e8 2a a5 c1 ff 89 1d 48
[587134.548195] EIP: [] smp_apic_timer_interrupt+0x24/0x50 SS:ESP 
0068:c1585f48
[587134.548195] CR2: 0001
[587134.548195] ---[ end trace c2ab876b17f6fd20 ]---
[587134.548195] Kernel panic - not syncing: Attempted to kill the idle task!
[587134.548195] Kernel Offset: 0x0 from 0xc100 (relocation range: 
0xc000-0xf7ffdfff)
[587134.548195] Rebooting in 300 seconds..

** Model information
not available

** Loaded modules:
tcp_diag
inet_diag
xt_nat
xt_addrtype
ipt_MASQUERADE
ip6t_REJECT
xt_multiport
ipt_REJECT
xt_LOG
xt_limit
xt_tcpudp
nf_conntrack_ipv6
nf_defrag_ipv6
xt_conntrack
ip6table_mangle
iptable_mangle
ip6table_raw
iptable_raw
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
ip6table_filter
ip6_tables
cpufreq_stats
iptable_filter
cpufreq_conservative
ip_tables
x_tables
cpufreq_userspace
cpufreq_powersave
nfsd
auth_rpcgss
oid_registry
nfs_acl
nfs
lockd
fscache
sunrpc
sit
tunnel4
ip_tunnel
evdev
iTCO_wdt
iTCO_vendor_support
video
drm_kms_helper
drm
processor
thermal_sys
i2c_algo_bit
pcspkr
serio_raw
i2c_i801
lpc_ich
shpchp
i2c_core
rng_core
w83627hf
hwmon_vid
bridge
stp
llc
loop
slip
slhc
tun
fuse
autofs4
ext4
crc16
mbcache
jbd2
sg
sd_mod
crc_t10dif
crct10dif_generic
crct10dif_common
ata_generic
8139too

Bug#801463: BUG: unable to handle kernel NULL pointer dereference at 00000001 in smp_apic_timer_interrupt

[Ben Hutchings]

On Sat, 2015-10-10 at 18:11 +0100, Richard Kettlewell wrote:
> Package: src:linux
> Version: 3.16.7-ckt11-1+deb8u4
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> My kernel has started crashing every few days, since 2015-09-09.
> 
> The system was upgraded to this kernel (linux-image-3.16.0-4-586
> 3.16.7-ckt11-1+deb8u4) on 2015-09-20, so it's not a regression in that
> particular version.
> 
> I retrieved kernel output from the most recent crash, which replaces
> the kernel log section below.
[...]

This looks rather like a hardware failure, as the instruction pointer
is pointing to the middle of an instruction.  Here's the disassembly of
 smp_apic_timer_interrupt:

c1425ba0:   55  push   %ebp
c1425ba1:   89 e5   mov%esp,%ebp
c1425ba3:   53  push   %ebx
c1425ba4:   e8 c7 fb ff ff  call   0xc1425770; 
initial
3e 8d 74 26 00  lea%ds:0x0(%esi,%eiz,1),%esi ; 
patched
c1425ba9:   8b 0d 00 ee 59 c1   mov0xc159ee00,%ecx
c1425baf:   31 d2   xor%edx,%edx
c1425bb1:   8b 1d 48 39 59 c1   mov0xc1593948,%ebx
c1425bb7:   a3 48 39 59 c1  mov%eax,0xc1593948
c1425bbc:   b8 b0 00 00 00  mov$0xb0,%eax
c1425bc1:   ff 91 a4 00 00 00   call   *0xa4(%ecx)
 ^ EIP
c1425bc7:   e8 d4 a4 c1 ff  call   0xc10400a0
c1425bcc:   e8 df f6 bf ff  call   0xc10252b0
c1425bd1:   e8 2a a5 c1 ff  call   0xc1040100
c1425bd6:   89 1d 48 39 59 c1   mov%ebx,0xc1593948
c1425bdc:   5b  pop%ebx
c1425bdd:   5d  pop%ebp
c1425bde:   66 90   xchg   %ax,%ax
c1425be0:   c3  ret

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#800562: ncurses-term: screen terminfo is missing 'erase_chars' capstring

[Thomas Dickey]

On Wed, Sep 30, 2015 at 08:36:19PM -0400, Thomas Dickey wrote:
> On Wed, Sep 30, 2015 at 11:37:37PM +0100, Paul LeoNerd Evans wrote:
> > Package: ncurses-term
> > Version: 6.0+20150810-1
> > Severity: normal
> > Tags: upstream
> > 
> > The `screen` program has the ability to perform the 'erase_chars'
> > behaviour, using an ECMA-48-standard CSI X; for example:
> > 
> >   $ echo -e "ABCDEF\e[3G\e[2X"
> >   AB  EF
> > 
> > correctly erases the 2 chars in the middle when run via screen.
> 
> maybe/maybe not: there are a few descriptions where ECH is not used
> because the terminal's treatment of bce differs from that used in ncurses.

In a quick check, vttest screen 11.6.5 shows the problem I mentioned.
Test BCE-style clear line/display (ECH, Indexing)

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#801448: Acknowledgement (vlc: VLC change audio device without obvious reason)

[Gabriel Corona]

Hi,

This does not happen when using cvlc (/usr/bin/vlc -I "dummy").

Cheers.

-- 
Gabriel Corona

Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP

[Daniel Bailey]

On 10/10/15 19:06, Gianfranco Costamagna wrote:

That was a (sfortunate) issue due to the line wrapping.

I thought it would be something like that





so, now please use tab instead of spaces in the dh_auto_install target,

Oops, my mistake, my editor converted the tab, I've fixed it now.


set the distribution to unstable from UNRELEASED

Done.


update your copyright to a more complete version
(you can take example from there)
https://sources.debian.net/src/debomatic/0.21-1/debian/copyright/

Done.


and we might be good to go.

cheers,

G.



I hope that's everything complete, Thanks for all the help.
Dan.

Bug#788820: dd-list fixed in devscripts 2.15.9

[James McCoy]

On Sat, Oct 10, 2015 at 05:10:17PM +0800, Paul Wise wrote:
> On Tue, 2015-10-06 at 01:19 +, James McCoy wrote:
> 
> >    * dd-list:
> >  + Omit information from stanzas with “Extra-Source-Only: yes”.
> >  + Use only the information from the most recent version of a package
> >    within each sources file.  (Closes: #788820)
> 
> Thanks for that James.
> 
> Bart, could you update the devscripts embedded code copy on
> quantz.debian.org to version 2.15.9?

It's going to require some changes to how dd-list is currently being
called by the QA scripts.  I was planning on sending a patch for that
after the devscripts backport is updated.

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

Bug#800877: wheezy-pu: package nvidia-graphics-drivers/304.128-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2015-10-04 at 15:35 +0200, Andreas Beckmann wrote:
> CVE-2015-5950 in the non-free nvidia-graphics-drivers shall be fixed via
> PU, there won't be a DSA for this.

Please go ahead.

Regards,

Adam

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

[Guillem Jover]

Hi!

On Wed, 2015-10-07 at 03:29:10 +0200, Andreas Beckmann wrote:
> The chroot was bootstrapped with
> 
> 'debootstrap' '--variant=minbase' 
> '--keyring=/usr/share/keyrings/debian-archive-keyring.gpg' 
> '--components=main' '--arch=amd64' 'jessie' '/tmp/piupartss/tmpcNOJI3' 
> 'http://ftp.de.debian.org/debian'
> 
> and was slightly configured by piuparts to have e.g.
> 
> # cat /etc/apt/apt.conf.d/piuparts 
> APT::Get::Assume-Yes "yes";
> APT::Install-Recommends "0";
> APT::Install-Suggests "0";
> APT::Get::AllowUnauthenticated "No";
> Acquire::PDiffs "false";
> Acquire::http::Proxy "http://localhost:3128;;
> Dpkg::Options {"--force-unsafe-io";};

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.

Thanks,
Guillem
From 61a5fbc39deb116eec20db7757cf0a00ac8d5a0d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 10 Oct 2015 16:06:41 +0200
Subject: [PATCH] libdpkg: Config-Version should also be initialized on
 triggers-pending

A package in triggers-pending state should be considered an installed
package, by not doing so we might end up not passing the correct version
to the configure maintainer script and making it look like we are doing
a configuration for a first install, instead of an upgrade.

Closes: #801156
Reported-by: Andreas Beckmann 
Stable-Candidate: 1.16.x 1.17.x
---
 lib/dpkg/parse.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/lib/dpkg/parse.c b/lib/dpkg/parse.c
index 043a164..c06626a 100644
--- a/lib/dpkg/parse.c
+++ b/lib/dpkg/parse.c
@@ -225,19 +225,24 @@ pkg_parse_verify(struct parsedb_state *ps,
   if (!dop->arch)
 dop->arch = pkgbin->arch;
 
-  /* Check the Config-Version information:
-   * If there is a Config-Version it is definitely to be used, but
-   * there shouldn't be one if the package is ‘installed’ (in which case
-   * the Version and/or Revision will be copied) or if the package is
-   * ‘not-installed’ (in which case there is no Config-Version). */
+  /*
+   * Check the Config-Version information:
+   *
+   * If there is a Config-Version it is definitely to be used, but there
+   * should not be one if the package is ‘installed’ or ‘triggers-pending’
+   * (in which case the Version and/or Revision will be copied) or if the
+   * package is ‘not-installed’ (in which case there is no Config-Version).
+   */
   if (!(ps->flags & pdb_recordavailable)) {
 if (pkg->configversion.version) {
   if (pkg->status == PKG_STAT_INSTALLED ||
-  pkg->status == PKG_STAT_NOTINSTALLED)
+  pkg->status == PKG_STAT_NOTINSTALLED ||
+  pkg->status == PKG_STAT_TRIGGERSPENDING)
 parse_error(ps,
 _("Config-Version for package with inappropriate Status"));
 } else {
-  if (pkg->status == PKG_STAT_INSTALLED)
+  if (pkg->status == PKG_STAT_INSTALLED ||
+  pkg->status == PKG_STAT_TRIGGERSPENDING)
 pkg->configversion = pkgbin->version;
 }
   }
-- 
2.6.1

Bug#801455: libjogl2-java: please package upstream 2.3.1 or later

[tony mancill]

Source: libjogl2-java
Severity: wishlist

Filing a tracker bug to update libjogl2-java.  This is required to
introduce glugen2-2.3.1 to unstable and update scilab.


signature.asc
Description: PGP signature

Bug#801457: vlc: Segmentation fault playing a DVD with vdpau

[Arthur Marsh]

Package: vlc
Version: 2.2.1-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I had been watching a series of DVDs alright, when on the fourth DVD of 
the set, I get a Segmentation fault after the menu and immediately after
selecting the episode to play:

$ gdb vlc
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vlc...Reading symbols from 
/usr/lib/debug/.build-id/39/1fbfcc27d12d994a7d3208f55cf56694091211.debug...done.
done.
(gdb) run
Starting program: /usr/bin/vlc 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42)
[New Thread 0x76bb2700 (LWP 2609)]
[New Thread 0x763b1700 (LWP 2610)]
[New Thread 0x744e7700 (LWP 2611)]
[006090b8] core libvlc: Running vlc with the default interface. Use 
'cvlc' to use vlc without interface.
[New Thread 0x743e6700 (LWP 2614)]
[New Thread 0x7fffe76e4700 (LWP 2615)]
[New Thread 0x7fffe483d700 (LWP 2618)]
[New Thread 0x7fffe473c700 (LWP 2619)]
[New Thread 0x7fffd4e1d700 (LWP 2620)]
[New Thread 0x7fffd22d4700 (LWP 2621)]
[New Thread 0x7fffd21d3700 (LWP 2622)]
[New Thread 0x7fffd20d2700 (LWP 2623)]
[Thread 0x7fffd22d4700 (LWP 2621) exited]
[New Thread 0x7fffd22d4700 (LWP 2624)]
libdvdnav: Using dvdnav version 5.0.3
[Thread 0x7fffd21d3700 (LWP 2622) exited]
[Thread 0x7fffd22d4700 (LWP 2624) exited]
libdvdnav: DVD Title: Chrono Crusade V4
libdvdnav: DVD Serial Number: 35365907
libdvdnav: DVD Title (Alternative): Chrono Crusade V4
libdvdnav: DVD disk reports itself with Region mask 0x00f7. Regions: 4

libdvdread: Attempting to retrieve all CSS keys
libdvdread: This can take a _long_ time, please be patient

libdvdread: Get key for /VIDEO_TS/VIDEO_TS.VOB at 0x0154
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_01_0.VOB at 0x01be
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_01_1.VOB at 0x00027233
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_02_0.VOB at 0x00029fe3
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_02_1.VOB at 0x0002a030
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_03_0.VOB at 0x0013a1f0
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_03_1.VOB at 0x0013a23d
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_04_0.VOB at 0x001516ba
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_04_1.VOB at 0x00151707
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_05_0.VOB at 0x00161d1f
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_05_1.VOB at 0x00161d6c
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_06_0.VOB at 0x0016db0e
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_06_1.VOB at 0x0016db5b
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_07_0.VOB at 0x00174cef
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_07_1.VOB at 0x00174d3c
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_08_0.VOB at 0x0017754d
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_08_1.VOB at 0x0017759a
libdvdread: Error cracking CSS key for /VIDEO_TS/VTS_08_1.VOB (0x0017759a)!!
libdvdread: Elapsed time 1
libdvdread: Get key for /VIDEO_TS/VTS_09_0.VOB at 0x00177868
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_09_1.VOB at 0x001778b5
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_10_0.VOB at 0x00187c57
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_10_1.VOB at 0x00187ca4
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_11_0.VOB at 0x001901cb
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_11_1.VOB at 0x00190218
libdvdread: Elapsed time 0
libdvdread: Found 11 VTS's
libdvdread: Elapsed time 1
[New Thread 0x7fffd22d4700 (LWP 2627)]
[7fffc40009b8] core input error: ES_OUT_RESET_PCR called
[New Thread 0x7fffd21d3700 (LWP 2628)]
[New Thread 0x7fffd017f700 (LWP 2629)]
[New Thread 0x7fffc0f6b700 (LWP 2630)]
[7fffc817f8f8] avcodec decoder: Using G3DVL VDPAU Driver Shared Library 
version 1.0 for 

Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"

[Ian Jackson]

Johannes Schauer writes ("Bug#801435: dgit: avoiding/fixing "Source-only 
uploads to NEW are not allowed""):
> Package: dgit
> Version: 1.4
> Severity: wishlist
...
> after a "dgit push" of the package src:pdfrw I got a REJECT from
> ftpmaster because "Source-only uploads to NEW are not allowed". Since
> the source package is not yet in Debian I guess this talks about an
> upload to binary-NEW.

Looking at the ftpmaster db I think you misspoke.  You said "the
source package is not yet in Debian" but in fact it appears that 0.1-3
is in sid.

> Here are two issues I have with this (close this bug as you see fit):
> 
>  1. dgit is Debian specific so I guess it might be reasonable to assume
> that it encodes Debian specific rules like the above such that I can
> never do a "dgit push" of a source-only .changes file if there are
> new binary packages in the upload compared to the last

By definition a source-only upload doesn't involve dgit seeing the
binary packages.  I'm not even sure that it is possible to determine
which binary packages ought to be produced without doing the actual
build.  So this would be tricky.  (But how does the dak tell: does it
process debian/control?)

Also it would be possible for dgit to see that the package is entirely
new (which I think it is in your case) and to know to reject a
source-only upload in that case.

dgit is not Debian-specific, but it does have the ability to apply
different rules to different archives.  OTOH the more policy
information like this I encode in dgit, the more I have to track
ftpmaster's policy changes.  I don't know if this ftpmaster rule is
likely to change.

>  2. I do not see documentation of how to fix this situation. Is the only
> way around to bump my Debian revision to -2, rebuild with binaries
> and then do "dgit push" again? Or is there a way to mangle my
> source-only .changes file file I already have such that it contains
> the new binary packages while at the same time doesn't break any of
> dgits expectations?

Ideally you should bump the revision, yes, because the old tag and
signed .dsc and .changes for the old package are out in the wild with
your signature on.

You will need to tell dgit --deliberately-include-questionable-history
because it doesn't know why the package was REJECTed and it wants to
be told that it's not because of copyright problems (in which case
ideally you would provide a differnet git history as well as a
different package).

In some circumstances you might need to say --dpkg-genchanges:-sa I
think, to tell dgit to tell dpkg-genchanges to include the original
source, or --dpkg-genchanges:-sd to tell dgit tell dpkg-genchanges not
to.  I'm not 100% sure which the archive requires but given that 0.2-1
is in new I guess it can reuse the old .orig, in which case the
default should DTRT.  Please let me know what you discover.  TBH I
think dgit should figure this out for itself but I'm not sure of the
exact rules.

Ian.

Bug#800006: jessie-pu: package isc-dhcp/4.3.1-6

[Michael Gilbert]

On Sat, Oct 10, 2015 at 1:14 PM, Michael Gilbert wrote:
> On Wed, Oct 7, 2015 at 5:46 AM, Bastian Blank wrote:
>> On Fri, Sep 25, 2015 at 08:19:53AM +, Martin Zobel-Helas wrote:
>>> i wonder if #795227 warrants an upload to jessie-pu (and maybe also to
>>> wheezy-pu) to be fixed with the next point release. We run into that
>>> issue at work, when we want to effectivly publish static IP addresses in
>>> cloud environments.
>>
>> Can you please take a look at this update request and yell if you have
>> problems with fixing this in stable and oldstable.
>
> Where is the debdiff?

Nevermind, I just looked at the bug log.  Looks fine to me also, maybe
state that this is an NMU with maintainer approval?

Best wishes,
Mike

Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP

[Gianfranco Costamagna]

That was a (sfortunate) issue due to the line wrapping.




so, now please use tab instead of spaces in the dh_auto_install target,

set the distribution to unstable from UNRELEASED

update your copyright to a more complete version
(you can take example from there)
https://sources.debian.net/src/debomatic/0.21-1/debian/copyright/

and we might be good to go.

cheers,

G.

Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"

[Johannes Schauer]

Hi,

Quoting Ian Jackson (2015-10-10 18:07:02)
> > after a "dgit push" of the package src:pdfrw I got a REJECT from ftpmaster
> > because "Source-only uploads to NEW are not allowed". Since the source
> > package is not yet in Debian I guess this talks about an upload to
> > binary-NEW.
> 
> Looking at the ftpmaster db I think you misspoke.  You said "the
> source package is not yet in Debian" but in fact it appears that 0.1-3
> is in sid.

whoops, that sentence indeed had a *not* too many. Yes, the package was in sid
and my upload added two more binary packages, meaning it is now in binary-new.

> > Here are two issues I have with this (close this bug as you see fit):
> > 
> >  1. dgit is Debian specific so I guess it might be reasonable to assume
> > that it encodes Debian specific rules like the above such that I can
> > never do a "dgit push" of a source-only .changes file if there are
> > new binary packages in the upload compared to the last
> 
> By definition a source-only upload doesn't involve dgit seeing the
> binary packages.  I'm not even sure that it is possible to determine which
> binary packages ought to be produced without doing the actual build.

As far as I remember, even source packages which generate debian/control from a
debian/control.in must ship their generated debian/control. So it should be
possible to use debian/control together with dpkg-genchanges to retrieve the
list of binary packages.

> So this would be tricky.  (But how does the dak tell: does it process
> debian/control?)

I do not know either what dak does. Maybe it uses the Binary field of the
.changes file which lists the binary packages of the uploaded source package
even for a source-only upload? That field is also part of the .dsc.

> Also it would be possible for dgit to see that the package is entirely new
> (which I think it is in your case) and to know to reject a source-only upload
> in that case.

Is there a "not" missing above?

dgit could compare the Binary field of the previous .dsc file with the one of
the new .dsc file and check if there are any changes in its value.

> dgit is not Debian-specific, but it does have the ability to apply different
> rules to different archives.  OTOH the more policy information like this I
> encode in dgit, the more I have to track ftpmaster's policy changes.  I don't
> know if this ftpmaster rule is likely to change.

Sorry me neither. I just know that it was bothersome for me that I only noticed
my error after the "dgit push" and then had no idea how to fix the problem
because I cannot just rebuild and dput again as I'd otherwise do.

> >  2. I do not see documentation of how to fix this situation. Is the only
> > way around to bump my Debian revision to -2, rebuild with binaries and
> > then do "dgit push" again? Or is there a way to mangle my source-only
> > .changes file file I already have such that it contains the new binary
> > packages while at the same time doesn't break any of
> > dgits expectations?
> 
> Ideally you should bump the revision, yes, because the old tag and
> signed .dsc and .changes for the old package are out in the wild with
> your signature on.

But they didn't reach the archive yet, so they've been deleted. Not even I
could retrieve the stuff I uploaded from there anymore.

> You will need to tell dgit --deliberately-include-questionable-history
> because it doesn't know why the package was REJECTed and it wants to be told
> that it's not because of copyright problems (in which case ideally you would
> provide a differnet git history as well as a different package).

Aha, so --deliberately-include-questionable-history is the knob I have to turn.
That wasn't clear to me from the documentation before you told me to use it,
and reading the documentation again it is still not clear to me how that option
works, why it exists and how it fixes my problem.

From the context I assume that this option lets me do a `dgit push` even though
I already pushed that exact same version? If so, then maybe this should be
mentioned in the description of the option?

I was also wondering about why the mentioning of copyright and
redistributability reasons is important there. I can think of many other
reasons why there could be a REJECT after a dgit push including the one we
talked about in #800060 which was REJECTED because of a hash sum mismatch.

So is --deliberately-include-questionable-history indeed the right option I
want to do a `dgit push` of a fixed .changes or .dsc file after a REJECTED
upload (assuming I didn't change anything of the packaging but just did a
rebuild with different options)?

> In some circumstances you might need to say --dpkg-genchanges:-sa I think, to
> tell dgit to tell dpkg-genchanges to include the original source, or
> --dpkg-genchanges:-sd to tell dgit tell dpkg-genchanges not to.  I'm not 100%
> sure which the archive requires but given that 0.2-1 is in new I guess it can
> reuse the old .orig, in 

Bug#801318: jessie-pu: package postgresql-9.1/9.1.19-0+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2015-10-08 at 17:25 +0200, Christoph Berg wrote:
> postgresql-9.1 (9.1.19-0+deb8u1) jessie; urgency=medium
> 
>   * New upstream version, relevant PL/Perl change:
> + Fix plperl to handle non-ASCII error message texts correctly.

Flagged for acceptance, thanks.

Regards,

Adam

Bug#801463: BUG: unable to handle kernel NULL pointer dereference at 00000001 in smp_apic_timer_interrupt

[Richard Kettlewell]

On 2015-10-10 18:49, Ben Hutchings wrote:
> This looks rather like a hardware failure, as the instruction pointer
> is pointing to the middle of an instruction.  Here's the disassembly of
>  smp_apic_timer_interrupt:

Thanks for the diagnosis.  Time to spend some money l-/

For future reference, is there a convenient way to get a disassembly
corresponding to the kernel I have installed?

ttfn/rjk

Bug#800793: jessie-pu: package netcfg/1.131+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2015-10-03 at 18:23 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2015-10-03 at 18:44 +0200, Philipp Kern wrote:
> > I would like to fix netcfg in stable and allow KVM on s390x to boot the
> > installer with working networking. The simple patch is this and is
> > already in testing.
> > 
> > diff --git a/debian/changelog b/debian/changelog
> > index 8dc90b9..4f2d3bc 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,10 @@
> > +netcfg (1.131+deb8u1) stable; urgency=medium
> > +
> > +  * Fix is_layer3_qeth on s390x to avoid bailing out if the network
> > +driver is not qeth. (Closes: #798376)
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#800006: Tested patches for Jessie and Wheezy

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2015-10-07 at 13:42 +0100, Adam D. Barratt wrote:
> On 2015-10-07 10:36, Bastian Blank wrote:
> > Hi
> > 
> > Attached are tested diffs for Jessie and Wheezy.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#801471: cryptsetup: Update remote unlocking via SSH due following the dropbear 2015.68-1 release.

[Guilhem Moulin]

Control: block -1 by 782024

On Sat, 10 Oct 2015 at 21:42:27 +0200, Guilhem Moulin wrote:
> Hence /usr/share/doc/cryptsetup/README.Debian.gz section 8, as well as
> /usr/share/doc/cryptsetup/README.remote.gz, have to be updated to point
> to the new package name (dropbear-initramfs) and to mention the new
> features and configuration options.  Patch enclosed.

The 'unlock' script mentioned in the patched
/usr/share/doc/cryptsetup/README.Debian is taken from #782024.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP

[Daniel Bailey]

Ah, okay, no problem. Fixed it.
Dan.

On 10/10/15 20:29, Gianfranco Costamagna wrote:

Hi,

nack :)

gpl-3+ is different from GPL-3+

It might be a nitpick but I didn't find any other program with that syntax

search on codesearch.debian.net

GPL-3+ path:/copyright$

vs

gpl-3+ path:/copyright$


cheers,

G.

Il Sabato 10 Ottobre 2015 20:45, Daniel Bailey  ha scritto:

On 10/10/15 19:06, Gianfranco Costamagna wrote:

That was a (sfortunate) issue due to the line wrapping.

I thought it would be something like that




so, now please use tab instead of spaces in the dh_auto_install target,

Oops, my mistake, my editor converted the tab, I've fixed it now.

set the distribution to unstable from UNRELEASED

Done.

update your copyright to a more complete version
(you can take example from there)
https://sources.debian.net/src/debomatic/0.21-1/debian/copyright/

Done.


and we might be good to go.

cheers,

G.



I hope that's everything complete, Thanks for all the help.
Dan.

Bug#800664: jessie-pu: package wxmaxima/13.04.2-4+b1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2015-10-02 at 15:51 +0200, Gunter Königsmann wrote:
> Then thanks a lot for your help!
> 
> 
> The debdiff with the corrected version number is attached to this
> mail.

Please go ahead.

Regards,

Adam

Bug#740749: merge dante "new upstream version" bugs

[Peter Pentchev]

reassign 740749 src:dante
package src:dante
severity 740749 important
severity 801422 important
merge 791453 740749
merge 801422 740749
thanks

I'm working on it now; I've reimported all the Dante packaging
work in a new full-source repository (not just debian/), and
I'm working on 1.4.1 as we speak.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#787966: libtiff5: LZW compression doesn't work with GIMP.

[Jussi Hukkanen]

I can't see any easy workaround other than, obviously, not using LZW
compression.

However, the problem seems to have been fixed in libtiff 4.0.5. Now
there's also 4.0.6, which I haven't tried:
http://download.osgeo.org/libtiff/

You need to build and install the new version and make sure GIMP (or
whatever software you're using) sees it instead of the buggy 4.0.3.
Now LZW seems to work.

-- jussi.hukka...@gmail.com
What if this weren't a hypothetical question?

Bug#801464: redis-server: Socket placed at /tmp/systemd-private-$ subfolder

[Chris Lamb]

tags 801464 + pending
kthxbye

> > Would you be okay if I changed the (commented-out) default to somewhere
> > in, say, /var/run?
>
> That probably would be the best thing to do here. redis-server itself
> has no permissions to write directly into /var/run but in /var/run/redis

Whoops, I meant to say "under /var/run" :)  I'll change the default now.

> >  [..] PrivateTmp=True [..]
> 
> Ah, thats the reason for this extra tmp folder.

Indeed, it's one of the rather neat things about systemd - very easy to
toggle some cheap hardening features. Check the manual for more and
suggestions welcome.


Regards,

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

Bug#799758: jessie-pu: package apt-dater-host/1.0.0-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2015-09-22 at 10:20 +0200, Patrick Matthäi wrote:
> could I upload this package for the next jessie-pu? It fixes #794630

Please go ahead.

Regards,

Adam

Bug#798855: josm: Download from OSM... gives just a blank window

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 14-09-15 00:23, Sebastiaan Couwenberg wrote:
> On 14-09-15 00:07, Jonas Smedegaard wrote:
>> Quoting Jonas Smedegaard (2015-09-14 00:00:23)
>>> Quoting Sebastiaan Couwenberg (2015-09-13 22:09:11)
 Your debug output doesn't show anything out of the ordinary.
 So I still have no clue what's different on your system to
 break josm. Maybe a GPU driver issue that fumbles drawing the
 new windows.
>>> 
>>> My machine is a Lenovo Edge 145 laptop with AMD Radeon HD 8240 
>>> GPU using the free driver.
>>> 
>>> A possible difference - if you tested with both those DEs 
>>> installed - might be some package dependency missing from josm
>>> or a java library which gets pulled in by larger DEs and
>>> therefore often unnoticed.  I use Awesome and mostly GTK-based 
>>> applications, avoiding both KDE and GNOME as much as I can.  I
>>> do generally respect recommends, however - attached is the list
>>> of unsatisfied reverse recommends (too long, as some are
>>> satisfied by alternative packages).
> 
> Awesome doesn't appear to be a good choice of DE. I can reproduce
> the problem with josm under awesome. This issue should probably be 
> reassigned to awesome, this isn't an issue with josm.

I've tested this issue with the new JOSM 8800 from experimental, which
still has this issue.

Interestingly the 'Download from OSM' window does work, new tiles get
downloaded when zooming with the scroll wheel and hitting enter
downloads the area in question, it just doesn't get rendered.

Jonas, do you think it's worthwhile to reassign this issue to awesome?

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGRmOAAoJEGdQ8QrojUrx2K0QAImhZjHRnjLPtx4G6oBl8f9U
WRlCV3SVfi8xYz++tF4jBqSrriKpeujVC2cc91pyvPSJ3masSMf4SfAKJhgf011M
EV84Ti4zvL9Z37TR8+7JcitLgSLNuIe/plhX16BUmHuzaIn5gq8ZFcNy2fn/Z5NN
tsBYPR9EIeZjvt0X4bMI8TnffWkSxypyyCmBbstr6mGrr9C7+IiTj10id77ytGN0
vKFVA3NhazS87wtMlg5i3iY2qYlcCw/Lr6Jdt0rUECz1M6QlD6M7d1gF2/6k0z/c
a2SSPD0ZFNjjk0tlJTDjyEMblFqwyXtlgl30qcAC9FB9EQmtvlTovzHk9B7a+qFY
iLaY9OUk1ZqNt9lH3FRhn7b3ajrgKcQQSTWSeqjD57hIBHf69P3vQv4C3lofYhNv
KK0+fQmJGWjZGdYG8V+8WGVaYut0DTr2aaQ00PtCZjste6PxusdNCENIK+4IEdIW
PXjDv+DB2lvNFD/GH8SLQhjyj5/w9ToUefdGI+QH6utltkp1GoDws/XqMgs9LiHv
28ZFR4MkCtcuNo+o9Zw4JsAcrAHCiZopP6srO+i5L02CspaS/T0RQoqzPib111Aq
M8B/3OLkTx4z5juLXSFH7vEgrNmJWmPCDYhmrUBd90YZxJSm+l6TupBCxl6jVQBx
0u/cQEbmV70/6JGnsLjf
=L6dq
-END PGP SIGNATURE-

Bug#801136: mpd-sima: Troublesome with proxies

[Geoff]

Followup-For: Bug #801136
Package: mpd-sima
Tags: patch, confirmed

Here is a patch, it should merge available HTTPS?_PROXIES variables.
I will patch the debian package if it takes too long to release the next
upstream version including this fix.

I haven't fully tested the solution yet.
Don't hesitate to give it a try, the patch should merge fine on 0.13.

I'll have a look at the packaging part later.

Cheers
Geoff

Le 10/10/2015 15:07, Geoff a écrit :
> Hi Chris,
> 
> Thanks very much for your report :)
> 
> Two issues then :
> 
> [packaging] http proxies env. var should be exposed when using
> systemd/SystV.
> 
> [upstream] the http client should actually use them ^^
> The http client bug was forwarded upstream, the issue is
> identified/nearly fixed. Python requests is actually not honoring
> HTTP_PROXY because of the use of the lower level API in the http client
> which in turn is not propagating environment variables…
> 
> I'll try to fix this as soon as I can (I'm also the upstream developer).
> 
> Thanks again.
> Geoff
> 
> The 06/10/2015 17:46, Chris Chiappa wrote :
>> […]
>> Behind a proxy, I've found it very difficult to get mpd-sima to use it
>> for last.fm access.  python-requests documentation at
>> http://docs.python-requests.org/en/latest/ says it should pay
>> attention to the HTTP_PROXY and HTTPS_PROXY environment variables.  I
>> created /etc/systemd/system/mpd-sima.service.d/override.conf
>> with
>>
>> [Service]
>> Environment="HTTP_PROXY=http://proxy.company.com:80;
>> Environment="HTTPS_PROXY=http://proxy.company.com:80;
>>
>> and restarted mpd-sima.  In /proc//environ I can see both
>> environment variables, but from both strace and mpd-sima's log I can
>> see that it's failing to connect to last.fm.  I was able to get it to
>> work by hacking fetch_ws in http.py and manually specifying proxies:
>>
>> @Throttle(WAIT_BETWEEN_REQUESTS)
>> def fetch_ws(self, prepreq):
>> proxies = {
>> "http"  : "http://proxy.company.com:80;,
>> "https" : "http://proxy.company.com:80;
>> }
>> """fetch from web service"""
>> sess = Session()
>> sess.proxies = proxies
>> resp = sess.send(prepreq, timeout=SOCKET_TIMEOUT)
>> ...
>>
>> but that's obviously not the right way to do it.  Not being a python
>> hacker I'm not sure how to tell why the envrironment variables aren't
>> working, but it seems like having some better way of configuring
>> proxies might be desirable anyhow.
> 
diff --git a/sima/lib/http.py b/sima/lib/http.py
index 0c1b396..10fae9c 100644
--- a/sima/lib/http.py
+++ b/sima/lib/http.py
@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-
 
-# Copyright (c) 2014 Jack Kaliko 
+# Copyright (c) 2014-2015 Jack Kaliko 
 # Copyright (c) 2012, 2013 Eric Larson 
 #
 #   This program is free software: you can redistribute it and/or modify
@@ -301,7 +301,8 @@ class HttpClient:
 def fetch_ws(self, prepreq):
 """fetch from web service"""
 sess = Session()
-resp = sess.send(prepreq, timeout=SOCKET_TIMEOUT)
+settings = sess.merge_environment_settings(prepreq.url, {}, None, False, None)
+resp = sess.send(prepreq, timeout=SOCKET_TIMEOUT, **settings)
 if resp.status_code == 304:
 self.stats.update(etag=self.stats.get('etag')+1)
 resp = self.controller.update_cached_response(prepreq, resp)


signature.asc
Description: OpenPGP digital signature

Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Zhang,

2015-10-10 04:27 张敬强:

On Sat, 10 Oct 2015 09:56:50 +0800 Zhang Jingqiang  wrote:

Step to reproduce the bug:
1.Install maint-guide, debian-policy, devscripts, doc-base, dput, fakeroot, 
lintian
  make sure all marked as auto-installed except maint-guide
2.run "aptitude"
3.Mark maint-guide as purge, this will lead to many packages (>= 27 on my case) 
marked as remove
4.Pree "g" to review the action
5.Mark "Packages being removed because they are no longer used" as purge, then 
crash occur
6.run "aptitude", then mark maint-guide as purge, the number of pkgs marked as 
remove is reduced
  as many perl pkgs has been marked as manually installed, uninstall all pkgs 
except these perl pkgs
7.Now mark all these perl pkgs as remove, press 'g', mark them as purge, crash


The bug is caused by libxmlrpc-lite-perl and libsoap-lite-perl
libsoap-lite-perl depends libxmlrpc-lite-perl, while the latter one recommends 
the previous one.
 
The step to reproduce:
1.Install libsoap-lite-perl, make sure libxmlrpc-lite-perl is marked as 
auto-installed
2.Select package libsoap-lite-perl, Press 'M'
3.Press 'g'
4.Select libxmlrpc-lite-perl or libsoap-lite-perl, press '_'
5.crash


I cannot reproduce it as it is, maybe because I have devscripts
installed, which recommends libsoap-lite-perl.

But interested to know, do you have ::Purge-Unused enabled in (user or
root's) ~/.aptitude/config ?  Can you post that file?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack

[Felipe Sateler]

On 10 October 2015 at 12:14, Stephen Dowdy  wrote:
>
> On Sat, Oct 10, 2015 at 6:42 AM, Felipe Sateler  wrote:
>>
>> I don't understand. Do you mean that if you plug into headphone jack
>> you do not have this problem? And that the problem only reveals itself
>> after plugging the speakers into the line-out jack and selecting Line
>> Out / Speakers / Analog Output port[1]?
>>
>> [1] This being worse because one of these is selected by default?
>
>
> Felipe,
>
> I have not tried headphones themselves, but if i plug the external speakers
> into the headphone jack on the workstation, the problem disappears.  Also,
> if i select the headphone "port" in software (pavucontrol) while the
> external speakers are still plugged into the line-out jack (either front or
> back jack of my system, a Dell Precision Workstation, the problem goes away,
> as well.

OK

>
> If i move the external speakers from the headphone jack back to the line-out
> jack, the automatic jack selection code reverts to the "No Bass" situation.
> (but, again, i can manually "fix" it, by selecting the headphone port in
> pavucontrol.  I'd *expect* that to route the sound through the headphone
> jack, and i should hear *nothing* at that point, but that's not the case).

Yes, that's what I'd expect too.  I have uploaded a backport of
pulseaudio 7 (that has changed the mappings a bit, so this may be
fixed). Unfortunately it has not been accepted yet, but you could
install manually from here:

http://debomatic-amd64.debian.net/distribution#jessie-backports/pulseaudio/7.0-1~bpo8+1

Please report if the problem also occurs there.

-- 

Saludos,
Felipe Sateler

Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP

[Daniel Bailey]

Okay, I've update the upstream makefile and the rules file as per you 
suggestion except for the change to the pod2man command which removes 
the end of the line, that change would break the makefile.

Is this is a mistake or is there something I have missed?

Thanks,
Dan.
On 27/09/15 16:48, Gianfranco Costamagna wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: owner -1 !
Hi Daniel,


I'm not sure what's wrong here, the upstream makefile contains this
  install rule which installs the script and the man page, have I
done something wrong?: install: all

install webdeploy $(DESTDIR)$(bindir)

install -m 0644 webdeploy.1 $(DESTDIR)$(man1dir)



well, it might be good, just I don't like custom makefiles :)


5) install the manpage too.

(see above)

6) use debian/dirs to create directories, or fix the Makefile :)

Sorry, once again, complete beginner, what is wrong with the
makefile here?

I'm not sure about perl:Depends, since there is no perl in build
dependencies. (also shlibs:depends and so on, because you don't
have any shared library)

I think this was the result of using dh_perl. I expected it to find
the libterm-readkey-perl Requirement but it didn't, It did however
add perl as a dependancy. Also, perl is in the build-depends in the
control file as it contains the pod2man program for generating the
man page. Is there anything I need to change here? Should I remove
the shlibs:depends from the control file?

I'm not sure about this but well, seems good!


Last issues:

this is how I would patch the Makefile:
- --- webdeploy-1.0.orig/Makefile
+++ webdeploy-1.0/Makefile
@@ -13,6 +13,7 @@ webdeploy.1: webdeploy
 pod2man --name=WebDeploy -c"WebDeploy - Deploy files via FTP"
- --section=1 --release="Version $(VERSION)" $< > $@

  install: all
+   install -d $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir)
 install webdeploy $(DESTDIR)$(bindir)
 install -m 0644 webdeploy.1 $(DESTDIR)$(man1dir)


removing the debian/webdeploy.dirs
and how I would use the install override:

override_dh_auto_install:
 dh_auto_install -- prefix=/usr


what do you think about?

cheers,

Gianfranco
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCA+2AAoJEPNPCXROn13ZYYwQAJXA4lKw5y7Wh8IQhCxZStVk
PrsdmTDbFN9sSXd0ddy3QVP75IIiZJl0A9mDE8I4UO7NKV4XXh0baw8dsNfgPg6d
OxODzMaWPGU7s0POrDVD6FoywKYpnLnvGWvXumBLGQNhKDHP+PU923gVgQ7taXyd
EonBLSoorD9iLnR1yH+oNennAaCA2TkQkmMRUrWXbbAZN9cZWYH07k26/qZ8uehA
0adUM67HVaGgCvd4CJ7zYT40h/AqzdnPi9Th1rjfwaEEPOWGARKfpoALN/XeB6OH
pazQUmV6MAzTA26kGWAKbZwpwB5t/VsRfF0M+uk3rCucJNedLwp1fj3HT8LIJOyK
QQr7NGtWVmt07lZjEBHj0j8hbCOkBCf9/O3DZjABrQKUr/I6bHLOPrVueQdDThpq
s5aPLhx9gwj+gEsyP+zSYCZNMWvRqcI/itMlM5mDOOe9y5zMOtlSeUyQ2GvSBCyV
ED4QUXSAwPLlYCF0FNG7xNDovVXgYwX73xkn8EgjzAjtBx181dg3Zq8YZboss75b
I+P0kCXeE0e5edufRM7IGLV1a+q4ON7K9yv1N0mpwtCcAPtxjEFw6l0KCdU0hOmb
ye5ATyuaut8c0D/mXCXHVDERq+jJc0RMprXz5owg8r+n/gBGlg9Lz6ThKVf745cD
yLMKglEmjkXvIfUQgEPo
=i5qg
-END PGP SIGNATURE-

Bug#801459: FTBFS with OCaml 4.02.3

[Stéphane Glondu]

Package: src:coccinelle
Version: 1.0.0.deb-1
Severity: serious

Dear Maintainer,

coccinelle fails to build on all architectures:

  https://buildd.debian.org/status/package.php?p=coccinelle=sid

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.1.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)

Bug#801460: aptitude: Does not show long description anymore

[Matijs van Zuijlen]

Package: aptitude
Version: 0.7.3-1
Severity: normal

Dear maintainer,

Since the upgrade to 0.7.3-1 (I think), aptitude no longer shows the
extended part of the description of the packages. Only the first line is
shown. A check with apt-cache shows the data is still there.

Regards,
Matijs

-- 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 (0x7ffefedf2000)
libapt-pkg.so.4.16 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.16 
(0x7f96d7bae000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f96d797e000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f96d7753000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f96d754d000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f96d724e000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f96d6f8)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f96d6d67000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f96d6965000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f96d6747000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f96d63cc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f96d60cb000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f96d5eb4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f96d5b0b000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f96d5908000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f96d5703000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f96d54e8000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f96d52d8000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f96d50b4000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f96d4eac000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f96d4ca6000)
/lib64/ld-linux-x86-64.so.2 (0x56210c551000)

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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
ii  debtags   2.0.1
pn  tasksel   

-- no debconf information

Bug#801464: redis-server: Socket placed at /tmp/systemd-private-$ subfolder

[Chris]

Package: redis-server
Version: 2:3.0.4-6
Severity: normal

Dear Maintainer,

after one of the latest updates for redis-server the unix socket configured in 
redis.conf is not found anymore at the specified path.
Instead a folder like:

/tmp/systemd-private-7bef6990f0be4054879de6df5772fc02-redis-server.service-IZieHa/tmp/

is created and the socket file is placed there. This is an unexpected
behavior and leads to confusion if you specify a:

unixsocket /tmp/redis.sock

and the file is ending up in a completely different location.

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

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

Versions of packages redis-server depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.23
ii  libc62.19-22
ii  libjemalloc1 3.6.0-3
ii  redis-tools  2:3.0.4-6

redis-server recommends no packages.

redis-server suggests no packages.

-- Configuration Files:
/etc/redis/redis.conf changed:
daemonize yes
pidfile /var/run/redis/redis-server.pid
port 0
tcp-backlog 511
bind 127.0.0.1
unixsocket /tmp/redis.sock
unixsocketperm 770
timeout 0
tcp-keepalive 0
loglevel notice
logfile /var/log/redis/redis-server.log
databases 16
save 900 1
save 300 10
save 60 1
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 1
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes


-- no debconf information

Bug#801460: aptitude: Does not show long description anymore

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Matijs,

2015-10-10 17:13 Matijs van Zuijlen:

Package: aptitude
Version: 0.7.3-1
Severity: normal

Dear maintainer,

Since the upgrade to 0.7.3-1 (I think), aptitude no longer shows the
extended part of the description of the packages. Only the first line is
shown. A check with apt-cache shows the data is still there.


Thanks, fixed and marked as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#801095: jessie-pu: package uqm/0.6.2.dfsg-9.1~deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2015-10-06 at 11:35 +0200, Andreas Beckmann wrote:
> uqm FTBFS in jessie due to a missing -lm (#792920).

Please go ahead.

Regards,

Adam

Bug#797462: jessie-pu: package whois/5.2.10

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2015-08-30 at 22:15 +0200, Marco d'Itri wrote:
> I think it is time for a whois stable update, are there any objections?

fwiw, this appears not to have made it to debian-release.

> These are all data changes, plus a little debian/rules cleanup.

None of those cleanups appear to have ever been mentioned in the
changelog. The diff as provided also doesn't include the changelog
stanza for the proposed upload - assuming that a rebuild on jessie
exactly matches the diff you attached other than that, please go ahead
as 5.2.10~deb8u1.

Regards,

Adam

Bug#798990: RFS: webdeploy/1.0-1 ITP #798716 -- deploy files via FTP

[Gianfranco Costamagna]

Hi,

nack :)

gpl-3+ is different from GPL-3+

It might be a nitpick but I didn't find any other program with that syntax

search on codesearch.debian.net

GPL-3+ path:/copyright$

vs

gpl-3+ path:/copyright$


cheers,

G.

Il Sabato 10 Ottobre 2015 20:45, Daniel Bailey  ha scritto:

On 10/10/15 19:06, Gianfranco Costamagna wrote:
> That was a (sfortunate) issue due to the line wrapping.
I thought it would be something like that
>
>
>
>
> so, now please use tab instead of spaces in the dh_auto_install target,
Oops, my mistake, my editor converted the tab, I've fixed it now.
>
> set the distribution to unstable from UNRELEASED
Done.
>
> update your copyright to a more complete version
> (you can take example from there)
> https://sources.debian.net/src/debomatic/0.21-1/debian/copyright/
Done.

>
> and we might be good to go.
>
> cheers,
>
> G.
>
>
I hope that's everything complete, Thanks for all the help.
Dan.

Bug#786980: heimdahl: german package translation misleading

[Holger Wansing]

Hi,

Andrei POPESCU  wrote:
> On Sb, 10 oct 15, 10:22:27, Holger Levsen wrote:
> > 
> > I don't wanna translate. I have seen a severe bug in a package description 
> > translation which I would like to report (so that it get's tracked and 
> > fixed 
> > eventually), as it's misleading to the users. So I filed the bug against 
> > the 
> > package, which was closed as the description translation is not part of the 
> > package.
> > 
> > The translation of that package description  is still buggy, now what to do?
> 
> The DDTP wiki page acknowledges that it is missing bug tracking, but 
> considering that it hasn't seen much development in recent years and 
> what other infrastructure is available *now* the best thing I can think 
> of are pseudo-packages for each language team, e.g.

+1 for pseudo-packages

Even if it's a better workflow to just fix the issues you find in a
package description, instead of filing a bug, there will still be the 
possibility that people, who are not active in the Debian project, 
find issues in a package description. 
Having a proper place for them to report such issues would be good.

Of course, if has to be documented at some prominent place, so that normal 
users know, where to report issues in package descriptions.




Regards
Holger

-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#798672: qdox: please upgrade qdox to version 2.x

[Markus Koschany]

On Mon, 05 Oct 2015 16:27:35 +0200 Markus Koschany  wrote:
> Control: tags -1 patch
> 
> I have pushed the new release to Git master. I took the opportunity to
> make some major cleanups and I switched to Maven and maven-debian-helper.
> 
> I have tested a few reverse-dependencies and quickly realized that
> probably all would need an update as well. The main reason is that the
> class JavaDocBuilder was replaced by JavaProjectBuilder. :(

FTR:

It seems Fedora already completed this transition and I have found
patches e.g. [1] for some of qdox r-deps. So probably it's not as bad as
it looks

Markus

[1]
http://pkgs.fedoraproject.org/cgit/xbean.git/tree/0003-Port-to-QDox-2.0.patch



signature.asc
Description: OpenPGP digital signature

Bug#801467: base: Boot process freezes dead after kernel upgrade linux-image-3.2.0-4-686-pae:i386 3.2.71-2

[Piyavkin]

Package: base
Justification: breaks the whole system
Severity: critical

Dear Maintainer,

I'm using Debian 7 Wheezy for a long time. In 2015-10-07 I've applied 
proposed upgrades:


libfreetype6:i386 2.4.9-1.1+deb7u1 2.4.9-1.1+deb7u2
linux-image-3.2.0-4-486:i386 3.2.68-1+deb7u4 3.2.71-2
linux-image-3.2.0-4-686-pae:i386 3.2.68-1+deb7u4 3.2.71-2
linux-headers-3.2.0-4-686-pae:i386 3.2.68-1+deb7u4 3.2.71-2
linux-headers-3.2.0-4-486:i386 3.2.68-1+deb7u4 3.2.71-2
linux-headers-3.2.0-4-common:i386 3.2.68-1+deb7u4 3.2.71-2
linux-libc-dev:i386 3.2.68-1+deb7u4 3.2.71-2

On the other day I wasn't able to boot up my system, because it freezes 
dead at boot process. Just right before login screen should appear. In 
the moment the system switches from character-mode to graphical one, the 
system stuck forever with black screen and clock-shaped mouse pointer in 
the right bottom corner (mouse/touchpad or keyboard aren't active). The 
only option here is to turn off computer with hard power button.


No one of the stated above kernel versions or their rescue modes doesn't 
work. The same result (as described above) for all of them.


Though I've found that I can normally run any LiveCDs that I have 
(Xubuntu, Debian 7 — from which the system was installed).


And I can run any of the stated above kernels if I use kernel option 
«acpi=off» (modifying bootup command in the grub2 menu). It works as 
usual, except Gnom3 doesn't start (probably, requires some ACPI 
services), Gnome2 fallback starts instead, and the system doesn't switch 
off properly, may be something else.


I'm using Debian GNU/Linux 7.9 (wheezy), kernel version 3.2.0-4-686-pae 
(gcc version 4.6.3 (Debian 4.6.3-14)) on at least 7 years old Dell 
Inspiron 1525 notebook.


dpkg -s libc6 | grep ^Version
Version: 2.13-38+deb7u8

Also I found that at least one other user has exactly the same problem:

https://lists.debian.org/debian-user/2015/10/msg00175.html
Machine freezes after kernel update
After the last kernel update and restart, a wheezy-based machine (laptop 
running 7.9) boots to some point, however it freezes just before opening 
GUI. Access to CLI (Ctrl-Alt-F1 etc) is also not possible. What to do to 
recover?

Sat Oct 10 2015 20:56:18 GMT+0300 (MSK)

See full discussion there. In short: he encounters the same problem with 
the same updates. Old kernel versions are missing from bootloader menu 
(and from the system, actually). He managed to access the file system by 
using rescue CD, and found the older kernel images were archived in 
/var/cache/apt/archives as .deb packages. There were 3.2.68-1+deb7u4 
images & headers (that worked perfectly), however apt-get install still 
wants to use "newest" version 3.2.71-2 (that produced the problem). 
Then, he somehow managed to start the system with CLI and had 
reinstalled the old kernel versions from .deb ( dpkg -i 
/path/to/packagename.deb ). The problem with boot process was solved for 
him.


The same with me: he uses LILO, I use Grub. But it hadn't saved old good 
kernel versions in the exactly same manner. I have no option of previous 
kernel versions in bootloader menu either. And I've never tweaked Grub 
on the computer, it's how it works out of the box of standard Debian 7 
installation. So, if newly installed kernel version doesn't work 
properly for me, I have no simple way to return to the previous working one.


I've done the same downgrade as him. I've loaded  with kernel option 
«--add rw init=/bin/bash» (modifying bootup command in the grub2 menu), 
it gave me CLI with root access. Then with command «dpkg -i» I've 
reinstalled the packages from cache:


linux-image-3.2.0-4-486_3.2.68-1+deb7u4_i386.deb
linux-image-3.2.0-4-686-pae_3.2.68-1+deb7u4_i386.deb
linux-headers-3.2.0-4-common_3.2.68-1+deb7u4_i386.deb
linux-headers-3.2.0-4-486_3.2.68-1+deb7u4_i386.deb
linux-headers-3.2.0-4-686-pae_3.2.68-1+deb7u4_i386.deb

Images related to 3.2.71-2 packages were completely removed. After that 
I can boot my system normally again.


Though, the questions are: what exactly caused the problem? Is it some 
bug in kernel beyond my appreciation or something wrong with my PC (old 
BIOS, falling apart hardware, weird settings, etc.), which possible lead 
to more problems in future?


And what should we do with future upgrades from now?

Thanks in advance!


Best regards,
Dmitry Piyavkin

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

Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#801317: wheezy-pu: package postgresql-9.1/9.1.19-0+deb7u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2015-10-08 at 17:21 +0200, Christoph Berg wrote:
> postgresql-9.1 (9.1.19-0+deb7u1) wheezy; urgency=medium
> 
>   * New upstream version.
> 
> + Fix contrib/pgcrypto to detect and report too-short crypt() salts
>   (Josh Kupershmidt)
> 
>   Certain invalid salt arguments crashed the server or disclosed a few
>   bytes of server memory.  We have not ruled out the viability of attacks
>   that arrange for presence of confidential information in the disclosed
>   bytes, but they seem unlikely.  (CVE-2015-5288)

This appears to have been rejected by dak:

adsb@franck:~$ cat 
queue/reject/postgresql-9.1_9.1.19-0+deb7u1_source.changes.reason 

postgresql-9.1_9.1.19-0+deb7u1.dsc: Refers to non-existing file 
'postgresql-9.1_9.1.19-0+deb7u1.debian.tar.gz'
Perhaps you need to include the file in your upload?

Regards,

Adam

Bug#801464: redis-server: Socket placed at /tmp/systemd-private-$ subfolder

[Chris]

Hi Chris,

On 10/10/2015 07:55 PM, Chris Lamb wrote:
>> unixsocket /tmp/redis.sock
> 
> So, I'm not sure "/tmp" is really a suitable location for a system-wide
> socket file.

just have used that because OpenVAS is defaulting to this location but i
agree that this is not the best location. There seems to be also an
older bugreport about that default location here:

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

> Would you be okay if I changed the (commented-out) default to somewhere
> in, say, /var/run? That would seem to match most other daemons that use
> UNIX sockets like this (MySQL, PostgreSQL, etc. etc.)

That probably would be the best thing to do here. redis-server itself
has no permissions to write directly into /var/run but in /var/run/redis
so this is what i'm currently using.

> I don't really want to disable PrivateTmp=True as it's quite an easy
> security measure and -- as a bonus -- prevents multiple instances of
> Redis from conflicting with each other.

Ah, thats the reason for this extra tmp folder. Wasn't aware of this
functionality and the reason behind it.

Bug#799033: jessie-pu: package file/1:5.22+15-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2015-09-15 at 08:16 +0200, Christoph Biedl wrote:
> for the next jessie point relase, I'd like to upload a new version
> of the file package, in order to fix the bug described in
> 
> https://bugs.debian.org/798410
> http://mx.gw.com/pipermail/file/2015/001777.html
> 
> Short version: The handling of file's --parameter command line option
> is broken, the program segfaults upon every usage. Additionally,
> --parameter has no effect when used with --files-from.

Please go ahead.

Regards,

Adam

Bug#779998: node-string-decoder: Failing tests & not supporting nodejs 4.x yet

[Ross Gammon]

Hi,

I just investigated why the upstream tests are failing today, and it is
probably related to the recent switch to nodejs 4.1.1 in unstable.

I emailed Rod Vagg and he has not yet replied.

As his string-decoder is a fork of another string-decoder, I also raised
an issue there:
https://github.com/substack/string_decoder/issues/4

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#776540: game-data-packager: please add support for games working with gemrbd engine

[Markus Koschany]

Control: tags -1 patch pending

Am 08.10.2015 um 16:10 schrieb Alexandre Detiste:
> 2015-10-07 14:01 GMT+02:00 Markus Koschany :
>>>
>>> It's important to specify the english archive first; this one will be 
>>> considered the "original"
>>> version, and the other will have the ?lang prefix appended to files with 
>>> the same
>>> name but different size/md5.
>>
>> I tried the exact same command with the German and English windows
>> installer and it works but some files from the English version also get
>> the ?en suffix which is probably unnecessary?
>>
>> make-template outputs for example:
>> chitin.key
>> chitin.key?en
>>
>> If the English version is always considered the "base" version only
>> chitin.key should suffice.
> 
> This happens because this English archive was likely unpacked without
> using then new "--collisions=rename" innoextract flag.
> You end up with two different files names "chitin.key" & "Chitin.key".

Hi,

ok I give up for now because I can't get it to work with more than one
language version. I have pushed baldurs-gate-1.yaml to git master which
supports the English Linux installer from gog.com.

The debug information from g-d-p are very sparse. I only see

INFO:game-data-packager.build:identifying app1/movies/MOVIECD1.BIF
INFO:game-data-packager.build:identifying app1/movies/MOVIECD4.BIF
INFO:game-data-packager.build:identifying app1/data/GUI.bif
INFO:game-data-packager.build:identifying app1/data/CHAANIM.bif
ERROR:game-data-packager.build:Unable to complete any packages.

That's it and then it fails. The --verbose flag doesn't add any extra
information.

Please correct me if I am wrong: At first I used

game-data-packager make-template setup_baldurs_gate_2.0.0.20.exe
setup_baldurs_gate_german_2.0.0.20.exe > bg_en_de.txt

this produces output like chitin.key?en. How can I use g-d-p with the
--collisions=rename option of innoextract?

When I manually unpack both windows installers with innoextract
--collisions=rename and then run make-template on both unpacked
directories, I get something which looks similar to your last e-mail
attachment but it is still not the same. I've pushed my bg_en_de.txt
file to the baldurs-gate branch, in case you want to have look at it.


This whole renaming is somehow crazy. What do you think about the
following design: just declare all files with size and hashsums per
package and enforce that the user passes a language option to
game-data-packager like

game-data-packager baldurs-gate-1 --lang de 


baldurs-gate-1.yaml

size_and_md5:
  lang: en
  baldurs-gate-original-saga-en-data:
  .
  .
  .
  all detected files from the English Linux Installer with size and
  hashsums

  lang: de
  baldurs-gate-original-saga-de-data:
  .
  .
  .
  all detected files from the German Linux Installer with size and
  hashsums


I would only have to trim the raw output from make-template, remove some
files and that's it. No renaming necessary. There will be duplicate
information regarding file names, sizes and hashsums but this design is
much less error prone and simpler to maintain, IMO.

Cheers,

Markus











signature.asc
Description: OpenPGP digital signature

Bug#800378: pulseaudio: no sound with nForce3 250Gb AC'97 Audio Controller (rev a1) (Realtek ALC850 rev0)

[Felipe Sateler]

Control: tags -1 + moreinfo

On 10 October 2015 at 09:48, Felipe Sateler  wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 unreproducible
>
> On 7 October 2015 at 15:45, debianuser  wrote:
>> As requested, here is the pulseaudio log using paplay.
>> Thanks to everybody who help me.
>
> I'm afraid I'm out of places to look at now. Could you please present
> your problem at the upstream list
> (pulseaudio-disc...@lists.freedesktop.org)?
>
> I have recently uploaded a backport of pulseaudio 7.0 but it hasn't
> been accepted yet. Then you might want to try if upgrading pulseaudio
> to version 7 fixes your problem.

You can fetch it from here in the meantime:

http://debomatic-amd64.debian.net/distribution#jessie-backports/pulseaudio/7.0-1~bpo8+1


-- 

Saludos,
Felipe Sateler

Bug#776540: game-data-packager: please add support for games working with gemrbd engine

[Alexandre Detiste]

Le samedi 10 octobre 2015, 17:16:51 Markus Koschany a écrit :
> Control: tags -1 patch pending
> 
> Hi,
> 
> ok I give up for now because I can't get it to work with more than one
> language version. I have pushed baldurs-gate-1.yaml to git master which
> supports the English Linux installer from gog.com.

Thanks

I commited these tow more thins:

- I liked the shorter packager names in the test branch better
("baldurs-gate-1-data" or "baldurs-gate1-data");
I picked that up from there; the 'marketing name' remain
in the package short description.

- I don't yet know if gemreb is case-sensitive;
but for the documentation in /usr/share/doc/ that should
never matter. If these files were needed at runtime they would
need to go in /usr/share/games anyway.

> The debug information from g-d-p are very sparse. I only see

with "DEBUG=1 ./run " you'll get pages & pages of log,
maybe some of this was needed when building the core
functionality and could be disabled now.

> That's it and then it fails. The --verbose flag doesn't add any extra
> information.

The --verbose flag show output from the external tools.

Showing the missing files when --package is explicitely defined
would be a plus !

> Please correct me if I am wrong: At first I used
> 
> game-data-packager make-template setup_baldurs_gate_2.0.0.20.exe
> setup_baldurs_gate_german_2.0.0.20.exe > bg_en_de.txt
> 
> this produces output like chitin.key?en. How can I use g-d-p with the
> --collisions=rename option of innoextract?

That's not yet implemented & this is the exactly only
game that would need this and can't be packaged with innoextract 1.4-1
& I'll have to recheck all the other archives with this --collisions=rename 
flag.

> When I manually unpack both windows installers with innoextract
> --collisions=rename and then run make-template on both unpacked
> directories, I get something which looks similar to your last e-mail
> attachment but it is still not the same. I've pushed my bg_en_de.txt
> file to the baldurs-gate branch, in case you want to have look at it.

Thanks

> This whole renaming is somehow crazy. What do you think about the
> following design: just declare all files with size and hashsums per
> package and enforce that the user passes a language option to
> game-data-packager like
> 
> game-data-packager baldurs-gate-1 --lang de 
> I would only have to trim the raw output from make-template, remove some
> files and that's it. No renaming necessary. There will be duplicate
> information regarding file names, sizes and hashsums but this design is
> much less error prone and simpler to maintain, IMO.

I think it should be easier & less error-prove to package Baldur's Gate the
current way than changing everything else; make-template is already quite 
improved.


Greets,

Alexandre



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

Bug#798855: josm: Download from OSM... gives just a blank window

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10-10-15 18:58, Jonas Smedegaard wrote:
> Quoting Sebastiaan Couwenberg (2015-10-10 15:58:42)
>> On 14-09-15 00:23, Sebastiaan Couwenberg wrote:
>>> On 14-09-15 00:07, Jonas Smedegaard wrote:
 Quoting Jonas Smedegaard (2015-09-14 00:00:23)
> A possible difference - if you tested with both those DEs 
> installed - might be some package dependency missing from
> josm or a java library which gets pulled in by larger DEs
> and therefore often unnoticed.  I use Awesome and mostly
> GTK-based applications, avoiding both KDE and GNOME as much
> as I can.  I do generally respect recommends, however -
> attached is the list of unsatisfied reverse recommends (too
> long, as some are satisfied by alternative packages).
>>> 
>>> Awesome doesn't appear to be a good choice of DE. I can
>>> reproduce the problem with josm under awesome. This issue
>>> should probably be reassigned to awesome, this isn't an issue
>>> with josm.
>> 
>> I've tested this issue with the new JOSM 8800 from experimental,
>> which still has this issue.
>> 
>> Interestingly the 'Download from OSM' window does work, new tiles
>> get downloaded when zooming with the scroll wheel and hitting
>> enter downloads the area in question, it just doesn't get
>> rendered.
>> 
>> Jonas, do you think it's worthwhile to reassign this issue to
>> awesome?
> 
> Is it perhaps related to bug#508650?  If so (or similar) I find it
> wrong to file it against each specific window managers - perhaps
> reassing to openjdk instead?

#508650 surely sounds exactly like this issue, so reassigning to
openjdk may be more appropriate indeed.

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGUXTAAoJEGdQ8QrojUrx0+gQALBHnyRTOKNlYH9I88ZWX2we
YRmsp3YEEnkDuE4VUmUW+723k0B83OjpScqhXDoIYHsyonE1rbnLTo8p5dJqkWgD
oKukkA1S9UoVQkRHfDJSk2gOKhLxxTXtYDWMHW8toap+vVmMVPAGsMsfokuI0ufS
KlEdERyvolx+OX+uBv9K0QR1D41neaIFgiMvcYWZIzQyvjKxS/wriOi/aDFoV9B7
kxZUErkzaX4o76o45lSKW6KXzAs8cdNsSCR+1hvjmQV6gTIbOGVbOMj8mcGYjDmT
7y07dc+YnAunFa86V8kPYidZ01lJKP2UTLoaYVMeKscBuMlWH7OzDG5SoBKtnpVR
A0Cb+SnqfQ2H+Ggv6GR1XCrhK8LUQRK8LmzMLRREP2/JvvV4Q6bVS1GluqQgtRE4
aXhWTZokNhV1CWs7W3Mf/+wPons9iPUWQ6Wy7XS5NScxAvNOT6BjjW07TA5phkMi
gSzjC9UNMd+zVfq5Vpplff9dF3/P8NRYMs9EyOD+yb/qzr2a8uQ7B8+R5s04QQzn
enRlITnyHQi0bNUA3aPWcxM3+F1dylyw+lBEAIqs3wDHEzFY5EqNyN+UdlBC9M9n
VzBK/KKOVjVkMPFrFwtmCHd0kNUymGkGoC95iYw4VBDle45RocF3zBJxAFG9gsfC
/mNEWo1E57chXBUjPN5U
=CWw6
-END PGP SIGNATURE-

Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here

[张敬强]

>>The bug is caused by libxmlrpc-lite-perl and libsoap-lite-perl
>>libsoap-lite-perl depends libxmlrpc-lite-perl, while the latter one
>>recommends the previous one. 
>>The step to reproduce:
>>1.Install libsoap-lite-perl, make sure libxmlrpc-lite-perl is marked as
>>auto-installed 2.Select package libsoap-lite-perl, Press 'M'
>>3.Press 'g'
>>4.Select libxmlrpc-lite-perl or libsoap-lite-perl, press '_'
>>5.crash
> 
> I cannot reproduce it as it is, maybe because I have devscripts
> installed, which recommends libsoap-lite-perl.
Today I uninstalled maint-guide and devscripts on my work computer and found 
this.
> 
> But interested to know, do you have ::Purge-Unused enabled in (user or
> root's) ~/.aptitude/config ?  Can you post that file?
On my old laptop, aptitude crash when "_" or "-" pkg postgresql-9.4 with the 
same backtrace.
/root/.aptitude/config content on this machine:

aptitude "";
aptitude::Keep-Unused-Pattern "";
aptitude::Delete-Unused-Pattern "";
aptitude::UI "";
aptitude::UI::Menubar-Autohide "true";
aptitude::UI::Package-Display-Format "%c%a%M%S %p %Z %t %v %V";
aptitude::UI::Package-Status-Format "%d %t";
aptitude::UI::Advance-On-Action "false";
aptitude::AutoClean-After-Update "true";


I can not reproduce both of them on my new laptop, on which two more lines
in /root/.aptitude/config:

APT "";
APT::Install-Recommends "false";

If I remove these two lines, the bug can be reproduced on my new laptop.

Thanks

Bug#801469: cogl: doesn't work with fglrx-driver (shader compiling problem)-

[Carsten Lüdtke]

Package: libcogl20
Version: 1.22.0-1
Severity: important
File: cogl

Dear Maintainer,

After installing fglrx-drivers-15.9-2 (i know, nonfree binary blob, but anyway) 
 i got the following in my syslog after rebooting the system with fglrx-driver 
enabled.

Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: Shader compilation failed:
Oct 10 20:02:09 acidmachine gnome-session[1169]: Vertex shader failed to 
compile with the following errors:
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#271) Explicit 
version number 120 not supported by GL3 forward compatible context
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#273) 1 
compilation errors.  No code generated
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: Shader compilation failed:
Oct 10 20:02:09 acidmachine gnome-session[1169]: Fragment shader failed to 
compile with the following errors:
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#271) Explicit 
version number 120 not supported by GL3 forward compatible context
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#273) 1 
compilation errors.  No code generated
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: Failed to link GLSL program:
Oct 10 20:02:09 acidmachine gnome-session[1169]: Vertex and Fragment shader(s) 
were not successfully compiled before glLinkProgram() was called.  Link failed.
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:796: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:819: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:823: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:827: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:831: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:213: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:213: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-opengl.c:751: GL error (1280): Invalid 
enumeration value
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: Shader compilation failed:
Oct 10 20:02:09 acidmachine gnome-session[1169]: Vertex shader failed to 
compile with the following errors:
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#271) Explicit 
version number 120 not supported by GL3 forward compatible context
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#273) 1 
compilation errors.  No code generated
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: Shader compilation failed:
Oct 10 20:02:09 acidmachine gnome-session[1169]: Fragment shader failed to 
compile with the following errors:
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#271) Explicit 
version number 120 not supported by GL3 forward compatible context
Oct 10 20:02:09 acidmachine gnome-session[1169]: ERROR: error(#273) 1 
compilation errors.  No code generated
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: Failed to link GLSL program:
Oct 10 20:02:09 acidmachine gnome-session[1169]: Vertex and Fragment shader(s) 
were not successfully compiled before glLinkProgram() was called.  Link failed.
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:384: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:399: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:409: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:796: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: driver/gl/cogl-pipeline-progend-glsl.c:819: GL error (1282): 
Invalid operation
Oct 10 20:02:09 acidmachine gnome-session[1169]: (gnome-shell:1370): 
Cogl-WARNING **: 

Bug#801098: jessie-pu: package human-icon-theme/0.28.debian-3.4~deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2015-10-06 at 12:02 +0200, Andreas Beckmann wrote:
> human-icon-theme has a flaw in its build system that can cause a race
> between internal cleanup (running in the background) and removal of the
> build chroot which results in hanging processes blocking the pty.

Please go ahead.

Regards,

Adam

Bug#801100: jessie-pu: package tangerine-icon-theme/0.26.debian-3.1~deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2015-10-06 at 12:05 +0200, Andreas Beckmann wrote:
> tangerine-icon-theme has a flaw in its build system that can cause a race
> between internal cleanup (running in the background) and removal of the
> build chroot which results in hanging processes blocking the pty.

Please go ahead.

Regards,

Adam

Bug#800881: jessie-pu: package nvidia-graphics-drivers/340.93-0+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2015-10-04 at 16:53 +0200, Andreas Beckmann wrote:
> Second PU request for fixing CVE-2015-5950.
> 
> This requires a new upstream release, too, that is two or three releases
> ahead of what is currently in jessie.
> 
> The proposed changes are all already included and tested in sid.
> This includes changes from several uploads to sid (up to 340.76-4) that
> are a new upstream release and several bugfixes and minor features that
> I consider appropriate for jessie.
> The big changes done in sid 340.76-5 onwards are excluded, instead the
> changes needed for jessie were cherry-picked into 340.93-0+deb8u1.

Please go ahead.

> Regarding the version number, 340.93-1 was uploaded to sid (before the
> CVE was made public), so we need to use 340.93-0+deb8u1 this time (or
> would 340.93-0 be ok?). (A shorter version number reduces version string
> inflation when rebuilding nvidia-graphics-modules.)

-0+deb8u1 would be clearer, but I wouldn't object terribly to -0.

Regards,

Adam

Bug#801470: dh-systemd: please sort list of unit files

[Reiner Herrmann]

Source: init-system-helpers
Version: 1.23
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that dh-systemd doesn't sort the list of unit files in prerm/postinst.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds

diff --git a/script/dh_systemd_enable b/script/dh_systemd_enable
index 41323dc..a03acb2 100755
--- a/script/dh_systemd_enable
+++ b/script/dh_systemd_enable
@@ -218,8 +218,8 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 
 	next if @units == 0;
 
-	my $unitargs = join(" ", map { basename($_) } @units);
-	for my $unit (@units) {
+	my $unitargs = join(" ", sort map { basename($_) } @units);
+	for my $unit (sort @units) {
 		my $base = basename($unit);
 		if ($dh{NO_ENABLE}) {
 			autoscript($package, "postinst", "postinst-systemd-dont-enable", "s/#UNITFILE#/$base/");
diff --git a/script/dh_systemd_start b/script/dh_systemd_start
index 297f9c5..9f56f4e 100755
--- a/script/dh_systemd_start
+++ b/script/dh_systemd_start
@@ -192,7 +192,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 	# This wrapper function makes the following logic easier to read.
 	my $sd_autoscript = sub {
 		my ($script, $filename) = @_;
-		my $unitargs = join(" ", map { basename($_) } @units);
+		my $unitargs = join(" ", sort map { basename($_) } @units);
 		autoscript($package, $script, $filename, "s/#UNITFILES#/$unitargs/");
 	};
 


signature.asc
Description: OpenPGP digital signature

Bug#462063: aptitude: please add a "See homepage" action for packages

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


Hello Guenter,

2008-01-22 09:25 G. Milde:

Package: aptitude
Version: 0.4.10-1+b1
Severity: wishlist


Dear Daniel,

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:

- can become a security liability (and aptitude has a wide enough attack
 surcface already), for example:

 - one would have to make sure that the field is not malicious and
 cannot be abused before passing it to another tool, etc

 - running the browser as root is even more problematic

- root doesn't necessarily have permission to run graphical applications
 if it was launched as another user, specially if run remotely

- even if it works when running it remotely, simply triggering the
 action (which can maybe be done by mistake) can have undesired effects
 like launch the browser in a way in which uses the remote X protocol
 and take lots of time on slow connections, and maybe it is not easy to
 cancel (specially if the intense flow data blocks the connection)


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.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#798028: jessie-pu: package pykerberos/1.1.5-0.1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2015-09-04 at 17:41 +0200, Guido Günther wrote:
> I'd like to fix CVE-2015-3206 (a loack (missing KDC authenticity
> verification) for jessie via a point release. The debdiff is
> attached. The bug is fixed in unstable as well as squeeze-lts already.
> 
> As in squeeze-lts the KDC check is disabled by default to not break existing
> installations.

+++ b/debian/NEWS
@@ -0,0 +1,42 @@
[...]
s/ordner/order/

Please go ahead.

Regards,

Adam

Bug#605090: [RFC] Proposal for a new linux-grsec source package

[Yves-Alexis Perez]

control: reassign -1 wnpp
control: retitle -1 ITP: linux-grsec -- Linux kernel with grsecurity patch

On mer., 2015-09-30 at 12:53 +0200, Yves-Alexis Perez wrote:
> I should be able to push something for review pretty soon

So here we are. I've pushed a git tree [1] of a linux-grsec source
package, heavily based on src:linux (it's actually a clone of linux.git
and I've worked in a grsec/sid branch).

I've kept the featureset idea, and on top of that:

- disabled all regular packages from src:linux (linux-libc-dev and
friends)
- disabled all non grsecurity featureset
- renamed the source package to linux-grsec

You can build it the same way you build the src:linux from git. I've
also uploaded packages for sid and Jessie to my repository [2],
including a .dsc [3] so rebuild should be easy.

This is really a work in progress and this mail a request for comment.
Especially missing is:

- various updates to the the debian/control templates (like
Maintainers/Uploaders etc.)
- updates to debian/copyright
- stuff I missed.

I started this with 4.1.7, updated from the v4.1.6-1 tag in the
linux.git. I've then pulled the 4.2.3-1 tag and it seemed to not break
that much, so it might indeed be workable (but we'll see in the long
run).

In any case, everything is in the git folder, and feel free to ask
questions if needed.

I don't intent to upload this to Debian right away, obviously :)

Regards,

[1] https://anonscm.debian.org/cgit/collab-maint/linux-grsec.git
[2] http://perso.corsac.net/~corsac/debian/kernel-grsec/packages/
[3] 
http://perso.corsac.net/~corsac/debian/kernel-grsec/packages/sid/linux-grsec_4.2.3-1.dsc
-- 
Yves-Alexis



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

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

[Felipe Sateler]

On 10 October 2015 at 09:54, Felipe Sateler  wrote:
> On 1 September 2015 at 17:54, Michael Biebl  wrote:
>> Am 01.09.2015 um 19:38 schrieb Felipe Sateler:
>>> On 1 September 2015 at 14:05, Anton Zinoviev  wrote:
 On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote:
>
> Does console-setup actually need to be run before user services are
> started? My guess is that it only needs to run before getty, but it
> should not block other services that want to start.

 It should run before fsck.
>>>
>>> That is definitely not what the init script says[1]:
>>>
>>> # Provides:  console-setup
>>> # Required-Start:$remote_fs
>>
>> Right, the $remote_fs dependency means it's actually started pretty late.
>> I guess what Anton meant was keyboard-setup.
>
> OK, so I added 2 service files, and preserved the early startup.

On IRC it was pointed out that --save is not necessary under systemd:
/usr must always be mounted. However I decided to preserve it because:

1. I am not 100% sure that /usr is guaranteed to be mounted (the
initrd AFAIK does not handle all cases).
2. On reboot to sysv it would be good to preserve the files in /etc.

If /usr is actually guaranteed to be available, then we should drop
--save from both the init script and service file.

-- 

Saludos,
Felipe Sateler

Bug#801428: pulseaudio: on stock workstation with normal left/right speakers, bass is stripped, unless using headphones jack

[Stephen Dowdy]

On Sat, Oct 10, 2015 at 6:42 AM, Felipe Sateler  wrote:

> I don't understand. Do you mean that if you plug into headphone jack
> you do not have this problem? And that the problem only reveals itself
> after plugging the speakers into the line-out jack and selecting Line
> Out / Speakers / Analog Output port[1]?
>
> [1] This being worse because one of these is selected by default?
>

​Felipe,​

​I have not tried headphones themselves, but if i plug the external
speakers into the headphone jack on the workstation, the problem
disappears.  Also, if i select the headphone "port" in software
(pavucontrol) while the external speakers are still plugged into the
line-out jack (either front or back jack of my system, a Dell Precision
Workstation, the problem goes away, as well.

If i move the external speakers from the headphone jack back to the
line-out jack, the automatic jack selection code reverts to the "No Bass"
situation.  (but, again, i can manually "fix" it, by selecting the
headphone port in pavucontrol.  I'd *expect* that to route the sound
through the headphone jack, and i should hear *nothing* at that point, but
that's not the case).

thanks,
--stephen​



-- 
Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
303.497.2869   -  sdo...@ucar.edu-  http://www.ral.ucar.edu/~sdowdy/

Bug#796355: node-readable-stream ITP update

[Ross Gammon]

Hi,

- node-core-util-is is in NEW
(https://ftp-master.debian.org/new/node-core-util-is_1.0.1-1.html)
- node-isarray is in NEW
(https://ftp-master.debian.org/new/node-isarray_0.0.1-1.html)
- node-string-decoder fails to build due to failing tests (and probably
because nodejs 4.x is not supported.

In any case, readable-stream is an extraction of the stream function of
nodejs-core for previous node versions (for stability). And when I
checked today, I see it is in the process of updating support for nodejs
4.x. But his work has not been released yet.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#801458: FTBFS with OCaml 4.02.3

[Stéphane Glondu]

Package: src:misery
Version: 0.2-1
Severity: serious
Control: block 789133 by -1

Dear Maintainer,

misery fails to build on all architectures:

  https://buildd.debian.org/status/package.php?p=misery=sid

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.1.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)

Bug#800769: pbuilder: conffiles not removed

[Mattia Rizzolo]

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.

Suggestion welcome!

-- 
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#800006: jessie-pu: package isc-dhcp/4.3.1-6

[Michael Gilbert]

On Wed, Oct 7, 2015 at 5:46 AM, Bastian Blank wrote:
> On Fri, Sep 25, 2015 at 08:19:53AM +, Martin Zobel-Helas wrote:
>> i wonder if #795227 warrants an upload to jessie-pu (and maybe also to
>> wheezy-pu) to be fixed with the next point release. We run into that
>> issue at work, when we want to effectivly publish static IP addresses in
>> cloud environments.
>
> Can you please take a look at this update request and yell if you have
> problems with fixing this in stable and oldstable.

Where is the debdiff?

Best wishes,
Mike

Bug#801465: ibus-tegaki: diff for NMU version 0.3.1-1.1

[Ross Gammon]

Package: ibus-tegaki
Version: 0.3.1-1
Severity: normal
Tags: patch pending

Dear maintainer,

I've prepared an NMU for ibus-tegaki (versioned as 0.3.1-1.1) and
my sponsor will upload it to DELAYED/2. Please feel free to tell
us if we should delay it longer.

Regards.

Ross
diff -Nru ibus-tegaki-0.3.1/debian/changelog ibus-tegaki-0.3.1/debian/changelog
--- ibus-tegaki-0.3.1/debian/changelog	2010-03-26 17:07:47.0 +0100
+++ ibus-tegaki-0.3.1/debian/changelog	2015-10-10 19:05:20.0 +0200
@@ -1,3 +1,11 @@
+ibus-tegaki (0.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to dh_python2 (Closes: #730248, #786015)
+Thanks to Logan Rosen for the patch
+
+ -- Ross Gammon   Sat, 10 Oct 2015 19:04:57 +0200
+
 ibus-tegaki (0.3.1-1) unstable; urgency=low
 
   * Initial release (Closes: #575530)
diff -Nru ibus-tegaki-0.3.1/debian/control ibus-tegaki-0.3.1/debian/control
--- ibus-tegaki-0.3.1/debian/control	2010-03-26 17:28:01.0 +0100
+++ ibus-tegaki-0.3.1/debian/control	2015-10-10 19:01:11.0 +0200
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: LI Daobing 
-Build-Depends: debhelper (>= 7), python-support
+Build-Depends: debhelper (>= 7), python (>= 2.6.6-3~), dh-python 
 Standards-Version: 3.8.4
 Homepage: http://www.tegaki.org/
 Vcs-Browser: https://code.launchpad.net/~lidaobing/tegaki/ibus-tegaki
diff -Nru ibus-tegaki-0.3.1/debian/rules ibus-tegaki-0.3.1/debian/rules
--- ibus-tegaki-0.3.1/debian/rules	2010-03-26 17:16:52.0 +0100
+++ ibus-tegaki-0.3.1/debian/rules	2015-10-10 19:01:43.0 +0200
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@
+	dh $@ --with python2

Bug#801463: BUG: unable to handle kernel NULL pointer dereference at 00000001 in smp_apic_timer_interrupt

[Ben Hutchings]

On Sat, 2015-10-10 at 19:34 +0100, Richard Kettlewell wrote:
> On 2015-10-10 18:49, Ben Hutchings wrote:
> > This looks rather like a hardware failure, as the instruction pointer
> > is pointing to the middle of an instruction.  Here's the disassembly of
> >  smp_apic_timer_interrupt:
> 
> Thanks for the diagnosis.  Time to spend some money l-/
> 
> For future reference, is there a convenient way to get a disassembly
> corresponding to the kernel I have installed?

Use scripts/extract-vmlinux from the Linux source to decompress the
image in /boot, then 'objdump -d'.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


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

Bug#801475: freeplane: Fails to build with JMapViewer 1.11

[Bas Couwenberg]

Source: freeplane
Version: 1.3.15-2
Severity: important
Tags: upstream

Dear Maintainer,

The jmapviewer package in Debian has been updated to the recent
JMapViewer 1.11 upstream release as required for JOSM 8800
(both available in experimental).

Unfortunately freeplane (1.3.15-2) fails to build with
jmapviewer (1.11+dfsg-1~exp1) as can be seen in the partial build log
below.

Please update the openmaps plugin to support JMapViewer 1.11 or consider
adding skip_openmaps=true to debian/ant.properties.

The severity of this issue will be raised to serious when
jmapviewer (1.11+dfsg-1) is moved from experimental to unstable.
I expect to do that next week.


>From the freeplane (1.3.15-2) build log:

 build:
 [mkdir] Created dir: 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/build
 [javac] 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/ant/build.xml:23: 
warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
 [javac] Compiling 12 source files to 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/build
 [javac] warning: [options] bootstrap class path not set in conjunction 
with -source 1.5
 [javac] 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/src/org/freeplane/plugin/openmaps/mapelements/OpenMapsController.java:64:
 error: incompatible types
 [javac] return map.getPosition(clickedLocation); 
 [javac]   ^
 [javac]   required: Coordinate
 [javac]   found:ICoordinate
 [javac] 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/src/org/freeplane/plugin/openmaps/mapelements/OpenMapsController.java:84:
 error: cannot find symbol
 [javac] int x = (int)OsmMercator.LonToX(location.getLon(), zoom);
 [javac] ^
 [javac]   symbol:   method LonToX(double,int)
 [javac]   location: class OsmMercator
 [javac] 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/src/org/freeplane/plugin/openmaps/mapelements/OpenMapsController.java:85:
 error: cannot find symbol
 [javac] int y = (int)OsmMercator.LatToY(location.getLat(), zoom);
 [javac] ^
 [javac]   symbol:   method LatToY(double,int)
 [javac]   location: class OsmMercator
 [javac] Note: 
/tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/src/org/freeplane/plugin/openmaps/mapelements/OpenMapsViewer.java
 uses or overrides a deprecated API.
 [javac] Note: Recompile with -Xlint:deprecation for details.
 [javac] 3 errors
 [javac] 1 warning
 
 BUILD FAILED
 /tmp/buildd/freeplane-1.3.15/build.xml:4: The following error occurred while 
executing this line:
 /tmp/buildd/freeplane-1.3.15/freeplane_framework/ant/build.xml:139: The 
following error occurred while executing this line:
 /tmp/buildd/freeplane-1.3.15/freeplane_framework/ant/build.xml:55: The 
following error occurred while executing this line:
 /tmp/buildd/freeplane-1.3.15/freeplane_plugin_openmaps/ant/build.xml:23: 
Compile failed; see the compiler error output for details.

 Total time: 18 seconds


My appologies for the inconvenience,

Bas

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

[James Lu]

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

Thanks for the thorough review!

On Mon, 05 Oct 2015 22:47:21 +0200 Christian Kastner  wrote:
> d/control:
>  - The frontend for git at anonscm.d.o has been changed from gitweb to
>git; please update Vcs-Browser URL accordingly
>  - Developer's Reference §6.2.2 says that the synopsis is not a
>sentence, so you don't need to start it with a capital letter
>  - synopsis / long description: GTK is spelled with all-caps, however

Done.

>  - Depends seems to be missing Pango, going by PKG-INFO

Assuming this means gir1.2-pango-1.0, added.

>
> 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.

>  - In the header, the field's name is "Source", not "Upstream-Source"

Done.

>  - 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.

> d/lightdm-gtk-greeter-settings.lintian-overrides:
>  - Instead of adding lintian override for the missing man page of
>lightdm-gtk-greeter-settings-pkexec, symlinking it to the
>manpage of lightdm-gtk-greeter-settings, as some other packages do
>for -pkexec files (eg: src:mate-system-tools), would be more useful

That's a better idea, done.

> d/rules:
>  - You don't need a get-orig-source target for a mere uscan invocation.
>g-o-s is for cases in which downloading via uscan produces something
>that does _not_ match the orig tarball uploaded to the Debian
>archive: for example, when files have been removed from the original
>source (think: DFSG cleaning), or when you can only recreate the
>tarball by checking out from a repository

Removed, thanks.

>
> I'm happy to sponsor your package, but out of curiosity: have you tried
> pinging the lightdm-gtk-greeter maintainers? They could be interested in
> this package, and are probably in a much better position to assist you
> with issues related to this program than I am.

No, I'll do that now.

Best,
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQIcBAEBCAAGBQJWGfl+AAoJEC7D9g3nHAudff0P/1WYusM98IcyaYtc9KN1wMr0
pcisB0uyqKkFjDG2FJ0DVZb+/vLCBw1QSg49GixIHjoVKSk/hBbB1OaAhfmbxVV3
wKpWYz+2axH7pzkshN2hkXPmUsWYfCLXk1rEYqnI4DmT1ez8tH1ioyM4dGlyUCMo
HFzNUOsKfZ+1xDbsuGJkVe2FmB38+uon4kZey30lyLFVeYI7B72+a12WxV4fb3sI
sMkUPUX+6/FiM33LrDlBbroil9/YAS2EjPHSDOfjhmd9SWL3R1yZ9jbziUAMIJcy
IRDWtx0iX2WQ6z4xj1PRDJFlqHqoUxrGGaqGcgFe/DlioixdKoVLeoCvtUZwIZ4h
cH5CB8h772mJvC/FebajgCAw7fZ1gvyqqgYhUJhipvWji7+nHEqB9cPN6r5LY+lx
t+zPJ/8Dyj1Q71rD3Pz7UGqBWu/NdGvqdoGkyYzCJW9o3yUmZguWcwtlenRaf7x+
gY10LfFaevLGe2bShkgkM3HQKbpkFJyLjrrg1O9bhr84C5YZ93rwZBaI2sFmA2h3
bv8E7L8CAsQuKTZCeibz9njwjZkS3IuA3LHdO3+hxLP30imydBdpcRFmx39kfvvo
fAWOk63LGgMHUmyUwfMURnpN/QrtMxTURrLAX619Xp9KIAftiQ5E01+WaPzitxxk
eqJXyZs4nfUnMvuI2wGE
=BhiE
-END PGP SIGNATURE-

Bug#801473: RM: vimperator -- ROM; keeps breaking with Iceweasel security updates

[Francois Marier]

Package: ftp.debian.org
Severity: normal

I would like to request removal of vimperator from unstable since it
constantly gets out of sync with new security releases of Iceweasel and
breaks (e.g. 800508). There is also some uncertainty around the upcoming
add-on signing enforcement.

The alternative is for users to install it directly from upstream:

  https://addons.mozilla.org/en-US/firefox/addon/vimperator/

Updates will be handled automatically by Iceweasel.

Francois

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

[Daniel Stender]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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 build 
log).

13) in python-privacyidea and privacyidea-pam, you have a five executable 
scripts in
/usr/bin without manpages. There is a "should have" in the policy on this issue 
[a],
but missing manpages are considered being a bug. And if missing manpages adds 
to a couple
of other issues like that (like sub standard descriptions) the chance of being 
rejected
by the FTP team rises [b].

   [a] https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1

   [b] 

Bug#801425: dbus: upgrade from dbus 1.10.0-2 to 1.10.0-3 breaks policykit

[Simon McVittie]

On 10/10/15 17:38, Gabriel Filion wrote:
> Laptop was booted and working fine since previous afternoon.
> The upgrade/dist-upgrade that brought in dbus 1.10.0-3 was done on the
> morning of oct 9th around 7:something, then I shutdown around 8:00, and
> booted again around 9:40 and I was seeing the error mentioned in my
> original report.

Hmm. Your logs suggest that you started to upgrade dbus 1.8 to 1.10.0-3
(without going via any intermediate version) on 2015-09-17 at 01:46:40,
and finished that upgrade transaction with dbus successfully installed
at 01:48:13. Presumably you didn't notice anything wrong between then
and the 9th?

On 2015-10-09 at 07:48:00, you started an upgrade of systemd and related
packages, which temporarily dropped dbus down to triggers-pending state
(because systemd installs D-Bus services, which cause a dbus reload to
be triggered). That suggests to me that the systemd upgrade is more
likely to be what triggered the symptoms you described.

At 10:28 it looks as though you reinstalled dbus; presumably none of
what you tried between then and 10:33:18 worked. At around 10:34:46 you
rebooted; at 17:43:47 you downgraded dbus to 1.10.0-2, and at 19:01:34
you rebooted again. I can't help wondering whether it was actually some
other event, not the downgrade to 1.10.0-2, that solved this for you...
perhaps the reboot?

It would be really useful to see any systemd, policykit-1 (polkit)
and/or dbus warnings/errors from 2015-10-09, from your syslog. If you
would prefer not to send that day's syslog to the BTS or spend time
censoring it, you can send it to me by private email (compressed if it's
large), and I'll make sure to only quote the relevant debug details on
the bug.

S

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

[Sascha Steinbiss]

Hi all,

>>> 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/
> 
> Wow, I see (and can’t help but feel a slight WTF about this building setup). 
> Thanks for pointing this out. I guess the cleanest way to proceed here would 
> be to properly package DataTables built from source as a dependency for 
> aegean. Then it wouldn't need to be included with the aegean source anymore, 
> as it is already the case with its other JS dependencies. I’ll put this on my 
> agenda.

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?

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...

Thanks
Sascha

[1] http://anonscm.debian.org/cgit/collab-maint/jquery-datatables.git/


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#801478: rakudo: FTBFS on kfreebsd-*

[Steven Chamberlain]

Package: rakudo
Version: 2015.09-2
Severity: normal
Tags: patch

Hi!

moarvm uses some functions of libkvm on kfreebsd, and therefore
rakudo is linked with this configure line:
libs: -ltommath -latomic_ops -lm -lpthread -lkvm -lrt -ldl

Therefore, rakudo should Build-Depend on it too.  Please find
patch attached.

Thanks a lot!

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

Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- debian/control.orig	2015-10-10 09:32:03.0 +0100
+++ debian/control	2015-10-10 23:52:40.794658887 +0100
@@ -8,6 +8,7 @@
libgmp-dev,
libreadline-dev,
libtommath-dev,
+   libkvm-dev [kfreebsd-any],
libuv1-dev,
moarvm-dev (>= 2015.09-3),
nqp (>= 2015.09.1-2),

Bug#800900: hurd-i386: changeset from r6489 breaks SIGBUS handling

[Samuel Thibault]

Hello,

Gilles Filippini, le Mon 05 Oct 2015 11:58:28 +0200, a écrit :
> I've reduced the testcase to the attached H5detect.c.
> The behavior is different depending on whether we link with "-lpthread":

Indeed, but

> pini@exodar:~/tmp$ /usr/bin/gcc -o H5detect H5detect.c
> pini@exodar:~/tmp$ ./H5detect
> verify_signal_handlers for signal 10 did 5 tries. Found 2 failures and 3

This was already dubious.  I have found the issue, which is due to
longjump-ing from the signal handler called from a raise().  I'll handle
submitting fixes etc.

Thanks for the report,
Samuel

Bug#801482: The name of a programme, from which an error message comes, is missing in the lintian's message

[Bjarni Ingi Gislason]

Package: lintian
Version: 2.5.30+deb8u4
Severity: important

Dear Maintainer,

   * What led up to the situation?

  Seeking an error that came when executing "lintian"

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

  The folowing simple script shows the error:

#!/bin/bash

set -u

echo TMPDIR is $TMPDIR

/usr/bin/man $*

# end of script.

  Put the script, named "man",  in a directory that is searched before 
"/usr/bin".

  Command line (any "deb"-file can be used (that contains a man-page?)):

lintian -C manpages /var/cache/apt/archives/lintian_2.5.30+deb8u4_all.deb

   * What was the outcome of this action?

W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian-info.1.gz  
line 5: TMPDIR: unbound variable
W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian.1.gz  line 
5: TMPDIR: unbound variable

   * What outcome did you expect instead?

  The name of the programme where the error occurred.

  This is important to reduce the time figuring out from where it came.

  The value of the environmental variable TMPDIR is '/tmp'

###

  There are two errors in "lintian", reported separately.

  Here, the missing name of the file with "line 5" (which is the above script).

##

  How will (the cause of) this programming error be documented, so people
(can) learn from it and do not repeat it themselves?

##

There is a saying,

Any fool can learn from his own experience,
The wise man learns from the experience of others.

Too many students show that the first line is not correct.
But the second is very important, and is the basis of
the setting up of an educational program.

Herman Rubin in the Usenet group "misc.education".

##

  "The problems of the real world are primarily those you are
left with when you refuse to apply their effective solutions."

P. xxxviii in:

On the Cruelty of Really Teaching Computing Science

Edsger W. Dykstra (Dijkstra)

SIGCSE Bulletin 1989, 21(1), bls. xxv-xxxix.
Also "www.cs.utexas.edu/users/EWD/"

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

Kernel: Linux 3.16.7-ckt11-u3 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.25-5
ii  bzip2  1.0.6-7+b3
ii  diffstat   1.58-1
ii  file   1:5.22+15-2
ii  gettext0.19.3-2
ii  hardening-includes 2.6
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.39-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.37-1+b1
ii  libdpkg-perl   1.17.25
ii  libemail-valid-perl1.195-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2+b1
ii  libparse-debianchangelog-perl  1.2.0-1.1
ii  libtext-levenshtein-perl   0.11-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.64-1
ii  man-db 2.7.0.2-5
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.20.2-3+deb8u1
ii  t1utils1.38-4

Versions of packages lintian recommends:
pn  libperlio-gzip-perl 
ii  perl5.20.2-3+deb8u1
ii  perl-modules [libautodie-perl]  5.20.2-3+deb8u1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.17.25
ii  libhtml-parser-perl3.71-1+b3
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   
ii  xz-utils   5.1.1alpha+20120614-2+b3

-- no debconf information

-- 
Bjarni I. Gislason

Bug#801478: rakudo: FTBFS on kfreebsd-*

[Steven Chamberlain]

p.s. while here, you may similarly need this to build rakudo on mipsel,
once moarvm is building on it:

   libffi-dev [mipsel],

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

Bug#801483: The environmental variable 'TMPDIR' is made unset by "lintian"

[Bjarni Ingi Gislason]

Package: lintian
Version: 2.5.30+deb8u4
Severity: important

Dear Maintainer,

   * What led up to the situation?

  Seeking an error that came when executing "lintian".

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

  The folowing simple script shows the error:

#!/bin/bash

set -u

echo TMPDIR is $TMPDIR

/usr/bin/man $*

# end of script.

  Put the script, named "man",  in a directory that is searched before 
"/usr/bin".

  Command line (any "deb"-file can be used (that contains a man-page?)):

lintian -C manpages /var/cache/apt/archives/lintian_2.5.30+deb8u4_all.deb

   * What was the outcome of this action?

W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian-info.1.gz  
line 5: TMPDIR: unbound variable
W: lintian: manpage-has-errors-from-man usr/share/man/man1/lintian.1.gz  line 
5: TMPDIR: unbound variable

   * What outcome did you expect instead?

  That the environmental variable "TMPDIR" retains its value.

##

  There are two errors in "lintian", reported separately.  The first
report is Debian #801482.

  Here, the environmental variable TMPDIR has been unset by "lintian". 
It has the value '/tmp'.

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

Kernel: Linux 3.16.7-ckt11-u3 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils   2.25-5
ii  bzip2  1.0.6-7+b3
ii  diffstat   1.58-1
ii  file   1:5.22+15-2
ii  gettext0.19.3-2
ii  hardening-includes 2.6
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b2
ii  libarchive-zip-perl1.39-1
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.37-1+b1
ii  libdpkg-perl   1.17.25
ii  libemail-valid-perl1.195-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2+b1
ii  libparse-debianchangelog-perl  1.2.0-1.1
ii  libtext-levenshtein-perl   0.11-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.64-1
ii  man-db 2.7.0.2-5
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.20.2-3+deb8u1
ii  t1utils1.38-4

Versions of packages lintian recommends:
pn  libperlio-gzip-perl 
ii  perl5.20.2-3+deb8u1
ii  perl-modules [libautodie-perl]  5.20.2-3+deb8u1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.17.25
ii  libhtml-parser-perl3.71-1+b3
ii  libtext-template-perl  1.46-1
pn  libyaml-perl   
ii  xz-utils   5.1.1alpha+20120614-2+b3

-- no debconf information

-- 
Bjarni I. Gislason

Bug#795196:

[Zack Weinberg]

I believe both #795196 and #798755 are the same problem, and I have
encountered it too; I've reported it upstream at
https://pcsxr.codeplex.com/workitem/12230 .  It appears to be that
kernel 4.1.0 changed how it lays out the address space, triggering a
latent bug in the JIT code-generator for x86-64; see the upstream
bugreport for more details.

Bug#773334:

[Zack Weinberg]

This does indeed appear to be fixed upstream, but there's no point
doing an update to 1.9.93 until we have a fix for #795196.

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

[Paul Wise]

On Sat, 2015-10-10 at 23:28 +0100, Sascha Steinbiss wrote:

> can’t help but feel a slight WTF about this building setup

Welcome to the world of JavaScript :)

> I guess the cleanest way to proceed here would be to properly package
> DataTables built from source as a dependency for aegean. Then it
> wouldn't need to be included with the aegean source anymore, as it is
> already the case with its other JS dependencies. I’ll put this on my
> agenda.

Agreed, thanks for considering this.

> OK. Still, I feel that line length probably is a bit weak as
> evidence.

Agreed, in your case it would also flag the source from DataTablesSrc
so clearly something needs to be different. There is some work in
lintian git to try to improve this situation. OTOH probably some false
positives in these checks are acceptable in order to get the situation
with JavaScript in Debian a bit closer to sanity.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

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

[Paul Wise]

On Sat, 2015-10-10 at 23:57 +0100, Sascha Steinbiss wrote:

> 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. 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.

> 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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#742400: iceweasel: No longer found in 41.0.1

[Dan DeVoto]

Package: iceweasel
Followup-For: Bug #742400

Dear Maintainer,

This bug no longer occurs for me in 41.0.1 using Sid.

Thank you.

Regards,

Dan


-- Package-specific info:

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

Name: EPUBReader
Location: ${PROFILE_EXTENSIONS}/{5384767E-00D9-40E9-B72F-9CC39D655D6F}
Status: enabled

Name: Greasemonkey
Location: ${PROFILE_EXTENSIONS}/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}.xpi
Status: enabled

Name: NoScript
Location: ${PROFILE_EXTENSIONS}/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

-- Plugins information

-- Addons package information
ii  iceweasel  41.0.1-1 powerpc  Web browser based on Firefox

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libatomic15.2.1-21
ii  libc6 2.19-22
ii  libcairo2 1.14.2-2
ii  libdbus-1-3   1.10.0-3
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.2.1-3
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgcc1   1:5.2.1-21
ii  libgdk-pixbuf2.0-02.32.1-1
ii  libglib2.0-0  2.46.0-2
ii  libgtk2.0-0   2.24.28-1
ii  libhunspell-1.3-0 1.3.3-3+b1
ii  libnspr4  2:4.10.9-2
ii  libnss3   2:3.20-1
ii  libpango-1.0-01.38.0-3
ii  libsqlite3-0  3.8.11.1-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.2.1-21
ii  libvpx2   1.4.0-4
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.10-4
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.6.0-1
ii  gstreamer1.0-plugins-good  1.6.0-1

Versions of packages iceweasel suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-2
pn  mozplugger 

-- no debconf information

Bug#801477: ceph: FTBFS on armel: common/RWLock.h:29:11: error: 'atomic_t' does not name a type

[Emilio Pozuelo Monfort]

Source: ceph
Version: 0.80.10-1
Severity: serious

Hi,

Thanks for the upload to fix the FTBFS in sid. Unfortunately this still failed
on armel:

Excerpt from the log:

In file included from common/HeartbeatMap.h:26:0,
 from common/HeartbeatMap.cc:21:
common/RWLock.h:29:11: error: 'atomic_t' does not name a type

See the full log at:

https://buildd.debian.org/status/fetch.php?pkg=ceph=armel=0.80.10-1=1444230749

Cheers,
Emilio

Bug#799756: core-network: Privilege escalation via core-gui

[Eriberto Mota]

forwarded 799756 https://github.com/coreemu/core/issues/75
thanks


Hi all,

Opened a formal bug[1] in current upstream site.

[1] https://github.com/coreemu/core/issues/75

Regards,

Eriberto

Bug#600373: [aptitude] auto-depend on debugging symbols

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: retitle -1 aptitude: auto-depend on debugging symbols (install/remove 
-dbg package automatically, along with binaries)


Hello Daniel,

2010-10-16 15:55 Daniel Herzog:

Package: aptitude
Version: 0.6.3-3.1
Severity: wishlist

--- Please enter the report below this line. ---

I would like like to be able to have aptitude automatically install debugging
symbols (where they are available) as if they were dependencies.
This way, no manually installed debugging symbols will be needed, thus they
will be removed whenever the package they belong to is being removed, too.
The result aimed at is to effectively be able to have a Debian system which
mostly behaves as if the binaries weren't stripped to begin with, thereby
facilitating development.
Manual installation of the -dbg packages is not the same thing.
This is going to be especially usefull, once automatical generation of -dbg
packages is implemented.


I don't think that this is a good idea.

Take for example only a few of the tools that can be installed in a
typical desktop (sample taken from large packages, of course):
chromium-dbg [1], ffmpeg-dbg [2], gimp-dbg [3], kate-dbg [4], kwin-dbg
[5], libwebkit2gtk-4.0-37-dbg [6] (by epiphany-browser), and
libreoffice-dbg [7].

With just these, the download size of the .debs probably exceeds that of
the rest of the system, and the unpacked size in the disk of these is
also probably more than the rest of the system.  Also, if multi-arch is
enabled and the package installed, it would install the -dbg as well for
the multi-arch version, doubling the figures.

So if users enable this casually and "just in case", they risk running
out of space in existing system (fair enough -- it's their choice, but
then again I assume that some complaints and bug reports will come back
to use asking to improve the situation in some ways).

But more importantly, if a significant fraction of users enable this,
and those users use unstable/testing (there is a likely correlation),
this could have serious consequences in the load and bandwith of the web
of mirrors.

So I think that yes, it could be useful in some cases to have this, but
there are also some dangers, specially to the Debian infrastructure, and
given the size of the packages it can get out of control pretty quickly,
at which point we couldn't do much to "undo it".

Apart from that, it would need quite a serious effort to think about it,
design and implement this properly and deal with all corner cases; and
given the shortage of time I think that it's better to spend the
available one elsewhere.  And given that 5 years went by already, this
is not going to be implemented soon in anycase.

So I am leaving it open for the time being, but marking it as +wontfix.


[1] Compressed Size: 652 M, Uncompressed Size: 695 M

   The binary itself is many times smaller: Compressed Size: 37.6 M,
   Uncompressed Size: 145 M

[2] Compressed Size: 36.9 M, Uncompressed Size: 43.5 M

[3] Compressed Size: 12.3 M, Uncompressed Size: 55.3 M

[4] Compressed Size: 21.2 M, Uncompressed Size: 22.5 M

[5] Compressed Size: 49.3 M, Uncompressed Size: 52.9 M

[6] Compressed Size: 1,128 M, Uncompressed Size: 4,971 M

[7] Compressed Size: 675 M, Uncompressed Size: 3,167 M


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#801434: transition: armadillo

[Kumar Appaiah]

On Sat, Oct 10, 2015 at 11:30:37PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 10/10/15 05:57, Kumar Appaiah wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hi.
> > 
> > Please consider permitting me to upload the latest armadillo. The
> > soname has become 6, and I have verified that all the rdepends build
> > and work, so a binNMU should be sufficient.
> 
> Ack.

Uploaded. Thanks.

Kumar
-- 
Kumar Appaiah