Bug#538568: apt: apt-get incorrect remaining time

[Torquil Macdonald Sørensen]

Package: apt
Version: 1.0.9.5
Followup-For: Bug #538568

This is very similar to the remaining time I just got, after the
download was finished:

Fetched 379 kB in 213503982334601d 6h 58min 14s (0 B/s)

Actually, the speed (0 B/s) is also wrong, but might just be a
consequency of the large incorrect duration.

Best regards
Torquil Sørensen

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.17-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.17-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Get "";
APT::Get::Purge "true";
APT::Default-Release "sid";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "1";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "2";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-9n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "3";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-9";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "4";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "5";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-9";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt/";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::mirrors "mirrors/";
Dir::State::extended_states "ext

Bug#770944: [PKG-Openstack-devel] Bug#770944: Bug#770944: Bug#770944: Problem still occurs if DEBIAN_FRONTEND=noninteractive

[Gaudenz Steinlin]

Hi Thomas

Thomas Goirand  writes:

> Ooops, then that's the issue, neutron/configure_db should really be set
> to no. I'm retitling the bug, and will fix the issue.

Thanks, that helps a lot for people that don't use debconf to configure
the openstack packages. There is still another issue that the db
migrations on upgrade should be run even if the database was not
configured with debconf. IMO these should either run in any case where a
database connection is configured or there should be a separate debconf
question (defaulting to true) for deciding of migrations should be run
or not. Running migrations on upgrade and configureing the database
throug debconf are two separate things.

Gaudenz


signature.asc
Description: PGP signature

Bug#774831: unblock: pbbuttonsd/0.7.9-5

[Mathieu Malaterre]

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

Please unblock package pbbuttonsd

This upload fixes 711685, I took the liberty to also fix a lintian error 
(dpkg-dev version in B-D).
It also fixes an issue with an incorrect entry in d/control when package was 
adopted, see #774688

unblock pbbuttonsd/0.7.9-5

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

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru pbbuttonsd-0.7.9/debian/changelog pbbuttonsd-0.7.9/debian/changelog
--- pbbuttonsd-0.7.9/debian/changelog	2014-01-22 13:08:34.0 +0100
+++ pbbuttonsd-0.7.9/debian/changelog	2015-01-08 09:01:18.0 +0100
@@ -1,3 +1,16 @@
+pbbuttonsd (0.7.9-5) unstable; urgency=low
+
+  * Really adopt package (#774688).
+
+ -- Mathieu Malaterre   Thu, 08 Jan 2015 09:01:14 +0100
+
+pbbuttonsd (0.7.9-4) unstable; urgency=low
+
+  * Adopt package. Closes: #422162
+  * Fix for linux kernel 3.x. Closes: #711685
+
+ -- Mathieu Malaterre   Tue, 06 Jan 2015 10:12:35 +0100
+
 pbbuttonsd (0.7.9-3) unstable; urgency=low
 
   * QA upload.
diff -Nru pbbuttonsd-0.7.9/debian/control pbbuttonsd-0.7.9/debian/control
--- pbbuttonsd-0.7.9/debian/control	2014-01-22 13:05:01.0 +0100
+++ pbbuttonsd-0.7.9/debian/control	2015-01-08 09:00:35.0 +0100
@@ -1,8 +1,8 @@
 Source: pbbuttonsd
 Section: admin
 Priority: optional
-Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 9), bison, gettext, libasound2-dev, libglib2.0-dev, pkg-config
+Maintainer: Mathieu Malaterre 
+Build-Depends: debhelper (>= 9), bison, gettext, libasound2-dev, libglib2.0-dev, pkg-config, dpkg-dev (>= 1.16.1~)
 Standards-Version: 3.9.5
 
 Package: pbbuttonsd
diff -Nru pbbuttonsd-0.7.9/debian/patches/cpufreq.patch pbbuttonsd-0.7.9/debian/patches/cpufreq.patch
--- pbbuttonsd-0.7.9/debian/patches/cpufreq.patch	1970-01-01 01:00:00.0 +0100
+++ pbbuttonsd-0.7.9/debian/patches/cpufreq.patch	2015-01-05 12:19:16.0 +0100
@@ -0,0 +1,28 @@
+Description: pbbuttonsd is not rewritten for kernel 3.2
+Author: Mathieu Malaterre 
+Origin: https://bugs.gentoo.org/show_bug.cgi?id=429306#c1
+Bug-Debian: http://bugs.debian.org/711685
+Reviewed-by: Mathieu Malaterre 
+
+Index: pbbuttonsd-0.7.9/scripts/scripts.d/cpufreq
+===
+--- pbbuttonsd-0.7.9.orig/scripts/scripts.d/cpufreq	2015-01-05 12:05:46.542701600 +0100
 pbbuttonsd-0.7.9/scripts/scripts.d/cpufreq	2015-01-05 12:05:50.220539855 +0100
+@@ -18,7 +18,7 @@
+ case "$1" in
+   powersave|custom)
+ case "$KVER" in
+-  2.6.*)
++  "2.6."*|"3."*)
+ if [ -d /sys ]; then
+   echo -n "userspace" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+   cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
+@@ -41,7 +41,7 @@
+;;
+   performance)
+  case "$KVER" in
+-  2.6.*)
++  "2.6."*|"3."*)
+ if [ -d /sys ]; then
+   echo -n "userspace" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+   cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
diff -Nru pbbuttonsd-0.7.9/debian/patches/laptopmode.patch pbbuttonsd-0.7.9/debian/patches/laptopmode.patch
--- pbbuttonsd-0.7.9/debian/patches/laptopmode.patch	1970-01-01 01:00:00.0 +0100
+++ pbbuttonsd-0.7.9/debian/patches/laptopmode.patch	2015-01-05 12:19:18.0 +0100
@@ -0,0 +1,37 @@
+Description: pbbuttonsd is not rewritten for kernel 3.2
+Author: Mathieu Malaterre 
+Origin: https://bugs.gentoo.org/show_bug.cgi?id=429306#c2
+Bug-Debian: http://bugs.debian.org/711685
+Reviewed-by: Mathieu Malaterre 
+
+Index: pbbuttonsd-0.7.9/scripts/scripts.d/laptopmode.sh
+===
+--- pbbuttonsd-0.7.9.orig/scripts/scripts.d/laptopmode.sh	2006-10-01 17:34:12.0 +0200
 pbbuttonsd-0.7.9/scripts/scripts.d/laptopmode.sh	2015-01-05 12:12:09.217970623 +0100
+@@ -122,7 +122,7 @@
+ 	 )
+ 	 )
+ case "$KLEVEL" in
+-	"2.4"|"2.6")
++	"2.4"|"2.6"|"3."*)
+ 		true
+ 		;;
+ 	*)
+@@ -222,7 +222,7 @@
+ echo "1"> /proc/sys/vm/laptop_mode
+ echo "30 500 0 0 $AGE $AGE 60 20 0"	> /proc/sys/vm/bdflush
+ ;;
+-			"2.6")
++			"2.6"|"3."*)
+ echo "5"> /proc/sys/vm/laptop_mode
+ echo "$AGE"> /proc/sys/vm/dirty_writeback_centisecs
+ echo "$AGE"> /proc/sys/vm/dirty_expire_centisecs
+@@ -268,7 +268,7 @@
+ 			"2.4")
+ echo "30 500 0 0 $U_AGE $B_AGE 60 20 0"	> /proc/sys/vm/bdflush
+ ;;
+-			"2.6")
++			"2.6"|"3."*)
+ echo "$U_AGE"> /proc/sys/vm/dirty_writeback_centisecs

Bug#679543: Detailed xev analysis

[Erik Thiele]

in the following reports I always leave out lines like these to save
sceen space:
root 0x377, subw 0x0, time 1027512667, (515,302), root:(519,358),
XLookupString gives 0 bytes: 
XmbLookupString gives 0 bytes: 
XFilterEvent returns: False


xev on local X11 session. Pressing Up and Right keys on arrow keypad
(not numeric keypad):

KeyPress event, serial 35, synthetic NO, window 0x461,
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x461,
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 38, synthetic NO, window 0x461,
state 0x0, keycode 114 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x461,
state 0x0, keycode 114 (keysym 0xff53, Right), same_screen YES,


xev on vnc4server 4.1.1+X4.3.0-37.1, xvnc4viewer 4.1.1+X4.3.0, pressing
same keys again:

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,


xev on local X11 session pressing super+Up and super+Right on arrow
keypad (not numeric keypad). i checked that it is really super+Up by
verifying that it automatically maximizes the window. this way you do
not see the key events in xev. To actually see the keys in xev I
reconfigured my gnome keyboard settings to not use super+Up anymore.
this is the result:

KeyPress event, serial 38, synthetic NO, window 0x301,
state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,

KeyPress event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 111 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 114 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 114 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 38, synthetic NO, window 0x301,
state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,


xev on vnc4server 4.1.1+X4.3.0-37.1, xvnc4viewer 4.1.1+X4.3.0, pressing
same keys again (with super):

KeyPress event, serial 33, synthetic NO, window 0x321,
state 0x0, keycode 255 (keysym 0xffeb, Super_L), same_screen YES,

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,

KeyPress event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES,

KeyRelease event, serial 35, synthetic NO, window 0x321,
state 0x0, keycode 255 (keysym 0xffeb, Super_L), same_screen YES,



analysis of results:

keycodes on local X11 and vnc are different.

keysym on local X11 and vnc are the same.

see the difference on the Super_L keypress.  keycode is 255 on vnc!. is
255 a legal keycode? it somehow looks like -1.

running gnome keyboard settings on local x11 i can enter new key
sequences consisting of super+anything. when trying to do so on vnc,
once you press the super key, "Super L" will be displayed as key. this
means super is not seen as a modifier. it is instead seen as a "final"
key just like hitting a normal alphabetic key.

running xmodmap on x11 local:
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift   Shift_L (0x32),  Shift_R (0x3e)
lockCaps_Lock (0x42)
control Control_L (0x25),  Control_R (0x69)
mod1Alt_L (0x40),  Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3  
mod4Super_L (0x85),  Super_R (0x86),  Super_L (0xce),
Hyper_L(0xcf)
mod5ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)


running xmodmap on vnc:
xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift   Shift_L (0x32),  Shift_R (0x3e)
lock  
control Control_L (0x25),  Control_R (0x6d)
mod1Alt_L (0x40),  Alt_R (0x71)
mod2  
mod3  
mod4  
mod5


see that there is no Super stuff on xmodmap vnc.

i am not an expert in vnc/x11/keyboard stuff.

For now i simply disable Super-Up/Down in gnome keyboard settings as
suggested in the bugreport, but still i do not understand, why gnome
thinks the user presses super

Bug#774832: gluegen2: add mips64(el) and mipsn32(el) support

[YunQiang Su]

Package: gluegen2
Version: 2.2.4-2

This patch adds mips64(el) and mipsn32(el) support.
Please consider it.


-- 
YunQiang Su
Index: gluegen2-2.2.4/make/build.xml
===
--- gluegen2-2.2.4.orig/make/build.xml  2015-01-08 14:24:57.996411411 +0800
+++ gluegen2-2.2.4/make/build.xml   2015-01-08 15:27:57.281729646 +0800
@@ -294,6 +294,30 @@

 
 
+
+  
+   
+   
+
+
+
+  
+   
+   
+
+
+
+  
+   
+   
+
+
+
+  
+   
+   
+
+
 
   

@@ -336,7 +360,7 @@

 
 
-
+
   
   
 
Index: gluegen2-2.2.4/make/gluegen-cpptasks-base.xml
===
--- gluegen2-2.2.4.orig/make/gluegen-cpptasks-base.xml  2015-01-08 
14:24:58.004223911 +0800
+++ gluegen2-2.2.4/make/gluegen-cpptasks-base.xml   2015-01-08 
15:56:26.160709142 +0800
@@ -45,6 +45,10 @@
-   isLinuxHppa
-   isLinuxMips
-   isLinuxMipsel
+   -   isLinuxMipsn32
+   -   isLinuxMipsn32el
+   -   isLinuxMips64
+   -   isLinuxMipsn64el
-   isLinuxPpc
-   isLinuxPpc64
-   isLinuxPpc64le
@@ -132,6 +136,10 @@
-   compiler.cfg.linux.hppa
-   compiler.cfg.linux.mips
-   compiler.cfg.linux.mipsel
+   -   compiler.cfg.linux.mipsn32
+   -   compiler.cfg.linux.mipsn32el
+   -   compiler.cfg.linux.mips64
+   -   compiler.cfg.linux.mips64el
-   compiler.cfg.linux.ppc
-   compiler.cfg.linux.ppc64
-   compiler.cfg.linux.ppc64le
@@ -157,6 +165,10 @@
-   linker.cfg.linux.hppa
-   linker.cfg.linux.mips
-   linker.cfg.linux.mipsel
+   -   linker.cfg.linux.mipsn32
+   -   linker.cfg.linux.mipsn32el
+   -   linker.cfg.linux.mips64
+   -   linker.cfg.linux.mips64el
-   linker.cfg.linux.ppc
-   linker.cfg.linux.s390
-   linker.cfg.linux.s390x
@@ -389,6 +401,42 @@
 
   
 
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+
+  
+
 
   
 
@@ -606,6 +654,10 @@
 
 
 
+
+
+
+
 
 
 
@@ -682,6 +734,22 @@
 
   
 
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
+  
+
   
 
   
@@ -718,7 +786,7 @@
 
   
 
-  
+  
 
   
 
@@ -1252,6 +1320,18 @@
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -1481,6 +1561,34 @@
   
 
 
+
+  
+   
+   
+  
+
+
+
+  
+   
+   
+  
+
+
+
+  
+   
+   
+  
+
+
+
+  
+   
+   
+  
+
+
 
   

@@ -1530,7 +1638,7 @@
   
 
 
-
+
 
 
 

Bug#774833: unblock: bley/2.0.0-2

[Evgeni Golov]

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

Hi,

as noticed yesterday in #-release, there are a few packages in the archive,
which still use ahbl.org in their configs. bley is one of these packages,
and while the existance of ahbl.org in the config will not result in data
loss as per design of bley, it will result in delays and should be avoided.

The obvious patch looks like this:
-dnsbls = ix.dnsbl.manitu.net, dnsbl.ahbl.org, dnsbl.sorbs.net
+dnsbls = ix.dnsbl.manitu.net, dnsbl.sorbs.net

The whole proposed debdiff is attached. If it looks sane, I'd like to upload
to unstable asap.

Thanks for all your work
Evgeni

unblock bley/2.0.0-2

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru bley-2.0.0/debian/changelog bley-2.0.0/debian/changelog
--- bley-2.0.0/debian/changelog	2014-10-21 08:34:38.0 +0200
+++ bley-2.0.0/debian/changelog	2015-01-08 09:48:22.0 +0100
@@ -1,3 +1,10 @@
+bley (2.0.0-2) unstable; urgency=medium
+
+  * drop dnsbl.ahbl.org from the config, it was shut down and produces
+false positives.
+
+ -- Evgeni Golov   Thu, 08 Jan 2015 09:47:58 +0100
+
 bley (2.0.0-1) unstable; urgency=medium
 
   * Imported Upstream version 2.0.0
diff -Nru bley-2.0.0/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch bley-2.0.0/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch
--- bley-2.0.0/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch	1970-01-01 01:00:00.0 +0100
+++ bley-2.0.0/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch	2015-01-07 21:58:47.0 +0100
@@ -0,0 +1,25 @@
+From e4eddec83e6e2337d5ab57d2ff1f2979ec412f81 Mon Sep 17 00:00:00 2001
+From: Evgeni Golov 
+Date: Wed, 7 Jan 2015 21:55:14 +0100
+Subject: [PATCH] drop dnsbl.ahbl.org from the config example, it's dead
+
+---
+ bley.conf.example | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bley.conf.example b/bley.conf.example
+index 2a133b9..d0786ad 100644
+--- a/bley.conf.example
 b/bley.conf.example
+@@ -24,7 +24,7 @@ whitelist_recipients_file = ./whitelist_recipients
+ whitelist_clients_file = ./whitelist_clients
+ 
+ # Which DNSBLs and DNSWLs to use?
+-dnsbls = ix.dnsbl.manitu.net, dnsbl.ahbl.org, dnsbl.sorbs.net
++dnsbls = ix.dnsbl.manitu.net, dnsbl.sorbs.net
+ dnswls = list.dnswl.org
+ 
+ # Whitelist after dnswl_threshold hits.
+-- 
+2.1.4
+
diff -Nru bley-2.0.0/debian/patches/series bley-2.0.0/debian/patches/series
--- bley-2.0.0/debian/patches/series	2014-10-21 08:29:50.0 +0200
+++ bley-2.0.0/debian/patches/series	2015-01-07 22:00:27.0 +0100
@@ -1 +1,2 @@
 01-debian_config_and_paths.patch
+drop-dnsbl.ahbl.org-from-the-config.patch

Bug#760911: gcc-arm-none-eabi: Version 4.8.3-9+11 breaks Linux kernel build

[Yann Soubeyrand]

The bug seems to be fixed upstream:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60663.


Is it possible for a fix to be released in time for Jessie? Do you need
help for that?

Cheers


-- 
Yann Soubeyrand
--
Adeneo Embedded
4 chemin du Ruisseau
69130 Écully
France
--
+33 4 72 18 08 40
ysoubeyr...@adeneo-embedded.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774607: gitweb breaks apache upgrade

[Guillem Jover]

Hi!

On Wed, 2015-01-07 at 17:07:14 -0800, Jonathan Nieder wrote:
> Guillem Jover wrote:
> > In this case though, it seems switching to interest-noawait is the
> > correct fix, because gitweb just wants to be notified when the
> > apache2-maintscript-helper program appears to be able to configure
> > itself, but apache does not care and does not need to await the
> > trigger processing from gitweb for itself to be operational.
> 
> Is there a way to tell the packaging system that gitweb is not
> operational until the trigger runs, without implying that apache2 is
> not operational until the trigger runs?

A package in «triggers-pending» does satisfiy dependencies, so even if
apache2 is awaiting triggers processing (i.e. in a «triggers-awaited»
state and as such does not satisfy dependencies) gitweb is considered
for all practical purposes to be «installed».

But I'm not sure I'm seeing the need for what you request. gitweb
states that it can use any of «apache2 | httpd | lynx-cur», so the
interest on the apache2 program is just to get an opportunistic
configuration in case we are using apache2. Is there any other package
that would need to rely on an operational gitweb to work itself? I'm
not sure we usually represent services exposed through a httpd or on
the network in general as readily available through packaging system
states. There are so many things that might need to be set up to
expose the service.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769844: linux: please make linux build reproducibly

[Ian Campbell]

On Wed, 2015-01-07 at 20:49 +0100, Jérémy Bobbio wrote:
> > > +@@ -301,7 +301,9 @@ if [ ! -z ${output_file} ]; then
> > > + if [ -z ${cpio_file} ]; then
> > > + timestamp=
> > > + if test -n "$KBUILD_BUILD_TIMESTAMP"; then
> > > +-timestamp="$(date -d"$KBUILD_BUILD_TIMESTAMP" 
> > > +%s || :)"
> > > ++source_date=$(echo "$KBUILD_BUILD_TIMESTAMP" |
> > > ++sed -e 
> > > 's/.*(\([0-9-]\+\)).*/\1/')
> > > ++timestamp="$(date -d"$source_date" +%s || :)"
> > 
> > This solution may not work.  The patched source can be built with a
> > normal timestamp override, via linux-source.
> 
> The above construction will work given a standard date in
> KBUILD_BUILD_TIMESTAMP. The sed expression only match parenthesises.
> I am open to other suggestions.

How about changing debian/rules.real to set some other variable (e.g.
DEB_BUILD_TIMESTAMP, or whatever) to our special version string and
patching the relevant code (not here, but the scripts/mkcompile_h one)
to prefer $DEB_BUILD_TIMESTAMP but still support $KBUILD_BUILD_TIMESTAMP
as a fallback?

I think we would still need to set KBUILD_BUILD_TIMESTAMP to the
debian/changelog date in rules.real.

Ian.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#773530: imagemagick regression for JPEG 2000 / need openjpeg 2.1.x

[Mathieu Malaterre]

Control: tags -1 patch

On wheezy (see attached file):

$ identify white.j2k
white.j2k JPC 1084x2318 1084x2318+0+0 8-bit DirectClass 335B 1.090u 0:01.080
$ dpkg -L libmagickcore5 | grep jp2
/usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/jp2.so
/usr/lib/x86_64-linux-gnu/ImageMagick-6.7.7/modules-Q16/coders/jp2.la

On jessie:

$ identify white.j2k
identify: no decode delegate for this image format `J2K' @
error/constitute.c/ReadImage/501.
$ dpkg -L libmagickcore-6.q16-2 | grep jp2
-> empty !


It seems jasper used to be reference JPEG 2000 implementation but
disapear at some point, and was replaced with openjpeg 2.1.x but
debian package was not updated.

Please consider applying this patch (jessie?):

libopenjp2-7-dev is missing from the B-D.

After applying patch:

$ identify white.j2k
white.j2k J2K 1084x2318 1084x2318+0+0 8-bit Grayscale Gray 335B 0.000u 0:00.000

Bug#676168: [debhelper-devel] Bug#676168: debhelper: dh_makeshlibs ignores $package.shlibs

[Peter Pentchev]

On Wed, Jan 07, 2015 at 09:55:36PM +0100, Niels Thykier wrote:
[snip]
> Thanks for the report.
> 
> I am considering to apply the attached patch as a solution to this bug.
>  Comments / review / tests welcome.

Just a very, very minor nit...

> +B no longer installs a maintainer provided

"maintainer-provided"

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@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: Digital signature

Bug#774834: rdiff-backup: When backing up to a vfat partition on a remote host, rdiffbackup fails on case-sensitive dirnames

[Kasper Loopstra]

Package: rdiff-backup
Version: 1.2.8-7
Severity: normal


When backing up a folder with subfolders A and a, to a vfat filesystem on a 
remote host that is mounted auto in fstab, rdiffbackup fales with a 'File 
already exists'. The rdiff-backup manual seems to imply that this should work. 
Changing the remote filesystem to ext3 allows the backup to work as ecptected.




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

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

Versions of packages rdiff-backup depends on:
ii  libc6  2.13-38+deb7u6
ii  librsync1  0.9.7-9
ii  python 2.7.3-4+deb7u1
ii  python2.6  2.6.8-1.1
ii  python2.7  2.7.3-6+deb7u2

Versions of packages rdiff-backup recommends:
ii  python-pylibacl  0.5.1-1.1
ii  python-pyxattr   0.5.1-1.1

rdiff-backup suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736588: debian-handbook: gendered language used when referring to subjects

[Johannes Schauer]

Hi,

On Tue, 16 Dec 2014 12:11:05 +0100 Raphael Hertzog  wrote:
> On Sat, 25 Jan 2014, Raphael Hertzog wrote:
> > > Some authors express concern that this is ambiguous as 'they' and 
> > > 'theirs' are
> > > often used as plural pronouns. In this case, a short explanation of the
> > > inclusive language in the foreword can help.
> > > 
> > > If you're accepting patches, I'm happy to sort this out. It'd be largely 
> > > a sed
> > > script followed by spot-checking the diff.
> > 
> > I do accept patches, but those fixes are often better done by rewriting
> > the sentence, either using a synonym to avoid the pronoun or by using
> > passive voice.
> > 
> > http://www.herodios.com/pronouns.html
> 
> FWIW we're starting to work on the jessie version of the handbook, so now is
> the good time to consider submitting such patches...

did the submitter supply a patch?

Is there still time to supply one?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#764704: botch: keep botch out of testing

[Johannes Schauer]

Control: tag -1 patch

test


signature.asc
Description: signature

Bug#774835: (pre-approval) unblock: ikiwiki/3.20141016.1

[Simon McVittie]

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

ikiwiki's blogspam plugin is enabled by default in the "blog" configuration,
to put potential spam comments in a moderation queue. It uses an external
service, blogspam.net, which recently switched off the API that ikiwiki
was using. Upstream author Joey Hess considers this to be an 'important'
bug (#774441) and I agree.

I have prepared a point release to take over Debian maintainership of
ikiwiki from Joey (who has left Debian), and backport the fixed blogspam
plugin from the latest upstream version.

This release also adds a build-dependency and makes one test work around
an ImageMagick bug, both to avoid FTBFS via test failure in non-minimal
environments.

May I upload this to unstable with the intention of getting an

unblock ikiwiki/3.20141016.1

to get it into jessie?

Filtered diff attached, omitting an automatic refresh of the po/ directory
which is part of the release process.

I'll open a separate wheezy-pu bug for a wheezy update, with the new
maintainer and the blogspam update but not the test changes, when I
have tested it.

Thanks,
S
diff --git a/IkiWiki/Plugin/blogspam.pm b/IkiWiki/Plugin/blogspam.pm
index e48ed72..3eb4cf8 100644
--- a/IkiWiki/Plugin/blogspam.pm
+++ b/IkiWiki/Plugin/blogspam.pm
@@ -6,7 +6,8 @@ use strict;
 use IkiWiki 3.00;
 use Encode;
 
-my $defaulturl='http://test.blogspam.net:/';
+my $defaulturl='http://test.blogspam.net:/';
+my $client;
 
 sub import {
 	hook(type => "getsetup", id => "blogspam",  call => \&getsetup);
@@ -33,14 +34,14 @@ sub getsetup () {
 			type => "string",
 			example => "blacklist=1.2.3.4,blacklist=8.7.6.5,max-links=10",
 			description => "options to send to blogspam server",
-			link => "http://blogspam.net/api/testComment.html#options";,
+			link => "http://blogspam.net/api/2.0/testComment.html#options";,
 			safe => 1,
 			rebuild => 0,
 		},
 		blogspam_server => {
 			type => "string",
 			default => $defaulturl,
-			description => "blogspam server XML-RPC url",
+			description => "blogspam server JSON url",
 			safe => 1,
 			rebuild => 0,
 		},
@@ -51,11 +52,23 @@ sub checkconfig () {
 	# if the module is missing when a spam is posted would not
 	# let the admin know about the problem.
 	eval q{
-		use RPC::XML;
-		use RPC::XML::Client;
-		$RPC::XML::ENCODING = 'utf-8';
+		use JSON;
+		use HTTP::Request;
 	};
 	error $@ if $@;
+
+	eval q{use LWPx::ParanoidAgent};
+	if (!$@) {
+		$client=LWPx::ParanoidAgent->new(agent => $config{useragent});
+	}
+	else {
+		eval q{use LWP};
+		if ($@) {
+			error $@;
+			return;
+		}
+		$client=useragent();
+	}
 }
 
 sub checkcontent (@) {
@@ -77,8 +90,6 @@ sub checkcontent (@) {
 	my $url=$defaulturl;
 	$url = $config{blogspam_server} if exists $config{blogspam_server};
 
-	my $client = RPC::XML::Client->new($url);
-
 	my @options = split(",", $config{blogspam_options})
 		if exists $config{blogspam_options};
 
@@ -107,19 +118,28 @@ sub checkcontent (@) {
 		site => encode_utf8($config{url}),
 		version => "ikiwiki ".$IkiWiki::version,
 	);
-	my $res = $client->send_request('testComment', \%req);
+	eval q{use JSON; use HTTP::Request}; # errors handled in checkconfig()
+	my $res = $client->request(
+		HTTP::Request->new(
+			'POST',
+			$url,
+			[ 'Content-Type' => 'application/json' ],
+			to_json(\%req),
+		),
+	);
 
-	if (! ref $res || ! defined $res->value) {
+	if (! ref $res || ! $res->is_success()) {
 		debug("failed to get response from blogspam server ($url)");
 		return undef;
 	}
-	elsif ($res->value =~ /^SPAM:(.*)/) {
+	my $details = from_json($res->content);
+	if ($details->{result} eq 'SPAM') {
 		eval q{use Data::Dumper};
-		debug("blogspam server reports ".$res->value.": ".Dumper(\%req));
-		return gettext("Sorry, but that looks like spam to http://blogspam.net/\";>blogspam: ").$1;
+		debug("blogspam server reports $details->{reason}: ".Dumper(\%req));
+		return gettext("Sorry, but that looks like spam to http://blogspam.net/\";>blogspam: ").$details->{reason};
 	}
-	elsif ($res->value ne 'OK') {
-		debug("blogspam server failure: ".$res->value);
+	elsif ($details->{result} ne 'OK') {
+		debug("blogspam server failure: ".$res->content);
 		return undef;
 	}
 	else {
diff --git a/debian/changelog b/debian/changelog
index 7dc5763..dccbb21 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,25 @@
+ikiwiki (3.20141016.1) unstable; urgency=medium
+
+  * Backport selected commits for Debian 8:
+
+  [ Joey Hess ]
+  * Add missing build-depends on libcgi-formbuilder-perl, needed for
+t/relativity.t if libipc-run-perl is also installed
+(buildds are unaffected by this)
+  * Set Debian package maintainer to Simon McVittie as I'm retiring from
+Debian.
+
+  [ Amitai Schlair ]
+  * blogspam: use the 2.0 JSON API (the 1.0 XML-RPC API has been EOL'd).
+Closes: #774441
+
+  [ Simon McVittie ]
+  * Work around imagemagick Debian bug #771047 by using a non-b

Bug#774836: unblock: libquvi/0.4.1-3

[Ansgar Burchardt]

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

Please unblock package libquvi. The version currently in testing has a
small security issue: it looks for Lua helper scripts below the
current path. This can lead to arbitrary code execution if a program
using libquvi is run in a directory such as /tmp.

unblock libquvi/0.4.1-3

Ansgar
diff -Nru libquvi-0.4.1/debian/changelog libquvi-0.4.1/debian/changelog
--- libquvi-0.4.1/debian/changelog	2014-05-27 10:25:54.0 +0200
+++ libquvi-0.4.1/debian/changelog	2015-01-04 12:53:58.0 +0100
@@ -1,3 +1,11 @@
+libquvi (0.4.1-3) unstable; urgency=medium
+
+  * Do not look for Lua helper scripts below current directory.
+(Closes: #774555)
++ new patch: lua-scripts-below-cwd.patch
+
+ -- Ansgar Burchardt   Sun, 04 Jan 2015 12:52:34 +0100
+
 libquvi (0.4.1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libquvi-0.4.1/debian/patches/lua-scripts-below-cwd.patch libquvi-0.4.1/debian/patches/lua-scripts-below-cwd.patch
--- libquvi-0.4.1/debian/patches/lua-scripts-below-cwd.patch	1970-01-01 01:00:00.0 +0100
+++ libquvi-0.4.1/debian/patches/lua-scripts-below-cwd.patch	2015-01-04 12:45:22.0 +0100
@@ -0,0 +1,23 @@
+From: Ansgar Burchardt 
+Subject: Do not look for Lua helper scripts below current directory
+Date: Sun, 04 Jan 2015 12:39:12 +0100
+
+Bug-Debian: https://bugs.debian.org/774555
+--- a/src/libquvi/lua_wrap.c
 b/src/libquvi/lua_wrap.c
+@@ -367,15 +367,6 @@
+   return (QUVI_OK);
+ }
+ 
+-  /* Current working directory */
+-  buf = getcwd(NULL,0);
+-  if (!buf)
+-return(QUVI_MEM);
+-
+-  asprintf(&path, "%s/%s", buf, spath);
+-  _free(buf);
+-  _scan;
+-
+   /* Home directory */
+   homedir = getenv("HOME");
+   if (homedir)
diff -Nru libquvi-0.4.1/debian/patches/series libquvi-0.4.1/debian/patches/series
--- libquvi-0.4.1/debian/patches/series	2014-05-22 15:44:47.0 +0200
+++ libquvi-0.4.1/debian/patches/series	2015-01-04 12:45:22.0 +0100
@@ -1,2 +1,3 @@
 configure.ac-add-missing-AM-macros.patch
 lua52.patch
+lua-scripts-below-cwd.patch

Bug#774832: gluegen2: add mips64(el) and mipsn32(el) support

[Emmanuel Bourg]

Thank you very much for the patch. Could you also submit it upstream
please [1] ? I think they will be pleased to have an improved portability.

Shouldn't the Java classes be updated as well similarly to the patch
adding mips(el)32 support?

https://sources.debian.net/src/gluegen2/2.2.4-2/debian/patches/add-mips-support.patch/

Emmanuel Bourg

[1] https://jogamp.org/bugzilla/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774837: developers-reference: avoid using gender binary in advice to be gender neutral

[Johannes Schauer]

Package: developers-reference
Version: 3.4.12
Severity: normal
Tags: patch

Hi,

section 6.5.2.6. is titled "be gender neutral" and also explicitly
advises to "use gender-neutral constructions in your writing" but in the
same line says "The world is made of men and women". This is not being
gender neutral as the world is not only made of men and women.

The attached patch tries to solve this problem by turning "The world is
made of men and women." into "The world is not only made of men and
women." and appending the part from the README-contrib which explains
that the singular they should be used as the gender of the subject is
unknown.

Thanks!

cheers, josch
>From 2e45a909750f76caee69e3ff79a8601cfef1ea8b Mon Sep 17 00:00:00 2001
From: josch 
Date: Thu, 8 Jan 2015 10:53:36 +0100
Subject: [PATCH] avoid using gender binary in advice to be gender neutral

---
 best-pkging-practices.dbk | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/best-pkging-practices.dbk b/best-pkging-practices.dbk
index 1651ddb..8728f49 100644
--- a/best-pkging-practices.dbk
+++ b/best-pkging-practices.dbk
@@ -917,8 +917,12 @@ still possible, like Enable this if ... instead of 
 Be gender neutral
 
-The world is made of men and women.  Please use gender-neutral constructions in
-your writing.
+The world is not only made of men and women. Please use gender-neutral
+constructions in your writing. This means avoiding pronouns like he/she when
+referring to a role (like "maintainer") whose gender is unknown. Instead of you
+should use the plural form
+(https://en.wikipedia.org/wiki/Singular_they";>singular they).
+
 
 
 
-- 
2.0.1

Bug#774838: weboob: insecure keyring handling

[Cyril Brulebois]

Package: weboob
Version: 1.0-2
Severity: grave
Tags: security
Justification: security hole

Hi,

the keyring handling when adding a remote repository is… scary. Quoting
weboob/core/repositories.py:
| if not keyring.exists() or self.key_update > keyring.version:
| # This is a remote repository, download file
| try:
| keyring_data = browser.open(posixpath.join(self.url, 
self.KEYRING)).content
| sig_data = browser.open(posixpath.join(self.url, self.KEYRING 
+ '.sig')).content
| except BrowserHTTPError as e:
| raise RepositoryUnavailable(unicode(e))
| if keyring.exists():
| if not keyring.is_valid(keyring_data, sig_data):
| raise InvalidSignature('the keyring itself')
| print('The keyring was updated (and validated by the previous 
one).')
| else:
| print('First time saving the keyring, blindly accepted.')
^^^
!!!
| keyring.save(keyring_data, self.key_update)
| print(keyring)

I would expect the Debian packages to contain some kind of trust chain
to bootstrap the keyring handling, and weboob to abort instead of
“blindly accepting” in other cases.

Mraw,
KiBi.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774841: qtbase-opensource-src: Please provide qtconfig-qt5

[Jonathan Ballet]

Source: qtbase-opensource-src
Severity: normal

Dear Maintainer,

the Qt4 source package provides a qt4-qtconfig package to configure
various aspects of Qt4 applications.

Qt5 in Debian currently doesn't ship with this application, although
it seems to be part of the Qt5 repository. There's no way to configure
Qt5 application, except by hand-editing the appropriate settings in the
appropriate files (I guess?), which is sub-optimal.

Can you please provide the qtconfig application for the Qt5 plateform?

Thanks,

 Jonathan


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774840: Recommends powerpc-utils

[Mathieu Malaterre]

Package: powerpc-utils
Version: 1.1.3-24

It would be nice to document more clearly that nvvideo was replaced by fbset.

Eg, add:

Recommends: fbset

Thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774839: fpc: Compiler /usr/bin/fpc does not support target x86_64-linux & failed

[Patrick Frank]

Package: fpc
Version: 2.6.4+dfsg-4
Severity: normal

Hello Maintainers,

I installed fpc and fpc-source via apt-get and built lazarus-ide from source
via SVN and the build process worked as expected. But when I launched
lazarus
I got the following error:
"Compiler /usr/bin/fpc does not support target x86_64-linux"

The package removal does not remove any files by the way.

The following ppc* related files are on my system:
lrwxrwxrwx 1 root root 24 Jan 6 21:17 /usr/bin/ppcx64 ->
/etc/alternatives/ppcx64
lrwxrwxrwx 1 root root 23 Oct 14 20:47 /usr/bin/ppcx64-2.6.4 ->
../lib/fpc/2.6.4/ppcx64

ls -l /etc/alternatives/fpc:
lrwxrwxrwx 1 root root 18 Jan 6 21:17 /etc/alternatives/fpc ->
/usr/bin/fpc-2.6.4

ls -l /etc/alternatives/ppcx64:
lrwxrwxrwx 1 root root 25 Jan 6 21:17 /etc/alternatives/ppcx64 ->
/usr/lib/fpc/2.6.4/ppcx64

which fpc shows: /usr/bin/fpc

"fpc -i" and "/usr/bin/fpc -i" show the same information as follows:

### begin fpc -i ###

Free Pascal Compiler version 2.6.4

Compiler Date  : 2014/10/14
Compiler CPU Target: x86_64

Supported targets:
  Linux for x86-64
  FreeBSD for x86-64
  Win64 for x64
  Darwin for x86_64
  Solaris for x86-64 (under development)
  OpenBSD for x86-64 (under development)
  NetBSD for x86-64 (under development)

Supported CPU instruction sets:
  ATHLON64

Supported FPU instruction sets:
  SSE64
  SSE3

Supported ABI targets:
  DEFAULT
  SYSV
  AIX
  EABI
  ARMEB
  EABIHF

Supported Optimizations:
  REGVAR
  STACKFRAME
  LOOPUNROLL
  TAILREC
  CSE

Supported Whole Program Optimizations:
  All
  DEVIRTCALLS
  OPTVMTS
  SYMBOLLIVENESS

Supported Microcontroller types:

This program comes under the GNU General Public Licence
For more information read COPYING.v2

Please report bugs in our bug tracker on:
 http://bugs.freepascal.org

More information may be found on our WWW pages (including directions
for mailing lists useful for asking questions or discussing potential
new features, etc.):
 http://www.freepascal.org

### end fpc -i ###


-- System Information:

Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages fpc depends on:
ii  fpc-2.6.4  2.6.4+dfsg-4

Versions of packages fpc recommends:
ii  fp-utils-2.6.4  2.6.4+dfsg-4

fpc suggests no packages.

-- no debconf information

Bug#774842: Add manpage for fnset

[Mathieu Malaterre]

Package: powerpc-utils
Version: 1.1.3-24
Tags: patch

It would be nice to also have a minimal man page for fnset.

$ help2man --no-info -n "Set Mouse Key Modifies" --help-option="-h"
--no-discard-stderr /sbin/fnset > /tmp/fnset.8

Attached.


fnset.8
Description: Binary data

Bug#732440: ghostscript: Error: /typecheck in /findfont

[Jonas Smedegaard]

Hi Chris,

Quoting Chris Liddell (2015-01-08 08:31:45)
> On 07/01/15 21:06, Didier 'OdyX' Raboud wrote:
>> Le mercredi, 7 janvier 2015, 12.17:43 Jonas Smedegaard a écrit :
 This is fixed in upstream's 9.14. I'll see with the release team if 
 we can backport this into Jessie.
>>>
>>> Great.  But what about its licensing?  I guess upstream treat it as 
>>> AGPL, so we may risk disagreeing with them if we choose to ignore 
>>> that - e.g. by treating it as too small to be copyright-protected.
>> 
>> Best is to ask I guess. Let's try to see what the upstream author of 
>> the patch says. Hereby CC'ing him.
>> 
>> Chris: We (Debian) want to include your patch for the Ghostscript bug 
>> 695031 "don't assume we can read a font file", but we are wondering 
>> about its licensing situation.
>> 
>> Debian is shipping ghostscript 9.06, licensed under GPL-3, but you 
>> included this patch in ghostscript 9.14, which is licensed under 
>> AGPL.
>> 
>> We have three options:
>> 
>> a) consider your patch as too small to be copyright-protected. This
>>would allow us to include is in GPL'd ghostscript 9.06. It'd be 
>>nice to have your confirmation on this though.
>> b) get your patch also GPL-licensed, allowing us to include it in 
>>GPL'd ghostscript 9.06. It'd be mandatory to have an explicit 
>>statement from you (as author of the patch) on that.
>> c) None of the above, leaving the bug open for Debian Jessie, thereby
>>leaving our users with a bug in our next stable release. Needless 
>>to say we'd prefer any of the two above solutions.
>> 
>> Cheers, and thanks in advance,
>
> So, for clarity, that will be this commit:
>
> http://git.ghostscript.com/?p=ghostpdl.git;a=blobdiff;f=gs/Resource/Init/gs_fonts.ps;h=8ab6872e
>
> (or, for convenience: http://tinyurl.com/pvr4acp )
>
> We'd have no problem with you patching an older, non-AGPL release with 
> that - we'd regard it as being covered by your "a" case above. It's 
> also a sufficiently obvious solution that any competent Postscript 
> programmer would almost certainly come up with the same solution, 
> which would make copyright enforcement decidedly questionable, too.
>
> So go ahead and use that patch.
>
> In the interests of the usual legal disclaimers, though, this only 
> applies to the particular patch linked above, so any other patches in 
> the future will need to be considered on a case-by-case basis.

Thanks, Chris, for taking the time with this.

Your judgement makes good sense, and is obviously helpful for us.


 - 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#774838: weboob: insecure keyring handling

[Romain Bignon]

Hi,

On 08/Jan - 11:11, Cyril Brulebois wrote:
> I would expect the Debian packages to contain some kind of trust chain
> to bootstrap the keyring handling, and weboob to abort instead of
> “blindly accepting” in other cases.

You're right we should have the official keyring distributed in the Debian
package, but in case the user adds a new repository, we shouldn't reject it but
ask him to accept (like ssh)?

I'm going to send a patch on the package this week.

Romain


signature.asc
Description: Digital signature

Bug#774843: developers-reference: unified section collecting all conventions about version number formats

[Johannes Schauer]

Package: developers-reference
Version: 3.4.12
Severity: wishlist

Hi,

I think the developers reference could use a unified section of all
conventions around Debian versions.

I will split this email into three subsections which I think make sense
for the new section I propose.

I was also told in #debian-mentors that there is disagreement of what
the right way is. These obviously need to be solved first.

Version number sorting
==

Debian policy §5.6.12 also comprehensively explains how version numbers
are compared but I think it would be useful to have some additional
practical advises in the devref like:

 - use `dpkg --compare-versions` if in doubt. This is already mentioned
   in 5.8.5.4. "Preparing packages to address security issues" but this
   is probably not the section name where one would expect such advise.

 - the general meaning of adding a "~" or a "+". Like, a practical
   example that it has to be 3.1~rc1 for release candidates which have
   to sort lower than the final release. And in that context how the "+"
   in +debXuY and +nmuX is used to sort higher than the version before
   but lower than the next. This info is already mentioned about the
   former (+debXuY) in 5.8.5.4. but a new section about versions would
   probably be a more appropriate place for this kind of information.

debian_revision postfixes
=

Debian policy §5.6.12 comprehensively explains the format of a version
number consisting of epoch, upstream_version and debian_revision. But it
does not explain about postfixes like +nmuX, +debXuY or ~bpoX+Y.

A new section could summarize these additional conventions and when they
are used. It would also link to the sections in dev ref where they are
explained in more detail.

This section could also be used to answer the question: what version
postfix to use for a security NMU: +nmuX or +debXuY? Probably the latter
but it's not spelled out anywhere as far as I can see. Or what to do for
a backport NMU?

This section would allow to get a unified overview of the possible
postfixes, what they are used for, why they are useful in terms of
versioning (and associated sorting) and that they are a comprehensive
list of debian_revision postfixes.

Backports do not seem to be part of the dev ref yet but are documented
at http://backports.debian.org/Contribute/

upstream_version postfixes
==

In addition, there exist some common postfixes to the upstream_version
like +dfsg or +ds. Looking through my local Sources list, there also
seem to be lot of usage of ~dfsg, ~ds, .dfsg, .ds, -dfsg, -ds etc. This
section of the developer's reference could explain which one is the
right one to use, probably using the prior explanations about sorting in
the first section as arguments which one the "right" way is.

Are there others?

What do you think?

cheers, josch


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC

[Andreas Beckmann]

Package: xfonts-traditional
Version: 1.7.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'wheezy'.
It installed fine in 'wheezy', then the upgrade to 'sid' fails.

>From the attached log (scroll to the bottom...):


  Preparing to replace perl-modules 5.14.2-21+deb7u2 (using 
.../perl-modules_5.20.1-4_all.deb) ...
  Unpacking replacement perl-modules ...
  Selecting previously unselected package libdb5.3:amd64.
  Unpacking libdb5.3:amd64 (from .../libdb5.3_5.3.28-9_amd64.deb) ...
  Processing triggers for xfonts-traditional ...
  Generating fonts...
  Can't locate File/Find.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
/usr/local/lib/site_perl .) at /usr/bin/update-xfonts-traditional line 9.
  BEGIN failed--compilation aborted at /usr/bin/update-xfonts-traditional line 
9.
  dpkg: error processing xfonts-traditional (--unpack):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   xfonts-traditional

This seems to be a regression by dpkg having added a versioned Breaks
due to trigger cycles ...

At the point where the error occurs we have these packages
installed/unpacked:
 dpkg: wheezy
 perl-base: wheezy (no File/Find.pm, yet)
 perl-modules: jessie (no File/Find.pm any longer)
 xfonts-traditional: wheezy

i.e. the triggers from xfonts-traditional/wheezy are run by dpkg/wheezy.
What triggered them btw?

Since File/Find.pm moved to perl-base, maybe the Depends: perl can be
changed to Depends: perl-base (>= 5.20.1-3~)
and perl-modules could add a Breaks: xfonts-traditional (<= 1.7.1)


cheers,

Andreas


xfonts-traditional_1.7.1.log.gz
Description: application/gzip

Bug#774845: yaboot 1.3.17 is out

[Mathieu Malaterre]

Package: yaboot

It would be nice to package newer yaboot release. It fixes:

Key features are:

Better netboot
IPv6 support for netboot
Bug fixes for iscsi and pSeries
Removal of old dead code
Now builds with -Werror


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774841: qtbase-opensource-src: Please provide qtconfig-qt5

[Pino Toscano]

reassign 774841 src:qttools-opensource-src
severity 774841 wishlist
close 774841
thanks

Hi,

On 2015-01-08 11:25, Jonathan Ballet wrote:

Qt5 in Debian currently doesn't ship with this application, although
it seems to be part of the Qt5 repository. There's no way to 
configure
Qt5 application, except by hand-editing the appropriate settings in 
the

appropriate files (I guess?), which is sub-optimal.

Can you please provide the qtconfig application for the Qt5 
plateform?


qtconfig there is not built by default, and I'm not sure whether it
would even compile OOTB.  It has been even removed upstream [1][2][3],
so it makes no sense to provide a dead tool in Debian.

[1] 
http://lists.qt-project.org/pipermail/development/2014-December/019544.html

[2] https://codereview.qt-project.org/#/c/102626/
[3] 
https://qt.gitorious.org/qt/qttools/commit/9eb989dee3b7add23d83f2d0c40b2843f6a832a7


Thanks for your report,
--
Pino Toscano


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774846: developers-reference: please document how to upload to stable/stable-proposed-updates

[Johannes Schauer]

Package: developers-reference
Version: 3.4.12
Severity: wishlist

Hi,

as part of my NM process I was asked how to upload to
stable/stable-proposed-updates. I noticed that the dev ref does not say
explicitly how to do such uploads and whether or not there is a
difference between functionality bug fixing stable uploads or security
related uploads.

Specifically it would be appreciated to explicitly spell out the
involved commands to do an upload for these scenarios. Like:

dput security-master package.deb

Secondly, it might be worthwhile to note how the distribution value in
d/changelog influences the destination of the upload. If my reading of
the docs is correct, then the following should be able to do an upload
to stable, given the right distribution in d/changelog:

dput ftp-master package.deb

But I think it ought to be easier to find that information, for example
by putting it in the dev ref.

Thirdly and lastly, I was not able to find out what to do if my upload
did not succeed and was only told by my AM that there are .commands
files which I can upload. Specifically, it would be nice if the dev ref
somewhere was linking to
ftp://ftp-master.debian.org/pub/UploadQueue/README somewhere or explain
its content.

Thanks!

cheers, josch


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774847: python2.7-minimal: fails to upgrade from 'wheezy': python or pycompile not found in public_modules.rtinstall hook.

[Andreas Beckmann]

Package: python2.7-minimal
Version: 2.7.9-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + texlive-music

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'wheezy'.
It installed fine in 'wheezy', then the upgrade to 'sid' fails.

This was observed during an distupgrade with the texlive-music package
installed, I haven't seen it elsewhere.

>From the attached log (scroll to the bottom...):

[...]
  Setting up texlive-base (2014.20141024-2) ...
  Installing new version of config file /etc/libpaper.d/texlive-base ...
  Installing new version of config file /etc/texmf/fmt.d/10texlive-base.cnf ...
  /usr/bin/tl-paper: setting paper size for dvips to a4.
  /usr/bin/tl-paper: setting paper size for dvipdfmx to a4.
  /usr/bin/tl-paper: setting paper size for xdvi to a4.
  /usr/bin/tl-paper: setting paper size for pdftex to a4.
  Running mktexlsr. This may take some time... done.
  Building format(s) --all.
This may take some time... done.
  Removing obsolete conffile /etc/texmf/dvipdfm/config/config ...
  Removing obsolete conffile /etc/texmf/xdvi/xdvi.cfg ...
  Processing triggers for tex-common (5.03) ...
  Running updmap-sys. This may take some time... done.
  Running mktexlsr /var/lib/texmf ... done.
  Setting up texlive-latex-base (2014.20141024-2) ...
  Installing new version of config file 
/etc/texmf/fmt.d/10texlive-latex-base.cnf ...
  Running mktexlsr. This may take some time... done.
  Building format(s) --all --cnffile /etc/texmf/fmt.d/10texlive-latex-base.cnf.
This may take some time... done.
  Processing triggers for libc-bin (2.19-13) ...
  Processing triggers for tex-common (5.03) ...
  Running updmap-sys. This may take some time... done.
  Running mktexlsr /var/lib/texmf ... done.
  Selecting previously unselected package python.
  (Reading database ... 14658 files and directories currently installed.)
  Preparing to unpack .../python_2.7.8-2_amd64.deb ...
  Unpacking python (2.7.8-2) ...
  Selecting previously unselected package python2.7.
  Preparing to unpack .../python2.7_2.7.9-1_amd64.deb ...
  Unpacking python2.7 (2.7.9-1) ...
  Selecting previously unselected package python2.7-minimal.
  Preparing to unpack .../python2.7-minimal_2.7.9-1_amd64.deb ...
  Unpacking python2.7-minimal (2.7.9-1) ...
  Selecting previously unselected package libpython2.7-minimal:amd64.
  Preparing to unpack .../libpython2.7-minimal_2.7.9-1_amd64.deb ...
  Unpacking libpython2.7-minimal:amd64 (2.7.9-1) ...
  Setting up libpython2.7-minimal:amd64 (2.7.9-1) ...
  Setting up python2.7-minimal (2.7.9-1) ...
  python or pycompile not found in public_modules.rtinstall hook.
  dpkg: error processing package python2.7-minimal (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   python2.7-minimal


cheers,

Andreas


texlive-music_2014.20141024-1.log.gz
Description: application/gzip

Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then

[sebastian]

Package: git
Version: 1:1.7.10.4-1+wheezy1
Severity: normal

I keep running into "git rebase -i" errors on Debian wheezy. In most cases,
"git rebase --abort" and trying again works around the problem. This is what it
looks like:

$ git rebase -i REMOTE/BRANCH
[detached HEAD XXX] MESSAGE1
 3 files changed, 14 insertions(+), 2 deletions(-)
fatal: Unable to create '[..]/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
Could not apply YYY... MESSAGE2

$ git --version
git version 1.7.10.4


What I've been doing this time, is turning one "pick" into an "f".



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

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

Versions of packages git depends on:
ii  git-man  1:1.7.10.4-1+wheezy1
ii  libc62.13-38+deb7u6
ii  libcurl3-gnutls  7.26.0-1+wheezy11
ii  liberror-perl0.17-1
ii  libexpat12.1.0-1+deb7u1
ii  perl-modules 5.14.2-21+deb7u2
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages git recommends:
ii  less 444-4
ii  openssh-client [ssh-client]  1:6.0p1-4+deb7u2
ii  patch2.6.1-3
ii  rsync3.0.9-4

Versions of packages git suggests:
ii  gettext-base  0.18.1.1-9
pn  git-arch  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774849: libuv: sometimes FTBFS with test 'tcp_close_while_connecting' failing

[James Cowgill]

Source: libuv
Version: 0.10.28-5
Severity: important
Tags: upstream
Forwarded: https://github.com/libuv/libuv/issues/125

Hi,

libuv sometimes FTBFS for me with testsuite errors depending on which
machine I build it on. It seems to fail to build on machines within a
network which blocks most outgoing ports (causing a connection refused
error almost immediately).

I originally found this while doing a mips64el archive rebuild, because
the mips64el buildds run in such a network.

Thanks,
James

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

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774847: python2.7-minimal: fails to upgrade from 'wheezy': python or pycompile not found in public_modules.rtinstall hook.

[Sebastian Ramacher]

On 2015-01-08 12:10:25, Andreas Beckmann wrote:
> Package: python2.7-minimal
> Version: 2.7.9-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + texlive-music
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'wheezy'.
> It installed fine in 'wheezy', then the upgrade to 'sid' fails.
> 
> This was observed during an distupgrade with the texlive-music package
> installed, I haven't seen it elsewhere.
> 
> >From the attached log (scroll to the bottom...):
> 
> [...]
>   Setting up texlive-base (2014.20141024-2) ...
>   Installing new version of config file /etc/libpaper.d/texlive-base ...
>   Installing new version of config file /etc/texmf/fmt.d/10texlive-base.cnf 
> ...
>   /usr/bin/tl-paper: setting paper size for dvips to a4.
>   /usr/bin/tl-paper: setting paper size for dvipdfmx to a4.
>   /usr/bin/tl-paper: setting paper size for xdvi to a4.
>   /usr/bin/tl-paper: setting paper size for pdftex to a4.
>   Running mktexlsr. This may take some time... done.
>   Building format(s) --all.
>   This may take some time... done.
>   Removing obsolete conffile /etc/texmf/dvipdfm/config/config ...
>   Removing obsolete conffile /etc/texmf/xdvi/xdvi.cfg ...
>   Processing triggers for tex-common (5.03) ...
>   Running updmap-sys. This may take some time... done.
>   Running mktexlsr /var/lib/texmf ... done.
>   Setting up texlive-latex-base (2014.20141024-2) ...
>   Installing new version of config file 
> /etc/texmf/fmt.d/10texlive-latex-base.cnf ...
>   Running mktexlsr. This may take some time... done.
>   Building format(s) --all --cnffile 
> /etc/texmf/fmt.d/10texlive-latex-base.cnf.
>   This may take some time... done.
>   Processing triggers for libc-bin (2.19-13) ...
>   Processing triggers for tex-common (5.03) ...
>   Running updmap-sys. This may take some time... done.
>   Running mktexlsr /var/lib/texmf ... done.
>   Selecting previously unselected package python.
>   (Reading database ... 14658 files and directories currently installed.)
>   Preparing to unpack .../python_2.7.8-2_amd64.deb ...
>   Unpacking python (2.7.8-2) ...
>   Selecting previously unselected package python2.7.
>   Preparing to unpack .../python2.7_2.7.9-1_amd64.deb ...
>   Unpacking python2.7 (2.7.9-1) ...
>   Selecting previously unselected package python2.7-minimal.
>   Preparing to unpack .../python2.7-minimal_2.7.9-1_amd64.deb ...
>   Unpacking python2.7-minimal (2.7.9-1) ...
>   Selecting previously unselected package libpython2.7-minimal:amd64.
>   Preparing to unpack .../libpython2.7-minimal_2.7.9-1_amd64.deb ...
>   Unpacking libpython2.7-minimal:amd64 (2.7.9-1) ...
>   Setting up libpython2.7-minimal:amd64 (2.7.9-1) ...
>   Setting up python2.7-minimal (2.7.9-1) ...
>   python or pycompile not found in public_modules.rtinstall hook.
>   dpkg: error processing package python2.7-minimal (--configure):
>subprocess installed post-installation script returned error exit status 1
>   Errors were encountered while processing:
>python2.7-minimal

So is this the same as 769106 that you've also reported?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#768456: Version 3 including ansgar's and pitti's feedback

[Martin Pitt]

Control: tag -1 pending

Hey Didier,

Didier Roche [2014-11-12 11:50 +0100]:
> done, deb-systemd-invoke now returns latest unit error code it may found
> (and print which one(s) in STDERR).
> 
> I added as well, as ansgar's suggested that we don't start static units (not
> being able to find as well any good reason we would want to autostart them).
> 
> Please find attached v4 of the debdiff with those 2 changes.

Thanks! Committed with two minor grammar fixes to the changelog. As we
are in freeze now I won't upload this to Debian unstable for now
though, but of course we can upload it to experimental (if you think
that's worth doing), and/or to Ubuntu.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774464: nginx: change to index.html lost on upgrade

[Arnout Engelen]

severity 774464 normal
thanks

Well, until the commit referred to above the default document root *was*
/usr/share/nginx/html :

diff --git a/debian/conf/sites-available/default
b/debian/conf/sites-available/default
index f6413f0..406c754 100644
--- a/debian/conf/sites-available/default
+++ b/debian/conf/sites-available/default
@@ -21,7 +21,7 @@ server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

- root /usr/share/nginx/html;
+ root /var/www/html;
  index index.html index.htm;

  # Make site accessible from http://localhost/

I entirely agree this change is valid and users shouldn't meddle with
/usr/share,
but given that this used to be the default configuration I'd say it'd be
good to be
more forgiving.


Kind regards,

Arnout

On Thu, Jan 8, 2015 at 2:05 AM, Michael Lustfield 
wrote:
>
> I can understand the concern about loss.
>
>
>
> However, /usr/share/ is for packages. This is where packages put things.
This
>
> is essentially a web app installed and maintained by the nginx-common
package.
>
> It is *not* a configuration file. There is no need to handle it as if it
were a
>
> configuration file.
>
>
>
> Let's look at every other package that sticks an app in /usr/share. I'm
only
>
> going to pick one - phpmyadmin.
>
>
>
> If you modify /usr/share/phpmyadmin/libraries/export/mediawiki.php and
then
>
> upgrade, your changes are gone. That's expected behavior.
>
>
>
> Users/admins should *NOT* be screwing with /usr/share. That's why this
file is
>
> there... it's managed by the package and NOT the user. That's also part of
>
> the reason why we don't stick the symlink for the default site back into
>
> sites-enabled once it's removed.
>
>
>
> I strongly disagree with the severity change. However, I'll leave it as I
feel
>
> we should just close this as wontfix. Someone incorrectly using /usr/share
>
> isn't our issue to fix.
>
>
>
> On Thu, 8 Jan 2015 01:03:15 +0100
>
> Arnout Engelen  wrote:
>
>
>
> > severity 774464 grave
>
> > thanks
>
> >
>
> > Updating the severity to 'grave' because of data loss: looks like the
>
> > user-modified index.html really is lost.
>
> >
>
> > On Sat, Jan 3, 2015 at 3:35 AM, Arnout Engelen  wrote:
>
> >
>
> > > Package: nginx
>
> > > Version: 1.6.2-5
>
> > > Severity: normal
>
> > >
>
> > > Dear Maintainer,
>
> > >
>
> > > After just upgrading nginx from the version in raspbian wheezy to the
one
>
> > > in
>
> > > jessie it appears my removed my (modified)
/usr/share/nginx/www/index.html
>
> > > and
>
> > > replaced it by a (default/original) /usr/share/nginx/html/index.html .
>
> > >
>
> > > Could perhaps be related to
>
> > >
http://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=74531a5070ac96a5e3c75bec2a19871c65e07446
>
> > > ?
>
> > >
>
> > >
>
> > > -- System Information:
>
> > > Distributor ID: Raspbian
>
> > > Description:Raspbian GNU/Linux testing (jessie)
>
> > > Release:testing
>
> > > Codename:   jessie
>
> > > Architecture: armv6l
>
> > >
>
> > > Kernel: Linux 3.12.35+ (PREEMPT)
>
> > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>
> > > Shell: /bin/sh linked to /bin/dash
>
> > > Init: systemd (via /run/systemd/system)
>
> > >
>
> > > Versions of packages nginx depends on:
>
> > > ii  nginx-full  1.6.2-5
>
> > >
>
> > > nginx recommends no packages.
>
> > >
>
> > > nginx suggests no packages.
>
> > >
>
> > > -- no debconf information
>
> > >
>
>
>
>
>
> --
>
> Michael Lustfield
>

Bug#774850: wheezy-pu: package bley/0.1.5-2+deb7u1

[Evgeni Golov]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

Hi,

as noticed yesterday in #-release, there are a few packages in the archive,
which still use ahbl.org in their configs. bley is one of these packages,
and while the existance of ahbl.org in the config will not result in data
loss as per design of bley, it will result in delays and should be avoided.

The obvious patch looks like this:
-dnsbls = ix.dnsbl.manitu.net, dnsbl.ahbl.org, dnsbl.sorbs.net
+dnsbls = ix.dnsbl.manitu.net, dnsbl.sorbs.net

The whole debdiff against the version in stable is attached. If it's OK,
i'd like to upload to stable to meet the next point release.

Greets and thanks
Evgeni

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 5bfb6e1..7c12b4f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+bley (0.1.5-2+deb7u1) stable; urgency=medium
+
+  * drop dnsbl.ahbl.org from the config, it was shut down and produces
+false positives.
+
+ -- Evgeni Golov   Thu, 08 Jan 2015 12:18:35 +0100
+
 bley (0.1.5-2) unstable; urgency=low
 
   * cherry-pick patch from upstream to disable njabl.org
diff --git a/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch b/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch
new file mode 100644
index 000..4f5e281
--- /dev/null
+++ b/debian/patches/drop-dnsbl.ahbl.org-from-the-config.patch
@@ -0,0 +1,25 @@
+From 94394d74bae1256b6db24b70a7b8a99d156c8dac Mon Sep 17 00:00:00 2001
+From: Evgeni Golov 
+Date: Wed, 7 Jan 2015 21:55:14 +0100
+Subject: [PATCH] drop dnsbl.ahbl.org from the config example, it's dead
+
+---
+ bley.conf | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bley.conf b/bley.conf
+index c20e7bd..6dd1ec2 100644
+--- a/bley.conf
 b/bley.conf
+@@ -18,7 +18,7 @@ dbpass = bley
+ dbname = bley
+ 
+ # Which DNSBLs and DNSWLs to use?
+-dnsbls = ix.dnsbl.manitu.net, dnsbl.ahbl.org, dnsbl.sorbs.net
++dnsbls = ix.dnsbl.manitu.net, dnsbl.sorbs.net
+ dnswls = list.dnswl.org
+ 
+ # Whitelist after dnswl_threshold hits.
+-- 
+2.1.4
+
diff --git a/debian/patches/series b/debian/patches/series
index 5ec0bf8..b86e3e1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 01-debian_config_and_paths.patch
 02-drop-dnsbl.njabl.org-it-s-not-maintained-anymore.patch
+drop-dnsbl.ahbl.org-from-the-config.patch

Bug#774851: torrus-common: cronjob produces output after package removal

[Andreas Beckmann]

Package: torrus-common
Version: 2.08-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob produces
output after the package has been removed.

>From the attached log (scroll to the bottom...):

3m11.8s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpt5NUrv', 
'/etc/cron.daily/torrus-common']
3m11.8s DUMP: 
  find: `/srv/torrus/collector_rrd': No such file or directory
3m11.8s DEBUG: Command ok: ['chroot', '/tmp/piupartss/tmpt5NUrv', 
'/etc/cron.daily/torrus-common']
3m11.8s ERROR: FAIL: Cron file /etc/cron.daily/torrus-common has output with 
package removed


cheers,

Andreas


torrus-common_2.08-1.log.gz
Description: application/gzip

Bug#752596: Bug #752596: android-tools: ftbfs on mips64el

[James Cowgill]

Version: 4.2.2+git20130529-5.1

On Wed, 22 Oct 2014 11:50:17 -0400 Hans-Christoph Steiner  wrote:
> fixed 752596 4.2.2+git20130529-4
> 
> I just uploaded -4 of this package which includes an alternate, cleaner fix
> for this issue on ppc64el.  I think it should also fix this issue.  The patch
> is attached, and also in android-tools git.

Hi,

I can confirm that android-tools now builds on mips64el, so I'm going to
close the bug.

Thanks,
James


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774852: manpages: please make build reproducible

[Jérémy Bobbio]

Source: manpages
Version: 3.74-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps randomness

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that manpages could not be built reproducibly.

The attached patches removes timestamps from gzip headers and ensure a
stable order in the copyright file. Once applied, manpages can be built
reproducibly with our current experimental framework.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From f1250e9b93ae8141fd455522d37b43886b5363e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobibo?= 
Date: Thu, 8 Jan 2015 12:14:06 +0100
Subject: [PATCH 1/2] Stop recording timestamps in gzip headers

These timestamps prevent the package from building reproducibly.
---
 debian/inst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/inst b/debian/inst
index 166f1e5..1d2f60e 100644
--- a/debian/inst
+++ b/debian/inst
@@ -7,7 +7,7 @@ install -d -m 755 licenses
 install -d -m 755 debian/manpages/usr/share/man/man{1,2,3,4,5,6,7,8}
 install -p -m 644 man2/intro.2 debian/manpages/usr/share/man/man2
 install -p -m 644 man3/intro.3 debian/manpages/usr/share/man/man3
-gzip -9 debian/manpages/usr/share/man/man{2,3}/*
+gzip -9n debian/manpages/usr/share/man/man{2,3}/*
 
 # Installing manpages files
 for i in man[145678]; do
@@ -52,7 +52,7 @@ for i in man[145678]; do
 		esac
 		echo -n " "
 	done
-	gzip -9 debian/manpages/usr/share/man/$i/*.?
+	gzip -9n debian/manpages/usr/share/man/$i/*.?
 	echo
 done
 
@@ -104,7 +104,7 @@ for i in man[23]; do
 		esac
 		echo -n " "
 	done
-	gzip -9 debian/manpages-dev/usr/share/man/$i/*.?
+	gzip -9n debian/manpages-dev/usr/share/man/$i/*.?
 	echo
 done
 
-- 
2.1.4

From c22bee93063848c6c1208697024d644599b60c1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobibo?= 
Date: Thu, 8 Jan 2015 12:17:20 +0100
Subject: [PATCH 2/2] Ensure licenses are in a stable order in copyright file

Perl hashes are sorted differently at each run. To make the package
build reproducibly, we sort the licenses in order to get a stable
order.
---
 debian/make-copyright | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/make-copyright b/debian/make-copyright
index 656f88e..c152aaa 100644
--- a/debian/make-copyright
+++ b/debian/make-copyright
@@ -149,7 +149,7 @@ foreach my $file (@files) {
 	$license = $exception{$file};
 	} elsif (!exists $licensetext{$file}) {
 	$license = '';
-	foreach $l (keys %licenses) {
+	foreach $l (sort keys %licenses) {
 		if ($blurb =~ /$licenses{$l}/) {
 		$license = $l;
 		last;
@@ -177,7 +177,7 @@ if (-r $config{template}) {
 }
 print OUT "\n";
 
-foreach $l (keys %licenses) {
+foreach $l (sort keys %licenses) {
 if (exists $manpages{$l}) {
 	print OUT "=" x $config{width} . "\n\n";
 	print OUT "The following license covers these manpages:\n\n";
@@ -194,7 +194,7 @@ foreach $l (keys %licenses) {
 }
 }
 
-foreach $l (keys %licensetext) {
+foreach $l (sort keys %licensetext) {
 print OUT "=" x $config{width} . "\n\n";
 print OUT "The following license covers these manpages:\n\n";
 $l =~ /(.*)\.(\d)/;
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#774853: udd/new-maintainers.cgi: please be gender neutral

[Johannes Schauer]

Package: qa.debian.org
Severity: normal
Tags: patch
User: qa.debian@packages.debian.org
Usertags: udd

Hi,

I just randomly stumbled over
https://udd.debian.org/cgi-bin/new-maintainers.cgi and noticed that it
says "his name and email" instead of being gender neutral.

Attached patch fixes this problem.

Thanks!

cheers, josch
>From ddf3962207eaf61f24b73a1138c124c2142042b9 Mon Sep 17 00:00:00 2001
From: josch 
Date: Thu, 8 Jan 2015 12:48:49 +0100
Subject: [PATCH] web/cgi-bin/new-maintainers.cgi: be gender neutral

---
 web/cgi-bin/new-maintainers.cgi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/web/cgi-bin/new-maintainers.cgi b/web/cgi-bin/new-maintainers.cgi
index 31b54a1..41f3961 100755
--- a/web/cgi-bin/new-maintainers.cgi
+++ b/web/cgi-bin/new-maintainers.cgi
@@ -61,7 +61,7 @@ sth.execute ; rows = sth.fetch_all
 
 unless csvflag
   puts "New Debian maintainers"
-  puts "This page lists the first upload of each maintainer (identified by his name and email), together with its sponsor."
+  puts "This page lists the first upload of each maintainer (identified by their name and email), together with its sponsor."
 
 
   puts ""
-- 
2.0.1

Bug#765338: wrap-and-sort: please support wrapping and sorting debian/*.links

[Fabian Greffrath]

Am Montag, den 20.10.2014, 17:06 +0200 schrieb Fabian Greffrath: 
> Please find attached a patch to implement this.

Any chance?

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774821: ERROR Details

[Licínio Cardoso]

root@raspberrypi:~# apt-get install mysql-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libdbd-mysql-perl libmysqlclient16 mysql-client-5.5 mysql-server-5.5
mysql-server-core-5.5
Suggested packages:
  libterm-readkey-perl tinyca
The following NEW packages will be installed:
  libdbd-mysql-perl libmysqlclient16 mysql-client-5.5 mysql-server
mysql-server-5.5 mysql-server-core-5.5
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,250 kB of archives.
After this operation, 87.9 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main
libmysqlclient16 armhf 5.1.62-1 [1,828 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ wheezy/main
libdbd-mysql-perl armhf 4.021-1 [123 kB]
Get:3 http://mirrordirector.raspbian.org/raspbian/ wheezy/main
mysql-client-5.5 armhf 5.5.40-0+wheezy1 [1,436 kB]
Get:4 http://mirrordirector.raspbian.org/raspbian/ wheezy/main
mysql-server-core-5.5 armhf 5.5.40-0+wheezy1 [3,061 kB]
Get:5 http://mirrordirector.raspbian.org/raspbian/ wheezy/main
mysql-server-5.5 armhf 5.5.40-0+wheezy1 [1,730 kB]
Get:6 http://mirrordirector.raspbian.org/raspbian/ wheezy/main mysql-server
all 5.5.40-0+wheezy1 [73.9 kB]
Fetched 8,250 kB in 7s (1,148 kB/s)
Preconfiguring packages ...
Selecting previously unselected package libmysqlclient16.
(Reading database ... 93714 files and directories currently installed.)
Unpacking libmysqlclient16 (from .../libmysqlclient16_5.1.62-1_armhf.deb)
...
Selecting previously unselected package libdbd-mysql-perl.
Unpacking libdbd-mysql-perl (from .../libdbd-mysql-perl_4.021-1_armhf.deb)
...
Selecting previously unselected package mysql-client-5.5.
Unpacking mysql-client-5.5 (from
.../mysql-client-5.5_5.5.40-0+wheezy1_armhf.deb) ...
Selecting previously unselected package mysql-server-core-5.5.
Unpacking mysql-server-core-5.5 (from
.../mysql-server-core-5.5_5.5.40-0+wheezy1_armhf.deb) ...
Selecting previously unselected package mysql-server-5.5.
Unpacking mysql-server-5.5 (from
.../mysql-server-5.5_5.5.40-0+wheezy1_armhf.deb) ...
Selecting previously unselected package mysql-server.
Unpacking mysql-server (from .../mysql-server_5.5.40-0+wheezy1_all.deb) ...
Processing triggers for man-db ...
Setting up libmysqlclient16 (5.1.62-1) ...
Setting up libdbd-mysql-perl (4.021-1) ...
Setting up mysql-client-5.5 (5.5.40-0+wheezy1) ...
Setting up mysql-server-core-5.5 (5.5.40-0+wheezy1) ...
Setting up mysql-server-5.5 (5.5.40-0+wheezy1) ...
[ ok ] Stopping MySQL database server: mysqld.
150108 11:57:59 [Warning] Using unique option prefix key_buffer instead of
key_buffer_size is deprecated and will be removed in a future release.
Please use the full name instead.
150108 11:57:59 [Warning] Using unique option prefix myisam-recover instead
of myisam-recover-options is deprecated and will be removed in a future
release. Please use the full name instead.
150108 11:57:59 [Note] Plugin 'FEDERATED' is disabled.
150108 11:57:59 InnoDB: The InnoDB memory heap is disabled
150108 11:57:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150108 11:57:59 InnoDB: Compressed tables use zlib 1.2.7
150108 11:57:59 InnoDB: Using Linux native AIO
150108 11:58:00 InnoDB: Initializing buffer pool, size = 128.0M
150108 11:58:00 InnoDB: Completed initialization of buffer pool
150108 11:58:00 InnoDB: highest supported file format is Barracuda.
150108 11:58:00  InnoDB: Waiting for the background threads to start
150108 11:58:01 InnoDB: 5.5.40 started; log sequence number 1595675
150108 11:58:01  InnoDB: Starting shutdown...
150108 11:58:02  InnoDB: Shutdown completed; log sequence number 1595675
[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . .
failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: error processing mysql-server-5.5 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
 mysql-server depends on mysql-server-5.5; however:
  Package mysql-server-5.5 is not configured yet.

dpkg: error processing mysql-server (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mysql-server-5.5
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@raspberrypi:~#


#EOF

Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC

[Ian Jackson]

Control: found -1 xfonts-traditional/1.6
Control: notfound -1 xfonts-traditional/1.7.1

Andreas Beckmann writes ("Bug#774844: xfonts-traditional: fails to upgrade from 
'wheezy': Can't locate File/Find.pm in @INC"):
> Package: xfonts-traditional
> Version: 1.7.1

Thanks for the report.  This is definitely a bad bug which must be
fixed for jessie.

> At the point where the error occurs we have these packages
> installed/unpacked:
>  dpkg: wheezy
>  perl-base: wheezy (no File/Find.pm, yet)
>  perl-modules: jessie (no File/Find.pm any longer)
>  xfonts-traditional: wheezy
> 
> i.e. the triggers from xfonts-traditional/wheezy are run by dpkg/wheezy.
> What triggered them btw?

I think that the target package for this bug is perhaps wrong.  (That
is, that the change will have to be made to a different package.)
Certainly the version is wrong: at the point where this bug occurs,
xfonts-traditional_1.7.1_all.deb has not even been touched.

> Since File/Find.pm moved to perl-base, [...]

I think that the current dependency structure would permit:
 * Start with wheezy, without xfonts-traditional
 * Unpack perl-modules from jessie but do not configure it
 * Install xfonts-traditional

But xfonts-traditional depends on `perl', not `perl-modules' or
`perl-base'.  And `perl' is not deconfigured merely because one of its
dependencies goes from configured to unpacked.  So at this point
xfonts-traditional's postinst will run but the actual purpose of its
dependency on `perl' is not fully satisfied.  The postinst will fail.

This arises from the fact that in dpkg the `dependencies are
configured when postinst is run' requirement is not transitive: it
doesn't apply to the dependencies of one's dependencies.

AFAICT xfonts-traditional's use of dependencies conforms to the
recommendation in the perl policy:
  https://www.debian.org/doc/packaging-manuals/perl-policy/ch-programs.html

If my scenario above is correct, this problem is not confined to
packages involving triggers, nor necessarily to xfonts-traditional.
Rather the problem is that the policy implies that most packages will
depend on just `perl', but `perl' can be `installed' despite some of
the functionality it is supposed to provide (File/Find.pm in this
case) being missing.

I think the right fix therefore has to be in the Perl packages.

Here is a suggestion: have perl-modules (jessie) declare a Breaks on
perl (wheezy).

That declares it necessary to deconfigure perl (wheezy) to install
perl-modules (jessie).  perl (wheezy) cannot be re-configured until
perl-modules (which it depends on) is re-configured, but perl-modules
(jessie) depends on perl-base (jessie) so apt and dpkg will have to
unpack and configure perl-base (jessie) first.

Thus it will not be possible for `perl' to be `installed' while
File/Find.pm is absent.  And xfonts-traditional's (or some other
client package)'s postinst won't run until `perl' is `installed'
again.

> Since File/Find.pm moved to perl-base, maybe the Depends: perl can be
> changed to Depends: perl-base (>= 5.20.1-3~)
> and perl-modules could add a Breaks: xfonts-traditional (<= 1.7.1)

But, firstly, that's not an entirely accurate description of
xfonts-traditional dependencies.  The package does in fact work with
older perls.  And, this approach suggests that perl-modules should
grow a Breaks for every package in the archive which uses File::Find,
which doesn't seem like a very good approach.

Regards,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774854: fex: fails to install: subprocess installed post-installation script returned error exit status 1

[Andreas Beckmann]

Package: fex
Version: 20140917-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package fex.
  (Reading database ... 9850 files and directories currently installed.)
  Preparing to unpack .../fex_20140917-2_all.deb ...
  Unpacking fex (20140917-2) ...
  Setting up fex (20140917-2) ...
  Adding group `fex' (GID 152) ...
  Done.
  Adding system user `fex' (UID 151) ...
  Adding new user `fex' (UID 151) with group `fex' ...
  Not creating home directory `/usr/share/fex'.
  Installing initial copy of htdocs into /var/lib/fex/htdocs ...
  Initializing /etc/fex/fex.ph with correcting hostname (using: 
myhost.domain.example.com)
  Adding system alias for fex to root
  dpkg: error processing package fex (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   fex

Running 'postinst configure' with set -x enabled ends with:

[...]
+ grep -q ^$admin_pw /etc/fex/fex.ph
+ perl -e require "/etc/fex/fex.ph";print $notify_newrelease;
+ NOTIFY=
+ [  !=  ]
+ [ -f /etc/aliases -o -L /etc/aliases ]
+ grep -qi ^\s*fex\s*: /etc/aliases
+ [ -f /etc/exim/exim.conf -o -f /var/lib/exim4/config.autogenerated ]
+ [ ! -f /var/lib/exim4/config.autogenerated ]
+ egrep ^\s*(MAIN_TRUSTED_USERS|trusted_users)\s*=.*fex 
/var/lib/exim4/config.autogenerated
+ ISTRUSTED=
dpkg: error processing package fex (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 fex


cheers,

Andreas


fex_20140917-2.log.gz
Description: application/gzip

Bug#774855: unblock: eztrace-contrib/1.0.5-2

[Samuel Thibault]

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

Please unblock package eztrace-contrib

With the move of /usr/bin/libtool from libtool to libtool-bin,
eztrace-contrib now FTBFS, see Bug#774609 for the details.  Basically,
This is because its build system explicitly calls libtool.  In version
1.0.5-2 of eztrace-contrib, I have made it simply use the libtool script
generated by ./configure.

unblock eztrace-contrib/1.0.5-2

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
 bon comment on fait de l'investigation pour savoir qui est le vilain ?
 on débranche le routeur et on regarde qui s'affole
 -+- #ens-mim administre -+-
diff -Nru eztrace-contrib-1.0.5/debian/changelog 
eztrace-contrib-1.0.5/debian/changelog
--- eztrace-contrib-1.0.5/debian/changelog  2014-09-10 17:25:14.0 
+0200
+++ eztrace-contrib-1.0.5/debian/changelog  2015-01-08 13:15:06.0 
+0100
@@ -1,3 +1,9 @@
+eztrace-contrib (1.0.5-2) unstable; urgency=medium
+
+  * patches/libtool-path: Fix path to libtool (Closes: Bug#774609).
+
+ -- Samuel Thibault   Thu, 08 Jan 2015 13:15:05 +0100
+
 eztrace-contrib (1.0.5-1) unstable; urgency=medium
 
   * eztrace contrib build upload.
diff -Nru eztrace-contrib-1.0.5/debian/patches/libtool-path 
eztrace-contrib-1.0.5/debian/patches/libtool-path
--- eztrace-contrib-1.0.5/debian/patches/libtool-path   1970-01-01 
01:00:00.0 +0100
+++ eztrace-contrib-1.0.5/debian/patches/libtool-path   2015-01-08 
13:10:49.0 +0100
@@ -0,0 +1,11 @@
+--- eztrace/src/modules/cuda/cudalt.py
 eztrace/src/modules/cuda/cudalt.py
+@@ -57,7 +57,7 @@ if rv != 0:
+ sys.exit(1)
+ 
+ # get libtool version
+-fd = os.popen("libtool --version")
++fd = os.popen("../../../libtool --version")
+ libtool_version = fd.readline()
+ # this loop supresses the broken pipe errors
+ # you get by not reading all the data
diff -Nru eztrace-contrib-1.0.5/debian/patches/series 
eztrace-contrib-1.0.5/debian/patches/series
--- eztrace-contrib-1.0.5/debian/patches/series 2014-09-10 17:22:49.0 
+0200
+++ eztrace-contrib-1.0.5/debian/patches/series 2015-01-08 13:10:27.0 
+0100
@@ -3,3 +3,4 @@
 plugins-abi-version
 static-bfd
 check
+libtool-path

Bug#774856: buildd: undeclared dependency on sudo

[Adam Borowski]

Package: buildd
Version: 0.65.0-1
Severity: normal

Hi!
Installed buildd spams the following cron mail:
,
Error reading configuration: SUDO binary 'sudo' does not exist or is not
executable at /usr/share/perl5/Buildd/Conf.pm line 77.
`
Installing 'sudo' manually makes it happy.


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.18.1-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages buildd depends on:
ii  adduser3.113+nmu3
ii  cron   3.0pl1-127
ii  dupload2.7.0
ii  exim4  4.84-6
ii  exim4-daemon-light [mail-transport-agent]  4.84-6
ii  libsbuild-perl 0.65.0-1
ii  libyaml-tiny-perl  1.64-1
ii  perl   5.20.1-4
ii  sbuild 0.65.0-1

buildd recommends no packages.

Versions of packages buildd suggests:
pn  wanna-build  

-- Configuration Files:
/etc/buildd/buildd.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774857: buildd: crontab entry fails when removed-but-not-purged

[Adam Borowski]

Package: buildd
Version: 2.7.0.2-5
Severity: normal

Hi!
If the 'buildd' package is temporarily removed with conf files present,
cron spams 8 times per hour:
/bin/sh: 1: /usr/bin/buildd-watcher: not found

The relevant entries are:
10,25,40,55  **   *   *buildd   /usr/bin/buildd-uploader
5,20,35,50   **   *   *buildd   /usr/bin/buildd-watcher

Please change them to: test -x /usr/bin/foo && foo



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.18.1-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774858: fastjet: CDF and ATLAS plugins are GPL'ed - new version (3.1.1) available

[Christian Holm Christensen]

Source: fastjet
Severity: important

Dear Maintainer,

In the README.Debian file it says the ATLAS and CDF plugins are disabled
because of license issues.  However, the classes ALTASConePlugin,
CDFJetCluPlugin, and CDFMidPointPlugin all carry the copyright notice

//--
7 // This file is part of FastJet.
8 //
9 //  FastJet is free software; you can redistribute it and/or modify
   10 //  it under the terms of the GNU General Public License as published by
   11 //  the Free Software Foundation; either version 2 of the License, or
   12 //  (at your option) any later version.
   13 //
   14 //  The algorithms that underlie FastJet have required considerable
   15 //  development. They are described in the original FastJet paper,
   16 //  hep-ph/0512210 and in the manual, arXiv:.6097. If you use
   17 //  FastJet as part of work towards a scientific publication, please
   18 //  quote the version you use and include a citation to the manual and
   19 //  optionally also to hep-ph/0512210.
   20 //
   21 //  FastJet is distributed in the hope that it will be useful,
   22 //  but WITHOUT ANY WARRANTY; without even the implied warranty of
   23 //  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   24 //  GNU General Public License for more details.
   25 //
   26 //  You should have received a copy of the GNU General Public License
   27 //  along with FastJet. If not, see .
   28 //--

which surely is DFSG-free.  The (optional) clause to cite hep-ph/0512210
is not a _must_, and should not effect the DFSG status.

If - for some reason - you need to take out these, make sure you also
patch up fastjet-config to _not_ report these plugins

  $ fastjet-config --list-plugins
  Available plugins:
SISCone
CDFCones
PxCone
D0RunIICone
NestedDefs
TrackJet
ATLASCone
CMSIterativeCone
EECambridge
Jade

Finally, there's a new version (3.1.1) of fastjet available from the
web-page.

Will you also package the contrib plug-ins?  As far as I can judge by
looking over all the COPYING files at

  https://fastjet.hepforge.org/trac/browser/contrib#contribs 

it seems that all contrib plug-ins are licensend under the GPLv2.

Thank you for packaging this.

Yours,

Christian



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: x86_64

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

-- 
 ___  |  Christian Holm Christensen
  |_| |  -
| |  Address: Niels Bohr Institute
 _|   Blegdamsvej 17 
_|DK-2100 Copenhagen O
 |   Web: http://cern.ch/cholm
 | | Cell:+45 24 61 85 91


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#771428: Workaround

[Thomas Clavier]

Hello

I have same bug :
$ LANG=en_US sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
 libpam-systemd
The following packages will be upgraded:
 libpam-systemd
1 upgraded, 0 newly installed, 0 to remove and 591 not upgraded.
11 not fully installed or removed.
Need to get 0 B/120 kB of archives.
After this operation, 4096 B disk space will be freed.
Do you want to continue? [Y/n]
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory

locale: Cannot set LC_ALL to default locale: No such file or directory
dpkg: dependency problems prevent processing triggers for dbus:
dbus depends on libdbus-1-3 (>= 1.7.6); however:
 Package libdbus-1-3:amd64 is not configured yet.

dpkg: error processing package dbus (--configure):
dependency problems - leaving triggers unprocessed
dpkg: dependency problems prevent processing triggers for dbus:
dbus depends on libdbus-1-3 (>= 1.7.6); however:
 Package libdbus-1-3:amd64 is not configured yet.

...

dpkg: error processing package dbus (--configure):
dependency problems - leaving triggers unprocessed
dpkg: too many errors, stopping
Errors were encountered while processing:
dbus
...
dbus
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)

and

$ LANG=en_US sudo apt-get install libdbus-1-3
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
libdbus-1-3 : Breaks: libdbus-1-3:i386 (!= 1.8.14-1) but 1.8.12-3 is 
to be installed
libdbus-1-3:i386 : Breaks: libdbus-1-3 (!= 1.8.12-3) but 1.8.14-1 is 
to be installed
libpam-systemd : Depends: systemd (= 215-7) but 215-8 is to be 
installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or 
specify a solution).


Have you an idea to find a workaround ?

Bug#771428: Workaround

[Thomas Clavier]

Hello

I just found the workaround :

cd /var/cache/apt/archives
sudo dpkg -i libdbus-1-3_1.8.12-3_amd64.deb
sudo apt-get -f install

Bug#774810: pulseaudio-utils: pactl can no longer change volume: Assertion 'vol_spec' failed at utils/pactl.c:1462

[Felipe Sateler]

Control: tags -1 fixed-upstream

On Wed, Jan 7, 2015 at 9:33 PM, Jameson Graef Rollins
 wrote:
> On Wed, Jan 07 2015, Felipe Sateler  wrote:
>> The problem is not with the -- argument. That works fine. The problem
>> is that the option parsing for the volumes became buggy somewhere
>> after the 5.0 release. I have posted a patch to the upstream list,
>> hopefully it will be accepted before the final 6.0 release.
>>
>> In the meantime, just drop the -- specifier. For most cases (including
>> setting negative values) it should be unnecessaryi.

The patch has been applied upstream. I'm a bit short on time, so
getting this fix in debian will have to wait until the next PA release
(either rc or final).

>>
>> Thanks for your report!
>
> Ok, great, thanks so much, Felipe.  And thank you very much for the very
> speedy response, and for maintaining such a valuable package

:)

-- 

Saludos,
Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#764546: ntp: Init script returns 5 if the daemon is not executable

[Felipe Sateler]

On 8 Jan 2015 01:11, "Peter Eisentraut"  wrote:
>
> On 10/8/14 6:50 PM, Felipe Sateler wrote:
> > Package: ntp
> > Version: 1:4.2.6.p5+dfsg-3.1
> > Severity: normal
> >
> > The ntp init script has this check:
> >
> > test -x $DAEMON || exit 5
>
> That is the LSB exit code, but I guess that practice never really caught
on.
>

Sysvinit never checked scripts return status, so no wonder it didn't catch
on.

> > Which means that if ntp has been removed but not purged, the ntp script
> > will fail at boot. With systemd actually checking the return code of
> > init scripts, this results in the system being flagged as not correctly
> > booted.
>
> Hmm, is that something that should be fixed in jessie then?

Not sure if a fix would be acceptable now.  You'd have to ask the release
team, but given the late date and the minority of the bug I wouldn't have
high hopes.

>
> (Other packages might be affected.)

Probably,  but ntp happened to be installed on my computer ;)

Bug#774859: Various packaging-fixes for v0.9.2

[Rowan Thorpe]

Package: coquelicot
Version: 0.9.2-4
Tags: patch

Patch-series is attached. I bundled them as they seemed too small to open as 6
separate bugs. Bugs #773820 and #741421 are also patched by this, perhaps you
want to merge those bug-reports with this one? I don't know BTS well enough to
do that myself.

-- 
Rowan Thorpe
PGP fingerprint:
 BB0A 0787 C0EE BDD8 7F97  3D30 49F2 13A5 265D CCBD

"There is a great difference between worry and concern. A worried person sees
a problem, and a concerned person solves a problem."
 - Harold Stephens
>From 545ea2a6799231ec566f1713142737f7f18e9191 Mon Sep 17 00:00:00 2001
From: Rowan Thorpe 
Date: Thu, 8 Jan 2015 14:46:11 +0200
Subject: [PATCH 0/6] v0.9.2 bugfixes

While updating packaging for upstream v0.9.3 this patch-series proved useful
for v0.9.2 too (except for the backported fix which I added specifically). The
patches apply against 0.9.2-4 and build cleanly (in a Jessie pbuilder env).
The only patch which might also be useful upstream is the one for the obsolete
rubygem dep naming (patch 0004).

Rowan Thorpe (6):
  Improve package pgp-signing
  Fix collab-maint URL (Closes: #773820) &extra typo
  Fixes for clean package rebuilding
  Fix obsolete rubygem dep naming for activesupport
  Backport 0.9.3 auth-err-spill fix(Closes: #741421)
  Bump Standards-Version & associated change

 .gitignore |  5 ++
 debian/README.source   |  4 +-
 debian/control |  6 +-
 debian/coquelicot.gemspec  |  6 +-
 debian/patches/0008-Fix-rubygem-dep-naming.patch   | 44 
 .../0009-Backport-auth-error-spill-fix.patch   | 35 ++
 debian/patches/series  |  2 +
 debian/rules   |  4 ++
 debian/upstream/signing-key.asc| 79 ++
 debian/watch   |  2 +-
 10 files changed, 178 insertions(+), 9 deletions(-)
 create mode 100644 debian/patches/0008-Fix-rubygem-dep-naming.patch
 create mode 100644 debian/patches/0009-Backport-auth-error-spill-fix.patch
 create mode 100644 debian/upstream/signing-key.asc

-- 
2.1.3

>From 64d0d8e2e214dc075d1d177e8c2cce102e409206 Mon Sep 17 00:00:00 2001
From: Rowan Thorpe 
Date: Fri, 2 Jan 2015 15:27:37 +0200
Subject: [PATCH 1/6] Improve package pgp-signing

* Add pgpsigurlmangle option to debian/watch to silence warning
* Add debian/upstream/signing-key.asc to let uscan verify tarball sigs
---
 debian/upstream/signing-key.asc | 79 +
 debian/watch|  2 +-
 2 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 debian/upstream/signing-key.asc

diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
new file mode 100644
index 000..7139433
--- /dev/null
+++ b/debian/upstream/signing-key.asc
@@ -0,0 +1,79 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+Version: GnuPG v2
+
+mQINBExxDcQBEADYxKT5PSch5hvhw2Ej+LdnY6fx1WwhIl36LvSQwCD75K1ULUbgsQPNAMUO
+Zbk3dTBclPKCqRSRaZf8yqWqJsXDwbNHO5HiytgtNx5Qpa3UyJ8Kg5MTY+j7iKhWAwJtFEXO
+iIJHMZwzvy+FNtlxstKNeXV01AJpsJljoNhST6mkOAF+l8GvItfkLSap8/Bp9nOqqi+j9ibz
+kLCHN4MbbPeSWjpsTCo2kzqd/501Oaq7Gw4dpiccOPQGeYD9PDpPZz/7PpsryddHfut2Upsn
+bKsZU1ap9tpc2gkOhfIUxdDc6bZw1P8Ci7p9ziPW5CZBoSJId9Ns74jcwtpXffE+tpO15zch
+sRgaPTkZyPrR632gBx77E7ZcdgnOzPo7EZZXC14viDbRjOwtCiIjfqdK9TZRq8DLtm7869uQ
+pmCJjWANbRpqOsFvXs4TaNvzImSeSnfNzOSTLvpOeC+6zXAspyuNS9Pp72e3bA8DUMUj07Tq
+5RvYR1aQC8WWUncSGhLbv+1KqDM5v7klUJWEQPo0WO+karsnpByoNWv9ao5MSLHZyzBD+RzU
+pTR6A6xSctX0Y9PPT8++Q5BmGGLQjUTs//WLE+1569CKJDB8ATbGyhlZgOPDAV1OnrhAbbWS
+sR6C7uYcWUmWcW6/jEH/MGEFGJ4auFMHSQJsJFLeVABkG0l3YwARAQABtBpMdW5hciA8bHVu
+YXJAYW5hcmdlZWsubmV0PohGBBARCAAGBQJMkK19AAoJENLqJKaHCXE7VKgAn3XwpBVoBbfk
+5n+dom25oCsrOi03AJ9T38JsbN03NtUF+1nay+L3tgH1bokCHAQQAQoABgUCU5DPJAAKCRCD
+gslcKQI9+dbhD/9xG+zPsXG0D7ASXVrjoPW3nF8yIn/UhLHDn/Bi6CeRBwaIBfHnO1BK1y2/
+OZJGMcNflOQ3iYowMFadB/pAKnyDWP/TBZOEkjQz0QlI2YVXnfjynvjP0WuPCkFKUdwBWoc1
+uow9P7EgX1UWxMWPTk3oRu+LAuvKHU36wFmq7sZ2FgL+33uzzvRvkSHn5u0XiOx5tQhu/50d
+V+FybRpOZO/w2Cvm8DVR2PhPocsrFOBdYWWNx4mCov7QxrVRUwlxcz4AltSNof45JbUN1Oy5
+XEtoTGsgmnkSuunm4qFnPBgKupoId0H2MlMMI4z6uczJKKa6kLMTYD43l+EutXSpTHajMRRy
+1tEcamQDo1ET7c/EDrYAYjUWhDC7g+gW3dLzSf2+XbC481LiOoStUEFJyJhWeLatQ+UB55Rd
+vIRMQLYYrP1wKwVjuy9s8+tPSR8/1VQwpgN6y2HSMQTtVWJ/HeU0ywmXDNU1C/UA/e5dDtNJ
+qkqUjQzxNK0Mskkvxle44D7rkpIS7Z2oE9wMAif9wVxWyFTLC6DygWypboLR/yk1NfVwyuzT
+Vz908SZYEAuwP3OvaoJkVoeU0JpYQdIAxq68JMUfP4JZTCGr77zSzQTv1rB6AH64/uvsIITH
+9KXWb/uE0v1zGzg1mENOHFyPigrSYO79MME3EbwTtJLddw4HmIkCPQQTAQgAJwIbAwULCQgH
+AwUVCgkICwUWAgMBAAIeAQIXgAUCUDTIRQUJB4YhfAAKCRBOI9CsqNERKoQkEACbmlU7ALbo
+7gjnyN21/obkwLhLNxz8QxLWhPRlcDhn/5+1eqvDnKoVGBOYFoUPNBqPUmt0dS4cJwWNQA/p
+upnlNGauCJF6Djrj2zgAU9nkZb/H1H2MrH8xP/KNz5uAk1sVdszJ/jGDjddavwZ3DqwUxR6/
+qxcVMve9pMC9Oi3uPlC6oDKcvoTqQpRHAaMYcSfcE/2+PN1d7xNSAjJFA8DHCexNp+RiKr2C
+iaLNdnd5TyJVQ7/9WUqoDRbLrYkAzBsMvgUlX

Bug#144076: [PATCH] wget -nv doesn't show enough errors

[Mathieu Parent]

Hello,

Here is the patch for this long-standing bug.


See also:
https://bugs.debian.org/144076

Regards

-- 
Mathieu Parent
diff -ur wget-1.16.1-old/src/connect.c wget-1.16.1/src/connect.c
--- wget-1.16.1-old/src/connect.c   2014-12-02 08:49:37.0 +0100
+++ wget-1.16.1/src/connect.c   2015-01-08 14:30:27.052969833 +0100
@@ -366,7 +366,7 @@
 if (sock >= 0)
   fd_close (sock);
 if (print)
-  logprintf (LOG_VERBOSE, _("failed: %s.\n"), strerror (errno));
+  logprintf (LOG_NOTQUIET, _("failed: %s.\n"), strerror (errno));
 errno = save_errno;
 return -1;
   }

Bug#774078: does not cleanly upgrade if /home and /var are different filesystems

[Stephan Sürken]

On Fr, 2015-01-02 at 08:48 +0100, Marc Haber wrote:
> On Tue, Dec 30, 2014 at 06:59:19PM +0100, Stephan Sürken wrote:
> > That said ;), the final problem that (in the end) broke things with
> > _your_ setup imho was the lack of space in /var, as usermod supports
> > moving across filesystems just fine.
> 
> Yes, but I don't think that a user must expect multiple gigabytes (~ 6
> in my case) to be moved to /var during a package update.

Sure, I was not arguing against that ;).

The fix now always prefers the home of the actually existing mini-buildd
user, even over a previously set debconf value. As an extra, this also
handles manual (not via debconf) changes to the mini-buildd user
gracefully.

Such a move/copy on upgrade could now only happen in case the debconf
value is explicitly changed.

Hth,

S


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774860: quassel-core crashes on client connect

[Florian Kraus]

Package: quassel-core
Version: 0.8.0-1+deb7u3
Severity: normal

Dear Maintainer,

quasselcore (0.8.0-1+deb7u3 on wheezy) crashes when trying to connect to it
from a client (1:0.10.0-2.2 on jessie).
The initial configuration seems to work though, but after that it crashes.

2015-01-08 13:31:04 Info: SQLite Storage Backend is ready. Quassel Schema
Version: 17
2015-01-08 13:31:04 Info: Listening for GUI clients on IPv6 :: port 4242 using
protocol version 10
2015-01-08 13:31:14 Info: Client connected from :::83EA:42BD%0
2015-01-08 13:31:15 Warning: Peer tried to send package larger than max package
size!
2015-01-08 13:31:15 Warning: Disconnecting :::83EA:42BD%0
2015-01-08 13:31:15 Info: Non-authed client disconnected. :::83EA:42BD%0
2015-01-08 13:31:15 Info: Client connected from :::83EA:42BD%0
2015-01-08 13:31:15 Debug: Starting TLS for Client: :::83EA:42BD%0
2015-01-08 13:31:15 Debug: Using compression for Client: :::83EA:42BD%0
2015-01-08 13:31:15 Info: Client :::83EA:42BD%0 initialized and
authenticated successfully as "ArtooDetoo" (UserId: 1).
2015-01-08 13:31:15 Debug: Quassel IRC:  "0.8.0"
"5988f4cd56e54fbe02e668fd48bf430e80f33f55"
2015-01-08 13:31:15 Debug: #  0 quasselcore  0x0054fa84
Quassel::logBacktrace(QString const&)
2015-01-08 13:31:15 Debug: #  1 quasselcore  0x005370ef
Quassel::handleSignal(int)
2015-01-08 13:31:15 Debug: #  2 libc.so.60x7f7e5a0e21e0
0x
2015-01-08 13:31:15 Debug: #  3 libQtScript.so.4 0x7f7e5b3c7c5e
0x
2015-01-08 13:31:15 Debug: #  4 libQtScript.so.4 0x7f7e5b44c629
0x
2015-01-08 13:31:15 Debug: #  5 libQtScript.so.4 0x7f7e5b44cdec
0x
2015-01-08 13:31:15 Debug: #  6 libQtScript.so.4 0x7f7e5b4ed380
0x
2015-01-08 13:31:15 Debug: #  7 libQtScript.so.4 0x7f7e5b4ee2fe
QScriptEngine::QScriptEngine(QObject*)
2015-01-08 13:31:15 Debug: #  8 quasselcore  0x004b4b75
CoreSession::CoreSession(UserId, bool, QObject*)
2015-01-08 13:31:15 Debug: #  9 quasselcore  0x00480f99
SessionThread::run()
2015-01-08 13:31:15 Debug: # 10 libQtCore.so.4   0x7f7e5bda4d0b
0x
2015-01-08 13:31:15 Debug: # 11 libpthread.so.0  0x7f7e5bb0db50
0x
2015-01-08 13:31:15 Debug: # 12 libc.so.60x7f7e5a18c7bd clone

Kind regards,
Florian Kraus



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

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774860: Acknowledgement (quassel-core crashes on client connect)

[Florian Kraus]

Obviously reportbug placed my client's system information in the report,
which is not where the program crashes.

Here some info about the server:

Debian Release: Wheezy
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.41-042stab094.8


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#666499: Wrong frequency after suspend to ram

[Tim Small]

Package: cpufrequtils
Version: 008-1
Followup-For: Bug #666499

I'm also seeing this on a Dell Studio XPS 8100

The first CPU gets the correct frequency settings on resume, but the
others don't.

On boot - set via /etc/default/cpufrequtils:

ENABLE="true"
GOVERNOR="ondemand"
MAX_SPEED=2133000
MIN_SPEED=0



# cpufreq-info | grep 'be within'
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.13 GHz.


After a suspend-to-ram, then resume:

# cpufreq-info | grep 'be within'
current policy: frequency should be within 1.20 GHz and 2.13 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.
current policy: frequency should be within 1.20 GHz and 2.80 GHz.


i.e. first CPU retains settings, others revert to boot-time defaults.


I don't know what code (kernel/userspace/BIOS) should be responsible for
restoring the CPU frequency settings after resume, but it's not working
on this system the Jessie kernel.

As a workaround I created this script as 
/lib/systemd/system-sleep/cpufrequtilsrestart

#!/bin/sh
case $1 in
pre)
# Do nothing
exit 0
;;
post)
echo "Setting CPU frequency preferences following system resume"
systemctl restart cpufrequtils.service
;;
esac




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

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

Versions of packages cpufrequtils depends on:
ii  debconf [debconf-2.0]  1.5.55
ii  libc6  2.19-13
ii  libcpufreq0008-1
ii  lsb-base   4.1+Debian13+nmu1

cpufrequtils recommends no packages.

cpufrequtils suggests no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774861: libwine-alsa, libwine-gl: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: libwine-alsa,libwine-gl
Version: 1.6.2-17
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  wheezy -> jessie (package wine, with --install-recommends)

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.mainstscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

4m59.7s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libwine-alsa/changelog.Debian.gz (libwine-alsa) != 
/usr/share/doc/libwine/changelog.Debian.gz (libwine:i386)
/usr/share/doc/libwine-alsa -> libwine
  /usr/share/doc/libwine-alsa/copyright (libwine-alsa) != 
/usr/share/doc/libwine/copyright (libwine:i386)
/usr/share/doc/libwine-alsa -> libwine
  /usr/share/doc/libwine-gl/changelog.Debian.gz (libwine-gl:i386) != 
/usr/share/doc/libwine/changelog.Debian.gz (libwine:i386)
/usr/share/doc/libwine-gl -> libwine
  /usr/share/doc/libwine-gl/copyright (libwine-gl:i386) != 
/usr/share/doc/libwine/copyright (libwine:i386)
/usr/share/doc/libwine-gl -> libwine


cheers,

Andreas


wine_1.6.2-17.log.gz
Description: application/gzip

Bug#774863: RFP: googleplaydownloader -- A graphical frontend to download APKs from Google Play store

[Anthony Wong]

Package: wnpp
Severity: wishlist

* Package name: googleplaydownloader
  Version : 1.6
  Upstream Author : Tuxicoman 
* URL : http://codingteam.net/project/googleplaydownloader
* License : AGPL
  Programming Lang: Python
  Description : A graphical frontend to download APKs from Google Play store

Download Android application APK from Google Play Store without any
personal Google account.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774788: [PKG-Openstack-devel] Bug#774788: neutron-metadata-agent overwrites config on update

[Thomas Goirand]

On 01/07/2015 11:42 PM, Benedikt Trefzer wrote:
> 
> 
> On 07.01.2015 22:40, Thomas Goirand wrote:
>> On 01/07/2015 05:43 PM, Benedikt Trefzer wrote:
>>> Package: neutron-metadata-agent
>>> Version: 2014.1.3-8
>>> Severity: serious
>>>
>>> Hi
>>> Upgrade of neutron-metadata-agent overwrites the parameter
>>> auth_url in /etc/neutron/metadata_agent.ini
>>
>> Hi Benedict,
>>
>> What happens is that the auth_url in neutron.conf is first read, and
>> then what's in there is used to alter the auth_url of metadata_agent.ini
>> to match that. I don't think it's normal that you don't have matching
>> pairs, and therefore, I don't believe this is a bug, as the postinst
>> just repairs a broken config.
>>
>> I'm not closing this bug to give you the opportunity to let me know your
>> thoughts here.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>>
> Hi Thomas
> 
> I'm using the openstack puppet modules to handle the config files in
> out production environment.
> Since neutron-server is not running on the same host as the metadata
> agent, neutron.conf does not have an auth_url entry at all (which for
> that case is not necessar).
> 
> That's probably why it's then overwritten with the default, (from the
> templates file) which makes the neutron-metadata-agent unusable until
> the next puppet run.
> 
> To conclude, yes it's happening in a working, not broken environment.
> Setting the auth_url value in neutron.conf to avoid a change in
> metadata_agent.ini seems to be a workaround (did not yet test this), but
> I don't think this should be the solution.
> 
> Cheers,
> 
> Benedikt

Hi Benedikt,

Mi intend here was to have the debconf prompt happen only once when
installing the metadata server. So I was simply re-using the same
debconf variable. Obviously, this was a bad idea.

This last commit should be fixing your issue when using puppet:
http://anonscm.debian.org/cgit/openstack/neutron.git/commit/?id=5c17e246c7e1ed00a7f58ba1be98ab0185d25b81

Please give me your comments about it, then I'll upload it if you all
think it's ok.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774865: openntpd: new upstream release 5.7p1

[oldlaptop]

Package: openntpd
Version: 20080406p-10
Severity: wishlist

There is a new portable release of OpenNTPD available from upstream, as 
of January 8 2015:


http://www.openntpd.org/txt/release-5.7p1.txt


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774686: [Pkg-clamav-devel] Bug#774686: ClamAV: Can't create new file

[Sebastian Andrzej Siewior]

* =?UTF-8?Q?B=C3=bcsc...@buxtehude.debian.org | 2015-01-06 10:09:21 [+0100]:

>On some files clamav reports an error.
>Example:
>root@host:~# clamscan projectlibre-1.5.9.msi
>projectlibre-1.5.9.msi: Can't create new file ERROR

If you start with --debug you see

| LibClamAV debug: CAB/CAB-SFX signature found at 5120
| LibClamAV debug: CDBNAME:CL_TYPE_MSCAB:0:ANTLR.TXT:0:1208:0:0:0:(nil)
| LibClamAV debug: cli_scanmscab() failed to extract 9
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: cli_scanraw: MaxEmbeddedPE exceeded
| LibClamAV debug: Descriptor[3]: Continuing after cli_scanraw error Can't 
create new file
| LibClamAV debug: cli_magic_scandesc: returning 9  at line 2327

clamav finds a CAB file within the MSI file and scans it. The mspack
library finds a file named ANTLR.TXT but uncompressing fails with a CRC
error (denoted by the number 9). I have no idea if this is a valid error
or a bug in the mspack library. Unfortunately the error code from
libmspack is passed up to clamav which is intepreted differently and
this leads to the wrong "Can't create new file" error. 

>This file can be downloaded at 
>http://sourceforge.net/projects/projectlibre/files/ProjectLibre/1.5.9/ or 
>directly 
>http://netcologne.dl.sourceforge.net/project/projectlibre/ProjectLibre/1.5.9/projectlibre-1.5.9.msi
Thank you, this was helpfull.

>The same error occurs with HAVP and clamav as proxy filter with virus scan.

Is there a limitation of using HAVP due to this error?

>An system with debian squeeze 6.0.10 (LTS enabled) and 
>clamav-0.98.1+dfsg-1+deb6u4 doesn't report an error.
The problem is how I wired up libmspack. I will check later how the old
library handles the unpacking error.

Sebastian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774866: libqglviewer2: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: libqglviewer2
Version: 2.5.3+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  squeeze -> wheezy (keeping the squeeze package) -> jessie

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.mainstscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

3m55.2s INFO: dirname part contains a symlink:
  /usr/share/doc/libqglviewer2/README (libqglviewer2:amd64) != 
/usr/share/doc/libqglviewer-qt3-2/README (?)
/usr/share/doc/libqglviewer2 -> libqglviewer-qt3-2
  /usr/share/doc/libqglviewer2/changelog.Debian.gz (libqglviewer2:amd64) != 
/usr/share/doc/libqglviewer-qt3-2/changelog.Debian.gz (?)
/usr/share/doc/libqglviewer2 -> libqglviewer-qt3-2
  /usr/share/doc/libqglviewer2/changelog.gz (libqglviewer2:amd64) != 
/usr/share/doc/libqglviewer-qt3-2/changelog.gz (?)
/usr/share/doc/libqglviewer2 -> libqglviewer-qt3-2
  /usr/share/doc/libqglviewer2/copyright (libqglviewer2:amd64) != 
/usr/share/doc/libqglviewer-qt3-2/copyright (?)
/usr/share/doc/libqglviewer2 -> libqglviewer-qt3-2

3m55.9s ERROR: FAIL: debsums reports modifications inside the chroot:
  debsums: missing file /usr/share/doc/libqglviewer2/README (from 
libqglviewer2:amd64 package)
  debsums: missing file /usr/share/doc/libqglviewer2/changelog.Debian.gz (from 
libqglviewer2:amd64 package)
  debsums: missing file /usr/share/doc/libqglviewer2/changelog.gz (from 
libqglviewer2:amd64 package)
  debsums: missing file /usr/share/doc/libqglviewer2/copyright (from 
libqglviewer2:amd64 package)


cheers,

Andreas


libqglviewer2_2.5.3+dfsg-2.log.gz
Description: application/gzip

Bug#774867: lirc-x: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: lirc-x
Version: 0.9.0~pre1-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  squeeze -> wheezy -> jessie

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.mainstscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

2m28.1s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/lirc-x/NEWS.Debian.gz (lirc-x) != 
/usr/share/doc/lirc/NEWS.Debian.gz (lirc)
/usr/share/doc/lirc-x -> lirc
  /usr/share/doc/lirc-x/changelog.Debian.gz (lirc-x) != 
/usr/share/doc/lirc/changelog.Debian.gz (lirc)
/usr/share/doc/lirc-x -> lirc
  /usr/share/doc/lirc-x/copyright (lirc-x) != /usr/share/doc/lirc/copyright 
(lirc)
/usr/share/doc/lirc-x -> lirc


cheers,

Andreas


lirc-x_0.9.0~pre1-1.1.log.gz
Description: application/gzip

Bug#774868: php-pager: unhandled symlink to directory conversion: /usr/share/php/tests/Pager/tests

[Andreas Beckmann]

Package: php-pager
Version: 2.4.8-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  squeeze -> wheezy -> jessie

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.mainstscript.
Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


>From the attached log (usually somewhere in the middle...):

3m38.1s INFO: dirname part contains a symlink:
  /usr/share/php/tests/Pager/tests/README (php-pager) != 
/usr/share/doc/php-pager/tests/README (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/all_tests.php (php-pager) != 
/usr/share/doc/php-pager/tests/all_tests.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/multibyte_post.php (php-pager) != 
/usr/share/doc/php-pager/tests/multibyte_post.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_include.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_include.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_jumping_noData_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_jumping_noData_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_jumping_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_jumping_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_jumping_tests.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_jumping_tests.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_noData_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_noData_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_post_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_post_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_post_test_simple.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_post_test_simple.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_post_tests.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_post_tests.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_sliding_noData_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_sliding_noData_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_sliding_notExpanded_test.php 
(php-pager) != 
/usr/share/doc/php-pager/tests/pager_sliding_notExpanded_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_sliding_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_sliding_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_sliding_tests.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_sliding_tests.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_test.php (php-pager) != 
/usr/share/doc/php-pager/tests/pager_test.php (?)
/usr/share/php/tests/Pager/tests -> ../../../doc/php-pager/tests
  /usr/share/php/tests/Pager/tests/pager_test_xss.php (php-pager) != 
/usr/share/doc/php-page

Bug#774702: linux-image-3.16.0-4-amd64: Regression in topology for multi-NUMA-node Haswell Xeon CPUs

[Mehdi Dogguy]

Just for the sake of completeness, this regression happens only when
Cluster On Die is enabled. Sorry for not saying that in my initial
report.

Regards,

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774869: libmodule-build-perl: please output data in stable order

[Jérémy Bobbio]

Source: libmodule-build-perl
Version: 0.421000-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libmodule-build-perl could not be built reproducibly. It also
prevents other packages to build reproducibly.

The issue is that it outputs data with keys in a different order at each
run. The attached patch will tell Data::Dumper to sort the keys,
resulting in a stable output.

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

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#774871: guayadeque: Removable media not detected if using pmount or udevil

[Rob Owens]

Package: guayadeque
Version: 0.3.7~ds0-2.1
Severity: normal

If I use either pmount or udevil to mount a USB stick, Guayadeque
does not detect it as removable media.  Pmount creates a mount point
like /media/sdb1.  Udevil is configured on my system to create a mount
point like /media/$USER/$LABEL.  But Guayadeque does not detect
either one.

USB detection worked prior to making systemd the default.  I did not
move to systemd, but stuck with sysvinit.  

This drastically reduces the functionality of Guayadeque for me, as
my primary use case is transcoding flac files and copying them to 
USB stick for use in a car stereo which doesn't support flac.  USB 
detection worked fine until a short time after systemd became Debian's 
default.  

I had been using pcmanfm to mount my USB sticks.  That in turn uses
gvfs, which eventually tried to change my init system to systemd.  I 
opted instead to use spacefm which uses either udevil or pmount to 
mount USB sticks.  Udevil even mounts them to the same mount point as 
pcmanfm/gvfs would have, but Guayadeque doesn't seem to notice.

Great media player, by the way.  I switched from Rhythmbox a couple 
years back because Guayadeque has better control/configurability of 
transcoding options, and I like its interface better than the recent 
versions of Rhythmbox.


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

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

Versions of packages guayadeque depends on:
ii  gstreamer0.10-plugins-base  0.10.36-2
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+b1
ii  libc6   2.19-13
ii  libcurl3-gnutls 7.38.0-3
ii  libdbus-1-3 1.8.12-3
ii  libgcc1 1:4.9.1-19
ii  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgpod40.8.3-1.1+b1
ii  libgstreamer0.10-0  0.10.36-1.5
ii  libindicate50.6.92-2
ii  libstdc++6  4.9.1-19
ii  libtag1c2a  1.9.1-2.1
ii  libwxbase3.0-0  3.0.2-1+b1
ii  libwxgtk3.0-0   3.0.2-1+b1
ii  libwxsqlite3-3.0-0  3.1.1~dfsg1-1

guayadeque recommends no packages.

guayadeque suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774870: pcmanfm: Add support for udevil and pmount

[Rob Owens]

Package: pcmanfm
Version: 1.2.3-1
Severity: wishlist
Tags: upstream

Spacefm has the ability to use udevil or pmount for mounting of
removable media.  I would like to see this functionality included 
in pcmanfm.


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

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

Versions of packages pcmanfm depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-13
ii  libcairo21.14.0-2.1
ii  libfm-gtk4   1.2.3-1
ii  libfm4   1.2.3-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgtk2.0-0  2.24.25-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libx11-6 2:1.6.2-3

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme   3.12.0-1
pn  gvfs-backends  
pn  gvfs-fuse  
ii  lxde-icon-theme0.5.1-1
ii  lxsession [policykit-1-gnome]  0.5.1-2

pcmanfm suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774795: [php-maint] Bug#774795: php5, mysql-server-5.5: php5 FTBFS on ppc64el due to mysql assertion failure "InnoDB: Failing assertion: node->n_pending == 0"

[Ondřej Surý]

Control: reassign -1 mysql-server-5.5
Control: affects -1 php5

Hi Niels,

it looks like a bug in mysqld binary on ppc64el.

I will workaround the bug by disabling tests on ppc64el, but it needs to
be fixed in mysql-server-5.5 package.

Cheers,
Ondrej

On Wed, Jan 7, 2015, at 18:48, Niels Thykier wrote:
> Package: php5,mysql-server-5.5
> Severity: serious
> 
> Hi PHP5 maintainers and MySQL maintainers,
> 
> I noticed that PHP5 FTBFS on powerpc64el with the following[1]:
> 
> """
> 150105 16:07:30 InnoDB: 5.5.40 started; log sequence number 0
> 150105 16:07:30  InnoDB: Starting shutdown...
> 150105 16:07:31  InnoDB: Assertion failure in thread 70367505444544 in
> file fil0fil.c line 860
> InnoDB: Failing assertion: node->n_pending == 0
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
> InnoDB: If you get repeated assertion failures or crashes, even
> InnoDB: immediately after the mysqld startup, there may be
> InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB:
> http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> 16:07:31 UTC - mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly
> built,
> or misconfigured. This error can also be caused by malfunctioning
> hardware.
> We will try our best to scrape up some info that will hopefully help
> diagnose the problem, but since we have already crashed, 
> something is definitely wrong and this may fail.
> 
> key_buffer_size=8388608
> read_buffer_size=131072
> max_used_connections=0
> max_threads=151
> thread_count=0
> connection_count=0
> It is possible that mysqld could use up to 
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 338508 K  bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
> 
> Thread pointer: 0x0
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 0 thread_stack 0x4
> /usr/sbin/mysqld(my_print_stacktrace+0x48)[0x30f42bd8]
> /usr/sbin/mysqld(handle_fatal_signal+0x4ac)[0x30dbff5c]
> linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0)[0x3fffb62b0478]
> /lib/powerpc64le-linux-gnu/libc.so.6(gsignal+0x48)[0x3fffb5d70978]
> /lib/powerpc64le-linux-gnu/libc.so.6(abort+0x26c)[0x3fffb5d72d7c]
> /usr/sbin/mysqld(+0x70d8d0)[0x3109d8d0]
> /usr/sbin/mysqld(+0x712908)[0x310a2908]
> /usr/sbin/mysqld(+0x755950)[0x310e5950]
> /usr/sbin/mysqld(+0x687b34)[0x31017b34]
> /usr/sbin/mysqld(+0x6433b8)[0x30fd33b8]
> /usr/sbin/mysqld(_Z22ha_finalize_handlertonP13st_plugin_int+0x5c)[0x30dc33dc]
> /usr/sbin/mysqld(+0x3172d0)[0x30ca72d0]
> /usr/sbin/mysqld(+0x31d00c)[0x30cad00c]
> /usr/sbin/mysqld(_Z15plugin_shutdownv+0x2d0)[0x30cae8f0]
> /usr/sbin/mysqld(+0x27f870)[0x30c0f870]
> /usr/sbin/mysqld(unireg_abort+0x258)[0x30c108c8]
> /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x948)[0x30c17698]
> /usr/sbin/mysqld(main+0x18)[0x30bf9b98]
> /lib/powerpc64le-linux-gnu/libc.so.6(+0x24e00)[0x3fffb5d54e00]
> /lib/powerpc64le-linux-gnu/libc.so.6(__libc_start_main+0xc4)[0x3fffb5d54ff4]
> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html
> contains
> information that should help you find out what is causing the crash.
> make: *** [test-results.txt] Error 1
> """
> 
> Being an "assertion failure" (and given the remarks about the binary
> being possibly corrupt) I suspect it is a problem in the MySQL
> package.  If you agree with this, please reassign it to the relevant
> mysql-server package (possibly with an "affects" on php5).
> 
> ~Niels
> 
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=php5&arch=ppc64el&ver=5.6.4%2Bdfsg-3&stamp=1420474234
> 
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint


-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774872: gpsd: prompting due to modified conffiles which were not modified by the user: /etc/default/gpsd

[Andreas Beckmann]

Package: gpsd
Version: 3.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up gpsd (3.11-1) ...
  
  Configuration file '/etc/default/gpsd'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** gpsd (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package gpsd 
(--configure):
   EOF on stdin at conffile prompt

This was observed during an squeeze -> wheezy -> jessie upgrade test.


cheers,

Andreas


gpsd_3.11-1.log.gz
Description: application/gzip

Bug#769068: missing petalogix firmware for microblaze arch

[Tomas Martišius]

Hello,

After adding missing petalogix* files, they are duplicated in
qemu-system-misc and qemu-system-ppc packages,
so install of both qemu-system-misc and qemu-system-ppc fails with:

Unpacking qemu-system-misc (1:2.2+dfsg-2) over (2.1+dfsg-10.1) ...
dpkg: error processing archive
/var/cache/apt/archives/qemu-system-misc_1%3a2.2+dfsg-2~1_amd64.deb
(--unpack):
 trying to overwrite '/usr/share/qemu/petalogix-s3adsp1800.dtb', which
is also in package qemu-system-ppc 1:2.2+dfsg-2~1
Apdorojant įvyko klaidų:
 /var/cache/apt/archives/qemu-system-misc_1%3a2.2+dfsg-2~1_amd64.deb
needrestart is being skipped since dpkg has failed

Best regards,

Tomas

On Tue, 11 Nov 2014 10:40:46 +0400 Michael Tokarev  wrote:
> Package: qemu-system-misc
> Version: 2.1+dfsg-5
> Severity: normal
> Tags: patch
>
> The package is missing two firmware files for qemu-system-microblaze,
> petalogix-ml605.dtb and petalogix-s3adsp1800.dtb. These files has
> been removed in DFSG-fication step from the upstream sources due to
> lack of source code for them, but it turns out that these files ARE
> the source as upstream ships them. dtc is used to convert between
> dtb (binary) and dts (editable text) forms, and the conversion is
> 1:1 in this case, there's nothing in the original dts besides the
> content dtc produces given a dtb.
>
> The solution is to restore the upstream files, stop removing them
> for DFSG, and ship them in qemu-system-misc. Unfortunately this
> requires a new source upload.
>
> Alternative is to ship .dts files in debian/ and compile them during
> build time. Somewhat ugly but should work too.
>
> /mjt
>
>

-- 
Pagarbiai

Tomas Martišius
Vytauto Didžiojo universiteto
vyr. tinklo administratorius





signature.asc
Description: OpenPGP digital signature

Bug#774874: maradns: prompting due to modified conffiles which were not modified by the user: /etc/maradns/mararc

[Andreas Beckmann]

Package: maradns
Version: 2.0.09-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up maradns (2.0.09-3+b1) ...
  Installing new version of config file /etc/init.d/maradns ...
  
  Configuration file '/etc/maradns/mararc'
   ==> Deleted (by you or by a script) since installation.
   ==> Package distributor has shipped an updated version.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** mararc (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package maradns 
(--configure):
   EOF on stdin at conffile prompt
  Errors were encountered while processing:
   maradns

This was observed during an squeeze -> wheezy -> jessie upgrade test

cheers,

Andreas


maradns_2.0.09-3+b1.log.gz
Description: application/gzip

Bug#774873: Dependencies are not always configured before the depending package, since 9ee62ec

[Iain Lane]

Package: dpkg
Version: 1.17.23
Severity: serious

Hello,

[ Reported as RC because it could make packages fail to install
  correctly, but I don't have an instance in Debian handy, so feel free
  to downgrade ]

Since commit 9ee62ecfc8937f24a82805a424564997042dd984 ("Make the initial
dependtry be 1 instead of 0"), dpkg will in some circumstances configure
the dependencies of a package *after* configuring the package itself.

I noticed this in Ubuntu where we have a package "floodlight" which has
Depends on default-jre-headless and tries to use /usr/bin/java, which is
set up in the postinst of openjdk-7-jre-headless using alternatives.
openjdk-7-jre-headless is being configured after floodlight, meaning
that this fails. Here's the log

  
https://jenkins.qa.ubuntu.com/job/vivid-adt-floodlight/15/ARCH=amd64,label=adt/console

You should see "start/started" after floodlight is configured, not
"start/pre-start". The error reveals itself in the log files on the
system.

Attached is an equivs control file that you can use to reproduce this on
Debian. It's not minimal, but was enough for me to be able to bisect it
down to the commit identified. A way to reproduce is like this (ignore
vivid, that's the name of the host):

(sid-amd64)root@vivid:/# dpkg --version
Debian `dpkg' package management program version 1.17.23 (amd64).
[…]
(sid-amd64)root@vivid:/# apt-cache show foo
[…]
Depends: default-jre-headless | java6-runtime-headless
(sid-amd64)root@vivid:/# apt-cache show default-jre-headless
[…]
Depends: openjdk-7-jre-headless (>= 7~u3-2.1.1), […]
[…]
(sid-amd64)root@vivid:/# apt-get install --no-install-recommends foo
[…]
Setting up foo (1.0) ...
Setting up openjdk-7-jre-headless:amd64 (7u71-2.5.3-2) ...

(-headless is configured after foo which transitively depends on it)

And you can reproduce like this, once you've got the dependencies
installed

(sid-amd64)root@vivid:/# dpkg --unpack --auto-deconfigure 
/var/cache/apt/archives/default-jre-headless_2%3a1.7-52_amd64.deb 
/var/cache/apt/archives/ca-certificates-java_20140324_all.deb 
/var/cache/apt/archives/openjdk-7-jre-headless_7u71-2.5.3-2_amd64.deb 
/var/cache/apt/archives/foo_1.0_all.deb
[…]
(sid-amd64)root@vivid:/# dpkg --configure openjdk-7-jre-headless:amd64 
ca-certificates-java:all default-jre-headless:amd64 foo:all
Setting up default-jre-headless (2:1.7-52) ...
Setting up foo (1.0) ...
Setting up openjdk-7-jre-headless:amd64 (7u71-2.5.3-2) ...
Setting up ca-certificates-java (20140324) ...
[…]

Let me know if you need any more info, like debugging output.

(If a solution isn't immediately apparent, is this commit safe to revert
for the time being?)

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
### Commented entries have reasonable defaults.
### Uncomment to edit them.
# Source: 
Section: misc
Priority: optional
# Homepage: 
Standards-Version: 3.9.2

Package: foo
# Version: 
# Maintainer: Your Name 
# Pre-Depends: 
Depends: default-jre-headless | java6-runtime-headless
# Recommends: 
# Suggests: 
# Provides: 
# Replaces: 
# Architecture: all
# Copyright: 
# Changelog: 
# Readme: 
# Extra-Files: 
# Files: 
#  
Description:  
 long description and info
 .
 second paragraph

Bug#774876: ocl-icd: FTBFS on mips64el - testsuite errors

[James Cowgill]

Source: ocl-icd
Version: 2.2.3-1
Severity: important

Hi,

ocl-icd FTBFS on mips64el due to the failure of the test
 "5: Our dummy ICD through our ICD loader"

The full log is here, but doesn't contain much detail:
http://mips64el.debian.net/debian/buildlog/o/ocl-icd_2.2.3-1/ocl-icd_2.2.3-1_mips64el-20141231-1651.build

The tail of testsuite.log contains:
> 83  : clSetMemObjectDestructorCallback
> 84  : clCreateUserEvent
> 85  : clSetUserEventStatus
> 86  : ./testsuite-standard.at:48: exit code was 139, expected 0
> 5. testsuite-standard.at:45: 5. Our dummy ICD through our ICD loader 
> (testsuite-standard.at:45): FAILED (testsuite-standard.at:48)

I had a look at the segfault and it appears the stack was being corrupt
by some dodgy function calls in the test.

The dummy ICD test attempts to call all the OpenCL functions using a
dummy ICD but for simplicity calls them with only 2 arguments (see
run_dummy_icd_gen.c + run_dummy_icd_weak_gen.c)

Function 86 in the list is clEnqueueReadBufferRect (found in
ocl_icd_loader_gen.c). The key property of this function is that it has
a 32-bit integer parameter beyond the 8th argument. The MIPS n64 ABI
says that this argument must be passed on the stack and sign extended to
64-bits. To ensure this, GCC inserts a load and store to sign extend the
value during the call:
 RETURN(((struct _cl_command_queue 
*)command_queue)->dispatch->clEnqueueWriteBufferRect
but because the ICD test only passes 2 arguments instead of the required
number, the above line ends up corrupting some random part of the
previous function's stack space.

Clearly the "correct" way of fixing this is to pass the correct number
of arguments, but if that introduces too much complexity you could just
disable the test on mips64* due to the ABI being incompatible with it.

Thanks,
James


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774877: sympa: prompting due to modified conffiles which were not modified by the user: /etc/sympa/facility

[Andreas Beckmann]

Package: sympa
Version: 6.1.23~dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up sympa (6.1.23~dfsg-1) ...
  Installing new version of config file /etc/init.d/sympa ...
  
  Configuration file '/etc/sympa/facility'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** facility (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package sympa 
(--configure):
   EOF on stdin at conffile prompt

This was observed during an squeeze -> wheezy -> jessie upgrade test.


cheers,

Andreas


sympa_6.1.23~dfsg-1.log.gz
Description: application/gzip

Bug#773036: libetpan-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Ricardo Mones]

Hi Vincent!

On Fri, Jan 02, 2015 at 01:56:32AM -0800, Vincent Cheng wrote:
> Hi Ricardo,
> 
> I've attached a full debdiff (in the form of a NMU), which I haven't
> uploaded yet (but I'm happy to upload this if you have no objections).
> As for how to test it, well, I'm not an expert when it comes to
> piuparts, but I was able to reproduce the original error with:
> 
> # piuparts -m 'http://ftp.debian.org/debian/' -a -d wheezy -d sid libetpan-dbg
> 
> After applying the attached debdiff and building libetpan, you can use
> the following pbuilder invocation to check your package (I guess you
> can ignore the debsums-related error that piuparts spits out):
> 
> # piuparts -m 'http://ftp.debian.org/debian/' -d wheezy -d sid
> libetpan_1.5-1.1_amd64.changes

Many thanks for the patch! I've just adapted it for a regular upload and
is now in the archive. Piuparts command succeeds with the debsums errors
you mentioned, so all seems fine.

Thanks again to all and happy new year,
-- 
  Ricardo Mones 
  ~
  The three principal virtues of a programmer are Laziness, 
  Impatience, and Hubris.man perl



signature.asc
Description: Digital signature

Bug#774875: reportbug fails to start because missing add_metaclass

[Moshe Yudkowsky]

Package: reportbug
Version: 6.6.3

Reportbug itself fails to start:

: reportbug
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 38, in 
from reportbug import utils
  File "/usr/lib/python2.7/dist-packages/reportbug/utils.py", line 70, 
in 

import debbugs
  File "/usr/lib/python2.7/dist-packages/reportbug/debbugs.py", line 
43, in 

import checkversions
  File "/usr/lib/python2.7/dist-packages/reportbug/checkversions.py", 
line 39, in 

from debian.deb822 import Deb822
  File "/usr/lib/python2.7/dist-packages/debian/deb822.py", line 1481, 
in 

@six.add_metaclass(_ClassInitMeta)
AttributeError: 'module' object has no attribute 'add_metaclass'


Current setup:

reportbug6.6.3
3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux
python-debian0.1.25
python3-debian   0.1.25
python2.72.7.9-1
python33.4.2-2 amd64
python3.4  3.4.2-4 amd64

Also installed: pythons 2.4, 2.5, 2.6

Is there a conflict between the deb822.py supplied by python-debian and 
the version needed by 2.7?

--
Moshe Yudkowsky * mo...@pobox.com * www.pobox.com/~moshe
 "Today my head is my own.  To-night, when it is yours, you may do
  with it as you please."  - Montrose, 20 May 1650


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774869: libmodule-build-perl: please output data in stable order

[Jonas Smedegaard]

Quoting Jérémy Bobbio (2015-01-08 16:01:48)
> While working on the “reproducible builds” effort [1], we have noticed 
> that libmodule-build-perl could not be built reproducibly. It also 
> prevents other packages to build reproducibly.
> 
> The issue is that it outputs data with keys in a different order at 
> each run. The attached patch will tell Data::Dumper to sort the keys, 
> resulting in a stable output.

Thanks!

Seems you missed the attachment, though...

 - Jonas

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

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


signature.asc
Description: signature

Bug#774869: libmodule-build-perl: please output data in stable order

[Jérémy Bobbio]

Jonas Smedegaard:
> Seems you missed the attachment, though...

Oops. :)

It's also available from
git://git.debian.org/reproducible/libmodule-build-perl.git

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru libmodule-build-perl-0.421000/debian/changelog libmodule-build-perl-0.421000/debian/changelog
--- libmodule-build-perl-0.421000/debian/changelog	2014-09-19 11:10:35.0 +0200
+++ libmodule-build-perl-0.421000/debian/changelog	2015-01-08 15:53:11.0 +0100
@@ -1,3 +1,9 @@
+libmodule-build-perl (0.421000-2.0~reproducible1) UNRELEASED; urgency=low
+
+  * Add a patch to output data in stable order to make builds reproducible.
+
+ -- Jérémy Bobbio   Thu, 08 Jan 2015 15:52:19 +0100
+
 libmodule-build-perl (0.421000-2) unstable; urgency=medium
 
   [ gregor herrmann ]
diff -Nru libmodule-build-perl-0.421000/debian/patches/output-data-in-stable-order.patch libmodule-build-perl-0.421000/debian/patches/output-data-in-stable-order.patch
--- libmodule-build-perl-0.421000/debian/patches/output-data-in-stable-order.patch	1970-01-01 01:00:00.0 +0100
+++ libmodule-build-perl-0.421000/debian/patches/output-data-in-stable-order.patch	2015-01-08 15:53:11.0 +0100
@@ -0,0 +1,16 @@
+Description: output data in a stable order
+ In order to make builds reproducible, we sort keys when dumping
+ data.
+Author: Jérémy Bobbio 
+
+--- libmodule-build-perl-0.421000.orig/lib/Module/Build/Dumper.pm
 libmodule-build-perl-0.421000/lib/Module/Build/Dumper.pm
+@@ -12,7 +12,7 @@ use Data::Dumper;
+ sub _data_dump {
+   my ($self, $data) = @_;
+   return ("do{ my "
+-	  . Data::Dumper->new([$data],['x'])->Purity(1)->Terse(0)->Dump()
++	  . Data::Dumper->new([$data],['x'])->Purity(1)->Terse(0)->Sortkeys(1)->Dump()
+ 	  . '$x; }')
+ }
+ 
diff -Nru libmodule-build-perl-0.421000/debian/patches/series libmodule-build-perl-0.421000/debian/patches/series
--- libmodule-build-perl-0.421000/debian/patches/series	2014-09-19 11:10:35.0 +0200
+++ libmodule-build-perl-0.421000/debian/patches/series	2015-01-08 15:53:11.0 +0100
@@ -1,2 +1,3 @@
 man-ext
 0001-Allow-loading-from-system-path-when-running-under-au.patch
+output-data-in-stable-order.patch


signature.asc
Description: Digital signature

Bug#774878: unblock: libetpan/1.5-2

[Ricardo Mones]

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

Hi Release Team,

Please unblock package libetpan for fixing RC bug #773036 “libetpan-dbg:
unhandled symlink to directory conversion: /usr/share/doc/PACKAGE”

Full debdiff to testing version attached.

Thanks in advance,

unblock libetpan/1.5-2

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armel (armv5tel)
diff -Nru libetpan-1.5/debian/changelog libetpan-1.5/debian/changelog
--- libetpan-1.5/debian/changelog	2014-06-11 18:38:34.0 +0200
+++ libetpan-1.5/debian/changelog	2015-01-07 22:23:43.0 +0100
@@ -1,3 +1,15 @@
+libetpan (1.5-2) unstable; urgency=high
+
+  [ Vincent Cheng ]
+  * Fix unhandled symlink to directory conversion. (Closes: #773036)
+
+  [ Ricardo Mones ]
+  * Change Vincent's patch versions and changelog entry to make it a
+regular upload and thank him very much for the patch! :)
+  * Raise urgency because of RC bug.
+
+ -- Ricardo Mones   Wed, 07 Jan 2015 14:10:56 +0100
+
 libetpan (1.5-1) unstable; urgency=medium
 
   * New upstream release: not really, identical to 1.4.1 but version
diff -Nru libetpan-1.5/debian/control libetpan-1.5/debian/control
--- libetpan-1.5/debian/control	2014-06-11 18:38:34.0 +0200
+++ libetpan-1.5/debian/control	2015-01-07 22:23:43.0 +0100
@@ -28,6 +28,7 @@
 Section: libdevel
 Priority: extra
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, libetpan17 (= ${binary:Version}),
  libgnutls28-dev, liblockfile-dev, libsasl2-dev, libexpat1-dev,
  libcurl4-gnutls-dev (>= 7.16.4-5)
@@ -56,6 +57,7 @@
 Architecture: any
 Multi-Arch: same
 Priority: extra
+Pre-Depends: ${misc:Pre-Depends}
 Depends: libetpan17 (= ${binary:Version}), ${misc:Depends}
 Description: debugging symbols for libetpan
  libEtPan! is a mail library. It may be used for low-level mail handling:
diff -Nru libetpan-1.5/debian/libetpan-dbg.maintscript libetpan-1.5/debian/libetpan-dbg.maintscript
--- libetpan-1.5/debian/libetpan-dbg.maintscript	1970-01-01 01:00:00.0 +0100
+++ libetpan-1.5/debian/libetpan-dbg.maintscript	2015-01-07 22:23:43.0 +0100
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/libetpan-dbg /usr/share/doc/libetpan15 1.5-2~
diff -Nru libetpan-1.5/debian/libetpan-dev.maintscript libetpan-1.5/debian/libetpan-dev.maintscript
--- libetpan-1.5/debian/libetpan-dev.maintscript	1970-01-01 01:00:00.0 +0100
+++ libetpan-1.5/debian/libetpan-dev.maintscript	2015-01-07 22:23:43.0 +0100
@@ -0,0 +1 @@
+symlink_to_dir /usr/share/doc/libetpan-dev /usr/share/doc/libetpan15 1.5-2~

Bug#774808: debsources: line number undefined

[Matthieu Caneill]

On 7 January 2015 at 20:43, Reiner Herrmann  wrote:
> I'm using Iceweasel 34.0, and when I'm viewing a source file
> on sources.debian.net and click on a line number, it jumps
> to the current URL with #Lundefined appended (instead of e.g. #L123).
>
> It is working correctly with konqueror, but it occurs even with
> a new iceweasel profile (i.e. no addons installed).

Hi,
Thanks for the report.
I can reproduce this bug. As it works fine when I manually enter such
an URL, I believe the bug is due to the new javascript module
(debsources.js) which automatically highlights lines with internal
links (#L42).
Jason: any idea where this comes from?

Cheers,
--
Matthieu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)

[Tomas Pospisek]

Hello Kjetil,

On Wed, 7 Jan 2015, Kjetil Kjernsmo wrote:


On Wednesday 7. January 2015 08.23.32 Tomas Pospisek wrote:


Kjetil and Christian is it possible for you to test this?


As of now, I only have my laptop to test Jessie, which is something I 
use every day, and so I'm anxious about putting such an important thing 
as systemd from experimental on it. I've had the ambition to be able to
easily set up virtual hosts for these occasions for a long time, but 
alas, ENOTIME.


well, this is quite demotivating.

I am not concerned by the cryptosetup problem, I just wanted to help make 
the upgrade to the coming release better for people that are using crypted 
partitions.


But lets see, whether you're maybe able to contribute just a tiny bit -

Other than dropping the effort to try to improve on this particular 
problem I see two ways forward:


  a) you could test on your computer and I help you a bit
  b) I could test on my computer and you help me a bit
  a&b=c) we could both test

Let's see a)

You can do:

# apt-get install lxc
# lxc-create -n test_VM -t debian -- -r jessie

This will create a VM under /var/lib/lxc/test_VM, that you
can easilly remove later with

# rm -r /var/lib/lxc/test_VM

You can start the VM with:

# lxc-start -n test_VM

If you go and do something different while lxc-create is downloading its 
stuff, the whole thing takes about 1 minute of your time.


After that you can set up the crypted device and install systemd from 
experimental inside and see whether it works.


Now way forward b)
==

Could you tell me how to quickly set up a crypt device?


Please let me know what you think, greetings,
*t


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)

[Tomas Pospisek]

reopen 768314
reassign 768314 systemd
tags 768314 + help
thanks

It would be very nice, if concerned people could test systemd from 
experimental with a cryptsetup, so the patches could be maybe backported 
into jessie.


(reopening since this bug is closed and reassigning to systemd,
 since that's currently the scope within which this problem could be
 solved IMHO)

*t

On Wed, 7 Jan 2015, Tomas Pospisek wrote:


Thanks Zbigniew

Kjetil and Christian is it possible for you to test this?
*t

On Wed, 7 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote:


On Tue, Jan 06, 2015 at 06:56:11PM +0100, Tomas Pospisek wrote:

Hello Zbigniew,

I was told on IRC in #debian-systemd:

   tpo, I remember Zbigniew had a patch

without wanting to stress anybody: could you maybe tell me what the
status of that patch is? Are you considering it ready for inclusion
in Debian's systemd? Is it possible that it would be ready and
included prior to jessie's release?


systemd git should now avoid output when waiting for the password.
IIRC, my initial patch was followed up by a few cleanups, so it might
not be very backportable, but latest systemd in experimental should have
all the changes. I'd suggest that you test if that version works for you.

Zbyszek

Bug#774879: reportbug should prompt if attachments are allowed by user

[Nils Dagsson Moskopp]

Package: reportbug
Version: 6.6.0
Severity: wishlist

Dear Maintainer,


In bug #771561 reportbug silently attached my /etc/fstab to the bug report.
This file contained information that others have already been harassed for.

The file was deleted from the Debian bug tracking system.
However, I think it would be good if reportbug would prompt the user.
Then the user could decide if attachments to the bug report should be uploaded.


-- Package-specific info:
** Environment settings:
INTERFACE="urwid"

** /home/erlehmann/.reportbugrc:
reportbug_version "6.4.4"
mode standard
ui urwid
email "nils+debian-report...@dieweltistgarnichtso.net"
no-cc
header "X-Debbugs-CC: nils+debian-report...@dieweltistgarnichtso.net"
smtphost reportbug.debian.org

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.13-1-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages reportbug depends on:
ii  apt   1.0.9.3
ii  python2.7.8-2
ii  python-reportbug  6.6.0
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  dlocate   
ii  emacs23-bin-common23.4+1-4.1+b1
ii  file  1:5.20-2
ii  gnupg 1.4.18-4
ii  msmtp-mta [mail-transport-agent]  1.4.32-2
ii  python-gtk2   2.24.0-4
pn  python-gtkspell   
ii  python-urwid  1.2.1-2+b1
ii  python-vte1:0.28.2-5
ii  xdg-utils 1.1.0~rc1+git20111210-7.1

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.3
ii  python-debian 0.1.25
ii  python-debianbts  1.12
pn  python:any

python-reportbug suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774881: package haskell-ieee754 is causing FTBFS of package haskell-hastache on big-endian

[Jurica Stanojkovic]

Package: haskell-ieee754
Version:0.7.3-3
Severity: serious
Tags: sid + patch
User: debian-m...@lists.debian.org
Usertags: mips-patch


Hello,

Package haskell-ieee754 is reason why package haskell-hastache is FTBFS on 
big-endian.

I have attached a patch for this issue.
With this patch applied to package haskell-ieee754 I was able to build package 
haskell-hastache on mips big-endian successfully.

Upstream issue:
https://github.com/lymar/hastache/issues/36#

Thank you!

Regards,
Jurica
--- haskell-ieee754-0.7.3.orig/cbits/feqrel_source.c
+++ haskell-ieee754-0.7.3/cbits/feqrel_source.c
@@ -16,7 +16,7 @@
 # define REAL_EXPBIAS((uint16_t) 0x3F00)
 # define REAL_EXPBIAS_INT32  ((uint32_t) 0x7F80)
 # define REAL_MANTISSAMASK_INT32 ((uint32_t) 0x007F)
-# if BIG_ENDIAN == 1
+# if BYTE_ORDER == BIG_ENDIAN
 #  define REAL_EXPPOS_INT16 0
 # else
 #  define REAL_EXPPOS_INT16 1
@@ -28,7 +28,7 @@
 # define REAL_EXPBIAS((uint16_t) 0x3FE0)
 # define REAL_EXPBIAS_INT32  ((uint32_t) 0x7FF0)
 # define REAL_MANTISSAMASK_INT32 ((uint32_t) 0x000F); /* for the MSB only */
-# if BIG_ENDIAN == 1
+# if BYTE_ORDER == BIG_ENDIAN
 #  define REAL_EXPPOS_INT16 0
 #  define REAL_SIGNPOS_BYTE 0
 # else

Bug#774788: [PKG-Openstack-devel] Bug#774788: neutron-metadata-agent overwrites config on update

[Benedikt Trefzer]

On 08.01.2015 15:20, Thomas Goirand wrote:
> 
> Hi Benedikt,
> 
> Mi intend here was to have the debconf prompt happen only once when
> installing the metadata server. So I was simply re-using the same
> debconf variable. Obviously, this was a bad idea.
> 
> This last commit should be fixing your issue when using puppet:
> http://anonscm.debian.org/cgit/openstack/neutron.git/commit/?id=5c17e246c7e1ed00a7f58ba1be98ab0185d25b81
> 
> Please give me your comments about it, then I'll upload it if you all
> think it's ok.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

Hi Thomas

I had a look at the commit. This looks ok, and I think this does solve
my problem.
Though if I understand it correctly, this patch also means, that if
installation is made interactivly, the user is twice asked for the
values for neutron-metadata-agent/*.

If you like me to build and install (or better upgrade) the package on
my test instance to confirm the fix, please let me know (but it has to
wait until tomorrow).

Thanks

Benedikt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774880: nmu: maya-calendar_0.3-1~experimental1

[Andreas Beckmann]

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

nmu maya-calendar_0.3-1~experimental1 . ALL . experimental . -m "Rebuild 
against libical1a."

libical1 has been renamed to libical1a.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774686: AW: [Pkg-clamav-devel] Bug#774686: ClamAV: Can't create new file

[Büschel]

Hello Sebastian,

>Is there a limitation of using HAVP due to this error?
If you use HAVP with clamav engine as proxy then you won't be able to download 
this file. HAVP reports the clamav error and finish. No download.

regards

Uwe Büschel
INTER-FORUM AG
Sommerfelder Straße 120
04316 Leipzig

Telefon: 0341 25920-99
Fax: 0341 25920-20

E-Mail:  uwe.buesc...@inter-forum.de
WWW: http://www.inter-forum.de

Registergericht: Amtsgericht Leipzig
Registernummer:  HRB 18238
Vorstand:Jan Schaller (Vors.), Dr. Jörg Härtwig
Aufsichtsrat:Thomas Joschko (Vors.)
USt-IdNr.:   DE141624398
IK:  661430035

Bug#774856: [buildd-tools-devel] Bug#774856: buildd: undeclared dependency on sudo

[Wookey]

+++ Adam Borowski [2015-01-08 13:46 +0100]:
> Package: buildd
> Version: 0.65.0-1
> Severity: normal
> 
> Hi!
> Installed buildd spams the following cron mail:
> ,
> Error reading configuration: SUDO binary 'sudo' does not exist or is not
> executable at /usr/share/perl5/Buildd/Conf.pm line 77.
> `
> Installing 'sudo' manually makes it happy.

That should be a 'recommends', I think? As it will operate without it (but 
whinge)?

Or does it in fact also fail to operate?

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774808: debsources: line number undefined

[Jason Pleau]

Hello!

On 08/01/15 10:31 AM, Matthieu Caneill wrote:
> On 7 January 2015 at 20:43, Reiner Herrmann  wrote:
>> I'm using Iceweasel 34.0, and when I'm viewing a source file
>> on sources.debian.net and click on a line number, it jumps
>> to the current URL with #Lundefined appended (instead of e.g. #L123).
>>
>> It is working correctly with konqueror, but it occurs even with
>> a new iceweasel profile (i.e. no addons installed).
> 
> Hi,
> Thanks for the report.
> I can reproduce this bug. As it works fine when I manually enter such
> an URL, I believe the bug is due to the new javascript module
> (debsources.js) which automatically highlights lines with internal
> links (#L42).
> Jason: any idea where this comes from?
> 

I will need to have a more closer look tonight after work, but at first
sight what I can notice is that there is a javascript error in the page
(in debsources.js at line 35). This part of the file was added by this
commit [1]

---
33: var msgbox = document.getElementById('messages');
34: var index = document.getElementById('sourceslinenumbers');
35: var divHeight = msgbox.offsetHeight;
---

If msgbox is null (because there are no elements with an ID of
'messages', then msgbox.offsetHeight will error out.


Sometimes a javascript error like this can lead to weird behaviors,
similar to what Reiner reported. But I will test a bit more tonight to
confirm if that's the case or not (and try to submit a patch for the
little issue I pointed above).



> Cheers,
> --
> Matthieu
> 

Thanks

Jason

[1]:
http://anonscm.debian.org/cgit/qa/debsources.git/commit/debsources/app/static/javascript/debsources.js?id=e246fcfeb7f20dde3f026d2c4ff8f7e71fc8e303


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774882: openssl: fail to verify some sites when 1024bit root CAs removed

[Hiroyuki YAMAMORI]

Package: openssl
Version: 1.0.1j-1
Severity: normal

Dear Maintainer,

To avoid security weakness, when 1024-bit RSA root CAs removed,
verify error occurs in some sites with cross root CA. 

I've seen following,
https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4

And fixed patch is following,
http://rt.openssl.org/Ticket/Display.html?id=3637&user=guest&pass=guest
[PATCH] x509: skip certs if in alternative cert chain

I've test this patch. No issues were found.

My tests are following.
1) build openssl packages that applied the patch and install these.
2) remove root CAs in /usr/share/ca-certificates/mozilla/
 Equifax_Secure_*.crt
 GTE_CyberTrust_Global_Root.crt
 Thawte_*.crt
 Verisign_Class_3_Public_Primary_Certification_Authority.crt
 Verisign_Class_3_Public_Primary_Certification_Authority_2.crt
3) [strace] openssl s_client -CApath /etc/ssl/certs -showcerts -connect 
s3.amazonaws.com:443
 test other sites, e.g. www.debian.org, www.geotrust.co.jp, dinahosting.com


Thank you.
--
Hiroyuki YAMAMORI


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

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

Versions of packages openssl depends on:
ii  libc62.19-13
ii  libssl1.0.0  1.0.1j-1+p1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20141019

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774876: ocl-icd: FTBFS on mips64el - testsuite errors

[Vincent Danjean]

  Hi,

On 08/01/2015 16:22, James Cowgill wrote:
> Source: ocl-icd
> Version: 2.2.3-1
> Severity: important
> 
> Hi,
> 
> ocl-icd FTBFS on mips64el due to the failure of the test
>  "5: Our dummy ICD through our ICD loader"
> 
> The full log is here, but doesn't contain much detail:
> http://mips64el.debian.net/debian/buildlog/o/ocl-icd_2.2.3-1/ocl-icd_2.2.3-1_mips64el-20141231-1651.build
> 
> The tail of testsuite.log contains:
>> 83  : clSetMemObjectDestructorCallback
>> 84  : clCreateUserEvent
>> 85  : clSetUserEventStatus
>> 86  : ./testsuite-standard.at:48: exit code was 139, expected 0
>> 5. testsuite-standard.at:45: 5. Our dummy ICD through our ICD loader 
>> (testsuite-standard.at:45): FAILED (testsuite-standard.at:48)
> 
> I had a look at the segfault and it appears the stack was being corrupt
> by some dodgy function calls in the test.
> 
> The dummy ICD test attempts to call all the OpenCL functions using a
> dummy ICD but for simplicity calls them with only 2 arguments (see
> run_dummy_icd_gen.c + run_dummy_icd_weak_gen.c)
> 
> Function 86 in the list is clEnqueueReadBufferRect (found in
> ocl_icd_loader_gen.c). The key property of this function is that it has
> a 32-bit integer parameter beyond the 8th argument. The MIPS n64 ABI
> says that this argument must be passed on the stack and sign extended to
> 64-bits. To ensure this, GCC inserts a load and store to sign extend the
> value during the call:
>  RETURN(((struct _cl_command_queue 
> *)command_queue)->dispatch->clEnqueueWriteBufferRect
> but because the ICD test only passes 2 arguments instead of the required
> number, the above line ends up corrupting some random part of the
> previous function's stack space.
> 
> Clearly the "correct" way of fixing this is to pass the correct number
> of arguments, but if that introduces too much complexity you could just
> disable the test on mips64* due to the ABI being incompatible with it.

Thank you very much for your very detailed analysis.

For the time being, I will just, indeed, disable the test.
And Brice and I will think to a way to make it more robust
(perhaps by not using standard headers to avoid this kind
of problem, or by finding a way to autogenerate the good
API)

  Regards and thanks again
Vincent

> Thanks,
> James
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC

[Ian Jackson]

(Resending with debian-perl in the CC.)

Andreas Beckmann writes ("Bug#774844: xfonts-traditional: fails to upgrade from 
'wheezy': Can't locate File/Find.pm in @INC"):
> Package: xfonts-traditional
> Version: 1.7.1

Thanks for the report.  This is definitely a bad bug which must be
fixed for jessie.

> At the point where the error occurs we have these packages
> installed/unpacked:
>  dpkg: wheezy
>  perl-base: wheezy (no File/Find.pm, yet)
>  perl-modules: jessie (no File/Find.pm any longer)
>  xfonts-traditional: wheezy
> 
> i.e. the triggers from xfonts-traditional/wheezy are run by dpkg/wheezy.
> What triggered them btw?

I think that the target package for this bug is perhaps wrong.  (That
is, that the change will have to be made to a different package.)
Certainly the version is wrong: at the point where this bug occurs,
xfonts-traditional_1.7.1_all.deb has not even been touched.

> Since File/Find.pm moved to perl-base, [...]

I think that the current dependency structure would permit:
 * Start with wheezy, without xfonts-traditional
 * Unpack perl-modules from jessie but do not configure it
 * Install xfonts-traditional

But xfonts-traditional depends on `perl', not `perl-modules' or
`perl-base'.  And `perl' is not deconfigured merely because one of its
dependencies goes from configured to unpacked.  So at this point
xfonts-traditional's postinst will run but the actual purpose of its
dependency on `perl' is not fully satisfied.  The postinst will fail.

This arises from the fact that in dpkg the `dependencies are
configured when postinst is run' requirement is not transitive: it
doesn't apply to the dependencies of one's dependencies.

AFAICT xfonts-traditional's use of dependencies conforms to the
recommendation in the perl policy:
  https://www.debian.org/doc/packaging-manuals/perl-policy/ch-programs.html

If my scenario above is correct, this problem is not confined to
packages involving triggers, nor necessarily to xfonts-traditional.
Rather the problem is that the policy implies that most packages will
depend on just `perl', but `perl' can be `installed' despite some of
the functionality it is supposed to provide (File/Find.pm in this
case) being missing.

I think the right fix therefore has to be in the Perl packages.

Here is a suggestion: have perl-modules (jessie) declare a Breaks on
perl (wheezy).

That declares it necessary to deconfigure perl (wheezy) to install
perl-modules (jessie).  perl (wheezy) cannot be re-configured until
perl-modules (which it depends on) is re-configured, but perl-modules
(jessie) depends on perl-base (jessie) so apt and dpkg will have to
unpack and configure perl-base (jessie) first.

Thus it will not be possible for `perl' to be `installed' while
File/Find.pm is absent.  And xfonts-traditional's (or some other
client package)'s postinst won't run until `perl' is `installed'
again.

> Since File/Find.pm moved to perl-base, maybe the Depends: perl can be
> changed to Depends: perl-base (>= 5.20.1-3~)
> and perl-modules could add a Breaks: xfonts-traditional (<= 1.7.1)

But, firstly, that's not an entirely accurate description of
xfonts-traditional dependencies.  The package does in fact work with
older perls.  And, this approach suggests that perl-modules should
grow a Breaks for every package in the archive which uses File::Find,
which doesn't seem like a very good approach.

Regards,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774792: only half fixed ?

[Benedikt Trefzer]

resending to bug ...


Hi Thomas

Changing the default value in the template does only half fix this bug.
Now the upgrade does not fail. Which is good.

But I do not have a possibility to enable the
neutron-db-manage section in postinst script.
(beside setting it up with debconf, which is not an option ...)

This is also explained in Point 2 and 6.

I think there are two possible solutions for this.
Either have a separate debconf entry ask for manage DB on updates,
or simply do a lookup in the neutron.conf file for the DB connection
string (and not in the debconf values !). If string is found, then
the DB is available and configured. if not, then do not start manageDB.

In case of a noninteractive installation, the connection string in
neutron.conf is set to sqlite on localhost, so it updates the DB there
(wich is not used but does not hurt). This is the same behaviour as
currently if the connection string is not deleted.

If you want me to open a second bug report for this, let me know.

Cheers

Benedikt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774873: Dependencies are not always configured before the depending package, since 9ee62ec

[Guillem Jover]

Hi!

On Thu, 2015-01-08 at 15:15:43 +, Iain Lane wrote:
> Package: dpkg
> Version: 1.17.23
> Severity: serious

> [ Reported as RC because it could make packages fail to install
>   correctly, but I don't have an instance in Debian handy, so feel free
>   to downgrade ]

I don't think this is a bug at all in dpkg, but see below.

> Since commit 9ee62ecfc8937f24a82805a424564997042dd984 ("Make the initial
> dependtry be 1 instead of 0"), dpkg will in some circumstances configure
> the dependencies of a package *after* configuring the package itself.

The only effect of that commit was that it removed a run stage from
the package processing queue, possibly affecting how packages are
ordered in some cases, which has exposed wrong assumptions (for example
in debootstrap). But any package depending on that specific ordering
was relying on undefined behavior.

> And you can reproduce like this, once you've got the dependencies
> installed

Thanks for the reproducer!

> (sid-amd64)root@vivid:/# dpkg --unpack --auto-deconfigure 
> /var/cache/apt/archives/default-jre-headless_2%3a1.7-52_amd64.deb 
> /var/cache/apt/archives/ca-certificates-java_20140324_all.deb 
> /var/cache/apt/archives/openjdk-7-jre-headless_7u71-2.5.3-2_amd64.deb 
> /var/cache/apt/archives/foo_1.0_all.deb
> […]
> (sid-amd64)root@vivid:/# dpkg --configure openjdk-7-jre-headless:amd64 
> ca-certificates-java:all default-jre-headless:amd64 foo:all
> Setting up default-jre-headless (2:1.7-52) ...
> Setting up foo (1.0) ...
> Setting up openjdk-7-jre-headless:amd64 (7u71-2.5.3-2) ...
> Setting up ca-certificates-java (20140324) ...
> […]
> 
> Let me know if you need any more info, like debugging output.
> 
> (If a solution isn't immediately apparent, is this commit safe to revert
> for the time being?)

The problem here is that there's a dependency cycle and dpkg breaks it
now in a different place due to the change in the processing queue. But
this has been a latent issue or an actual issue (depending on the
upgrade path) on the java packages. Here's the cycle:

  foo -Depends→ default-jre-headless | java6-runtime-headless
  default-jre-headless -Depends→ openjdk-7-jre-headless
  default-jre-headless -Provides→ java6-runtime-headless
  openjdk-7-jre-headless -Depends→ ca-certificates-java
  openjdk-7-jre-headless -Provides→ java6-runtime-headless
  ca-certificates-java -Depends→
openjdk-6-jre-headless (>= 6b16-1.6.1-2) | java6-runtime-headless

And dpkg decides to do this (from the debug output), after having made
no progress so far:

,---
[…]
D000400: findbreakcyclerecursive openjdk-6-jre-headless  <- ca-certificates-java
D000400: findbreakcyclerecursive java6-runtime-headless  <- ca-certificates-java
D000400: findbreakcyclerecursive default-jre-headless:amd64  <- 
ca-certificates-java
D000400: findbreakcyclerecursive openjdk-7-jre-headless:amd64  <- 
default-jre-headless <- ca-certificates-java
D40: found cycle
D40: cycle broken at default-jre-headless:amd64 -> openjdk-7-jre-headless
[…]
D01: process queue pkg default-jre-headless:amd64 queue.len 3 progress 1, tr
D000400: findbreakcyclerecursive default-jre-headless:amd64
D000400: findbreakcyclerecursive java-common:all  <- default-jre-headless
D40: checking dependencies of default-jre-headless:amd64 (- )
D000400:   checking group ...
D000400: checking possibility  -> openjdk-7-jre-headless
D000400:   break cycle so ok and found
D000400:   found 3 matched 0 possfixbytrig -
D000400:   checking group ...
D000400: checking possibility  -> java-common
D000400:   checking non-provided pkg java-common:all
D000400:   is installed, ok and found
D000400: found 3
D000400:   found 3 matched 0 possfixbytrig -
D40: ok 2 msgs >><<
D40: checking Breaks
D000400:  checking virtbroken java-runtime-headless
D000400:  checking virtbroken java2-runtime-headless
D000400:  checking virtbroken java5-runtime-headless
D000400:  checking virtbroken java6-runtime-headless
D000400:  checking virtbroken java7-runtime-headless
Setting up default-jre-headless (2:1.7-52) ...
`---

And that's why the Depends order is not preserved. This needs to be
reassigned and fixed somewhere in the Java packages.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774883: # CONFIG_PMAC_APM_EMU is not set anymore

[Mathieu Malaterre]

Package: pmud
Severity: important

I believe the pmud package should be removed from jessie since it
relies internally on CONFIG_PMAC_APM_EMU being set. This is not longer
the case, therefore /proc/apm is not available anymore.

$ cat README.Debian
[...]
Recent kernels should have APM emulation built in so /proc/apm should be
used where possible.
[...]


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774884: kmail: Cannot choose my smime cert in KMail

[Kai Michael Hamich]

Package: kmail
Version: 4:4.14.1-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I imported my certs and could not choose it for signing my emails.

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

I tried to choose a cert and then i choosed a key in the dialog

   * What was the outcome of this action?

The key-icon in front of the line got a red-cross and the "OK"-Button is grey
and disabled

   * What outcome did you expect instead?

the cert should be useable, as in evolution where it works like a charm

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



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

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

Versions of packages kmail depends on:
ii  kde-runtime   4:4.14.2-2
ii  kdepim-runtime4:4.14.2-2
ii  kdepimlibs-kio-plugins4:4.14.2-2+b1
ii  libakonadi-calendar4  4:4.14.2-2+b1
ii  libakonadi-contact4   4:4.14.2-2+b1
ii  libakonadi-kde4   4:4.14.2-2+b1
ii  libakonadi-kmime4 4:4.14.2-2+b1
ii  libakonadiprotocolinternals1  1.13.0-2
ii  libc6 2.19-13
ii  libcalendarsupport4   4:4.14.1-1
ii  libfollowupreminder4  4:4.14.1-1
ii  libgcc1   1:4.9.1-19
ii  libgpgme++2   4:4.14.2-2+b1
ii  libgrantlee-core0 0.4.0-2
ii  libincidenceeditorsng44:4.14.1-1
ii  libkabc4  4:4.14.2-2+b1
ii  libkalarmcal2 4:4.14.2-2+b1
ii  libkcalcore4  4:4.14.2-2+b1
ii  libkcalutils4 4:4.14.2-2+b1
ii  libkcmutils4  4:4.14.2-4
ii  libkdecore5   4:4.14.2-4
ii  libkdepim44:4.14.1-1
ii  libkdeui5 4:4.14.2-4
ii  libkio5   4:4.14.2-4
ii  libkleo4  4:4.14.1-1
ii  libkmanagesieve4  4:4.14.1-1
ii  libkmime4 4:4.14.2-2+b1
ii  libknewstuff3-4   4:4.14.2-4
ii  libknotifyconfig4 4:4.14.2-4
ii  libkontactinterface4a 4:4.14.2-2+b1
ii  libkparts44:4.14.2-4
ii  libkpgp4  4:4.14.1-1
ii  libkpimidentities44:4.14.2-2+b1
ii  libkpimtextedit4  4:4.14.2-2+b1
ii  libkpimutils4 4:4.14.2-2+b1
ii  libkprintutils4   4:4.14.2-4
ii  libksieveui4  4:4.14.1-1
ii  libktnef4 4:4.14.2-2+b1
ii  libmailcommon44:4.14.1-1
ii  libmailimporter4  4:4.14.1-1
ii  libmailtransport4 4:4.14.2-2+b1
ii  libmessagecomposer4   4:4.14.1-1
ii  libmessagecore4   4:4.14.1-1
ii  libmessagelist4   4:4.14.1-1
ii  libmessageviewer4 4:4.14.1-1
ii  libpimcommon4 4:4.14.1-1
ii  libqt4-dbus   4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtwebkit4  2.3.4.dfsg-3
ii  libsendlater4 4:4.14.1-1
ii  libsolid4 4:4.14.2-4
ii  libstdc++64.9.1-19
ii  libtemplateparser44:4.14.1-1
ii  perl  5.20.1-4

Versions of packages kmail recommends:
ii  gnupg-agent   2.0.26-3
ii  gnupg22.0.26-3
ii  pinentry-gtk2 [pinentry-x11]  0.8.3-2

Versions of packages kmail suggests:
ii  bogofilter 1.2.4+dfsg1-3
pn  clamav | f-prot-installer  
ii  kaddressbook   4:4.14.1-1
ii  kleopatra  4:4.14.1-1
ii  procmail   3.22-22

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org