Bug#787969: udev integration: overheating disk caused by mistakes in 85-hdparm.rules and hdparm-functions

[g1]

Package: hdparm
Version: 9.43-2
Severity: important

Mistake in /lib/udev/rules.d/85-hdparm.rules:
ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]*", 
RUN+="/lib/udev/hdparm"
should be 
ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]", 
RUN+="/lib/udev/hdparm"

As it is now, the rule matches when partitions are detected by udev,
typically after the disk device, and /lib/udev/hdparm is invoked with
e.g. DEVNAME=/dev/sda2 after being invoked with DEVNAME=/dev/sda.
I'm quite confident this is not the behaviour most users expect.

Brain damage in /lib/hdparm/hdparm-functions:
hdparm_options() contains 
# set our default global apm policy here.
if hdparm_try_apm "$WANTED_DISK"; then
if hdparm_is_on_battery; then
hdparm_set_option -B128
...
else
hdparm_set_option -B254
fi
fi
which causes it to emit "-B254" or "-B128" even if no stanza in
/etc/hdparm.conf matches the device name (and usually hdparm.conf has
no stanza for partitions).  Since the ioctl() on the partition acts in
fact on the disk, the result is that power management is set on the disk
depending only on battery vs AC status, overriding user's preferences
listed in /etc/hdparm.conf for the disk.

As a side note: duplicating (almost) the parsing logic of
/etc/init.d/hdparm in /lib/hdparm/hdparm-functions is an efficient way
to let bugs slip through.

Best regards
g

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

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hdparm depends on:
ii  libc6 2.19-18
ii  lsb-base  4.1+Debian13+nmu1

Versions of packages hdparm recommends:
pn  powermgmt-base  

Versions of packages hdparm suggests:
pn  apmd  

-- Configuration Files:
/etc/hdparm.conf changed:
/dev/sda {
apm = 128
apm_battery = 128
quiet
}


-- 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#785500: Severity

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is a minor issue only, because the problem is caused by the quick-resync 
option in
the mail-account preferences.
Details see in GNOME-bugzilla.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlVz8UoACgkQ5+rBHyUt5wtwEACdEzm+zs4khjf/3Tz7pZNVdR2p
3jYAnRplROapEXYj2Cmzr4vjSW4qnAlO
=lWSH
-END PGP SIGNATURE-

Bug#787970: openni-sensor-pointclouds: FTBFS on arm64

[Edmund Grimley Evans]

Source: openni-sensor-pointclouds
Version: 5.1.0.41.4-1
Tags: patch

Here's a patch.
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/Build/Common/CommonDefs.mak openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/Build/Common/CommonDefs.mak
--- openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/Build/Common/CommonDefs.mak
+++ openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/Build/Common/CommonDefs.mak
@@ -15,6 +15,8 @@
 	HOST_PLATFORM = x86
 else ifneq (,$(findstring arm,$(MACHINE)))
 	HOST_PLATFORM = Arm
+else ifneq (,$(findstring aarch64,$(MACHINE)))
+	HOST_PLATFORM = AArch64
 else ifneq (,$(findstring ppc,$(MACHINE)))
 	HOST_PLATFORM = Powerpc
 else
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/Build/Common/Platform.AArch64 openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/Build/Common/Platform.AArch64
--- openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/Build/Common/Platform.AArch64
+++ openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/Build/Common/Platform.AArch64
@@ -0,0 +1,9 @@
+ifeq "$(CFG)" "Release"
+
+# Optimization level, minus currently buggy optimizing methods (which break bit-exact)
+CFLAGS += -O3 -fno-tree-pre -fno-strict-aliasing
+
+# More optimization flags
+CFLAGS += -ftree-vectorize -ffast-math -funsafe-math-optimizations -fsingle-precision-constant
+
+endif
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/CreateRedist/RedistMaker openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/CreateRedist/RedistMaker
--- openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/CreateRedist/RedistMaker
+++ openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/CreateRedist/RedistMaker
@@ -29,6 +29,8 @@
 		PLATFORM="x64" ;;
 	arm)
 		PLATFORM="Arm" ;;
+	aarch64)
+		PLATFORM="AArch64" ;;
 	ppc)
 		PLATFORM="Powerpc" ;;
 	arm*)
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Source/Utils/XnSensorServer/SensorServer.cpp openni-sensor-pointclouds-5.1.0.41.4/Source/Utils/XnSensorServer/SensorServer.cpp
--- openni-sensor-pointclouds-5.1.0.41.4.orig/Source/Utils/XnSensorServer/SensorServer.cpp
+++ openni-sensor-pointclouds-5.1.0.41.4/Source/Utils/XnSensorServer/SensorServer.cpp
@@ -56,7 +56,7 @@
 	nRetVal = XnSensorServerGetGlobalConfigFile(strConfigDir, strConfigFile, XN_FILE_MAX_PATH);
 	XN_CHECK_RC(nRetVal, "Resolving global config file");
 
-#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
+#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
 	xnLogSetOutputFolder("/var/log/primesense/XnSensorServer/");
 #endif
 
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Source/XnDeviceSensorV2/XnDeviceSensorInit.h openni-sensor-pointclouds-5.1.0.41.4/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
--- openni-sensor-pointclouds-5.1.0.41.4.orig/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
+++ openni-sensor-pointclouds-5.1.0.41.4/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
@@ -57,7 +57,7 @@
 
 	#define XN_SENSOR_USB_MISC_BUFFER_SIZE	0x1000
 	#define XN_SENSOR_USB_MISC_BUFFERS		1
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM)
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_ISO32
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_BULK40
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_LOWBAND_ISO		16
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Source/XnDeviceSensorV2/XnSensorClient.cpp openni-sensor-pointclouds-5.1.0.41.4/Source/XnDeviceSensorV2/XnSensorClient.cpp
--- openni-sensor-pointclouds-5.1.0.41.4.orig/Source/XnDeviceSensorV2/XnSensorClient.cpp
+++ openni-sensor-pointclouds-5.1.0.41.4/Source/XnDeviceSensorV2/XnSensorClient.cpp
@@ -882,7 +882,7 @@
 	
 #if (XN_PLATFORM == XN_PLATFORM_WIN32)
 	nRetVal = GetModuleDir(strServerDir);
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
 	sprintf(strServerDir, "/usr/lib/libopenni-sensor-primesense0");
 #endif
 

Bug#787971: openni-sensor-primesense: FTBFS on arm64

[Edmund Grimley Evans]

Source: openni-sensor-primesense
Version: 5.1.0.41-4
Tags: patch

Here's a patch.
diff -N -ru openni-sensor-primesense-5.1.0.41.orig/Platform/Linux/Build/Common/CommonDefs.mak openni-sensor-primesense-5.1.0.41/Platform/Linux/Build/Common/CommonDefs.mak
--- openni-sensor-primesense-5.1.0.41.orig/Platform/Linux/Build/Common/CommonDefs.mak
+++ openni-sensor-primesense-5.1.0.41/Platform/Linux/Build/Common/CommonDefs.mak
@@ -15,6 +15,8 @@
 	HOST_PLATFORM = x86
 else ifneq (,$(findstring arm,$(MACHINE)))
 	HOST_PLATFORM = Arm
+else ifneq (,$(findstring aarch64,$(MACHINE)))
+	HOST_PLATFORM = AArch64
 else ifneq (,$(findstring ppc,$(MACHINE)))
 	HOST_PLATFORM = Powerpc
 else
diff -N -ru openni-sensor-primesense-5.1.0.41.orig/Platform/Linux/Build/Common/Platform.AArch64 openni-sensor-primesense-5.1.0.41/Platform/Linux/Build/Common/Platform.AArch64
--- openni-sensor-primesense-5.1.0.41.orig/Platform/Linux/Build/Common/Platform.AArch64
+++ openni-sensor-primesense-5.1.0.41/Platform/Linux/Build/Common/Platform.AArch64
@@ -0,0 +1,9 @@
+ifeq "$(CFG)" "Release"
+
+# Optimization level, minus currently buggy optimizing methods (which break bit-exact)
+CFLAGS += -O3 -fno-tree-pre -fno-strict-aliasing
+
+# More optimization flags
+CFLAGS += -ftree-vectorize -ffast-math -funsafe-math-optimizations -fsingle-precision-constant
+
+endif
diff -N -ru openni-sensor-primesense-5.1.0.41.orig/Platform/Linux/CreateRedist/RedistMaker openni-sensor-primesense-5.1.0.41/Platform/Linux/CreateRedist/RedistMaker
--- openni-sensor-primesense-5.1.0.41.orig/Platform/Linux/CreateRedist/RedistMaker
+++ openni-sensor-primesense-5.1.0.41/Platform/Linux/CreateRedist/RedistMaker
@@ -29,6 +29,8 @@
 		PLATFORM="x64" ;;
 	arm)
 		PLATFORM="Arm" ;;
+	aarch64)
+		PLATFORM="AArch64" ;;
 	ppc)
 		PLATFORM="Powerpc" ;;
 	*)
diff -N -ru openni-sensor-primesense-5.1.0.41.orig/Source/Utils/XnSensorServer/SensorServer.cpp openni-sensor-primesense-5.1.0.41/Source/Utils/XnSensorServer/SensorServer.cpp
--- openni-sensor-primesense-5.1.0.41.orig/Source/Utils/XnSensorServer/SensorServer.cpp
+++ openni-sensor-primesense-5.1.0.41/Source/Utils/XnSensorServer/SensorServer.cpp
@@ -56,7 +56,7 @@
 	nRetVal = XnSensorServerGetGlobalConfigFile(strConfigDir, strConfigFile, XN_FILE_MAX_PATH);
 	XN_CHECK_RC(nRetVal, "Resolving global config file");
 
-#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
+#if (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
 	xnLogSetOutputFolder("/var/log/primesense/XnSensorServer/");
 #endif
 
diff -N -ru openni-sensor-primesense-5.1.0.41.orig/Source/XnDeviceSensorV2/XnDeviceSensorInit.h openni-sensor-primesense-5.1.0.41/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
--- openni-sensor-primesense-5.1.0.41.orig/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
+++ openni-sensor-primesense-5.1.0.41/Source/XnDeviceSensorV2/XnDeviceSensorInit.h
@@ -57,7 +57,7 @@
 
 	#define XN_SENSOR_USB_MISC_BUFFER_SIZE	0x1000
 	#define XN_SENSOR_USB_MISC_BUFFERS		1
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM)
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_ISO32
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_BULK40
 	#define XN_SENSOR_USB_IMAGE_BUFFER_SIZE_MULTIPLIER_LOWBAND_ISO		16
diff -N -ru openni-sensor-primesense-5.1.0.41.orig/Source/XnDeviceSensorV2/XnSensorClient.cpp openni-sensor-primesense-5.1.0.41/Source/XnDeviceSensorV2/XnSensorClient.cpp
--- openni-sensor-primesense-5.1.0.41.orig/Source/XnDeviceSensorV2/XnSensorClient.cpp
+++ openni-sensor-primesense-5.1.0.41/Source/XnDeviceSensorV2/XnSensorClient.cpp
@@ -882,7 +882,7 @@
 	
 #if (XN_PLATFORM == XN_PLATFORM_WIN32)
 	nRetVal = GetModuleDir(strServerDir);
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC || XN_PLATFORM == XN_PLATFORM_MACOSX)
 	sprintf(strServerDir, "/usr/lib/libopenni-sensor-primesense0");
 #endif
 

Bug#787884: dictionaries-common: Emacs integration needs updating for 24.4

[Agustin Martin]

2015-06-05 23:50 GMT+02:00 Reuben Thomas :
> Package: dictionaries-common
> Version: 1.25.2
> Severity: normal
>
> Using Emacs 24.4, the versions of flyspell.el and ispell.el shipped with
> dictionaries-common are out of date.

Hi, Reuben,

Apart from a couple of minor things it should be mostly up to date. I
should indeed update it to 24.4, but mainly to minimize patches.

> There’s important new functionality in Emacs 24.4’s versions: in particular,
> it looks at dictionary files themselves to compute entries for
> ispell-dictionaries-alist.
>
> As far as I can tell, at least using hunspell, I’ve no need to load any of
> the dictionaries-common elisp any more.

I know, I wrote that part ;-)

> It would be good if it were possible simply to ship extra settings rather
> than patched files, so that further problems of this sort don’t occur in
> future.

There are some non XEmacs compatible changes in Emacs 25 in the
*spell.el parts, so I am planning to stop providing patched ispell.el
and flyspell.el Emacs in dictionaries-common, although will still
provide current version for XEmacs. I am rather busy now, but I'd like
to do that for 24.5, once it reaches Debian. Since all changes needed
for Debian integration should already be in upstream versions, this
should not cause problems.

Regards,

-- 
Agustin


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

Bug#784115: inn: incoming feed is garbled

[Stefan Froehlich]

Hi Julien,

On Sat, May 30, 2015 at 12:26:58PM +0200, Julien ÉLIE wrote:
> So maybe the issue comes from Perl...  Is it possible to disable the
> Perl filters in inn.conf to see if it then works OK?

I don't know where/how to disable the filters in the configuration but
I disabled them immediately after starting the daemon with

$ ctlinnd perl n

This did not make any change, I still get those errors.

> Or a large-file support issue?
> Is the problem only with the amd64 package?
> [...]

Sorry, but I can't try this here :-(

Stefan

-- 
Für den anspruchsvollen Herren - hüpfen mit Stefan!
http://www.sloganizer.de/


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

Bug#787974: fonts-ipafont: ipafont show "005C" as "Yen Sign"

[Shinichiro HIDA]

Package: fonts-ipafont
Version: 00303-12
Severity: wishlist

Dear Maintainer,

ipafont show 005C as "Yen Sign", it may be wrong.

The code point "005C" should appear as "Reverse Solidus = backslash",
not "Yen Sign".

  005C : Reverse Solidus = backslash
   http://www.unicode.org/charts/PDF/U.pdf
   
00A5 : Yen Sign = yuan sign
 http://www.unicode.org/charts/PDF/U0080.pdf

FFE5 : Fullwidth Yen Sign ≈  00A5
   http://www.unicode.org/charts/PDF/UFF00.pdf

Thank you for your maintain.
Best Regards,

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (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=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fonts-ipafont depends on:
ii  dpkg  1.17.25
ii  fonts-ipafont-gothic  00303-12
ii  fonts-ipafont-mincho  00303-12

fonts-ipafont recommends no packages.

fonts-ipafont 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#787973: Please don't use systemctl status in postinst

[Michael Biebl]

Package: libvirt-daemon-system
Version: 1.2.16-2
Severity: normal

Hi,

I noticed the following in postinst:

# Force virtlockd to reexec if enabled
if [ -d /run/systemd/system ] && systemctl status virtlockd.service 
>/dev/null; then
   systemctl reload virtlockd.service
fi


using systemctl status is bad, since it accesses the journal, which can
be quite costly.
If you only want to test if a service is active, you can use
systemctl is-active -q virtlockd.service, which is much more
lightweight.
The -q makes sure, you don't need to suppress stdout.

if [ -d /run/systemd/system ] && systemctl is-active -q virtlockd.service ; then
   systemctl reload virtlockd.service
fi

Or even simpler for your use case
if [ -d /run/systemd/system ] ; then
   systemctl reload-or-try-restart -q virtlockd.service
fi

I think reload-or-try-restart does already exactly what you want.

Cheers,
Michael

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser  3.113+nmu3
ii  gettext-base 0.19.4-1
ii  init-system-helpers  1.23
ii  libapparmor1 2.9.2-3
ii  libaudit11:2.4-1+b1
ii  libavahi-client3 0.6.31-5
ii  libavahi-common3 0.6.31-5
ii  libblkid12.26.2-6
ii  libc62.19-18
ii  libcap-ng0   0.7.6-1
ii  libdbus-1-3  1.8.18-1
ii  libdevmapper1.02.1   2:1.02.90-2.2
ii  libgnutls-deb0-283.3.15-5
ii  libnl-3-200  3.2.24-2
ii  libnl-route-3-2003.2.24-2
ii  libnuma1 2.0.10-1
ii  librados20.80.9-2
ii  librbd1  0.80.9-2
ii  libsasl2-2   2.1.26.dfsg1-13
ii  libselinux1  2.3-2
ii  libssh2-11.5.0-2+b1
ii  libsystemd0  220-5~test0
ii  libvirt-clients  1.2.16-2
ii  libvirt-daemon   1.2.16-2
ii  libvirt0 1.2.16-2
ii  libxen-4.4   4.4.1-9
ii  libxml2  2.9.2+dfsg1-3
ii  libyajl2 2.1.0-2
ii  logrotate3.8.7-2
ii  policykit-1  0.105-8

Versions of packages libvirt-daemon-system recommends:
ii  bridge-utils  1.5-9
ii  dmidecode 2.12-4
ii  dnsmasq-base  2.72-3.1+b1
ii  ebtables  2.0.10.4-3
ii  iproute2  3.16.0-2
ii  iptables  1.4.21-2+b1
ii  parted3.2-7
pn  pm-utils  

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
ii  nfs-common  1:1.2.8-9
ii  radvd   1:2.11-1
ii  systemd 220-5~test0
pn  systemtap   

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Keine Berechtigung: u'/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 13] Keine Berechtigung: 
u'/etc/libvirt/qemu/networks/default.xml'

-- 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#781742: initramfs-tools use of triggers and DPKG_MAINTSCRIPT_PACKAGE

[Ian Campbell]

(this conversation really should have been going to the flash-kernel
clone in #781882 and not to the original upgrade-report bug in #781742,
I've adjusted CC and moved the original to BCC)

On Thu, 2015-05-07 at 15:04 +0100, Ian Campbell wrote:
> Resending with a more obvious subject.
> 
> The workaround I describe in the final paragraph does seem to work, but
> I'm not sure that's the best way to go.

So I've been mulling this over for a while and I'm afraid the conclusion
I've eventually reached is that if the initramfs has been regenerated
then we really ought to be writing it to flash too, since otherwise we
risk leaving the system in an unbootable state.

I think this risk is already somewhat present in the gap between 's update and the initramfs trigger but adding another delay
between the initramfs trigger and the flash-kernel trigger is certainly
widening it. This may even be the logic behind initramfs clobbering
$DPKG_MAINTSCRIPT_PACKAGE for all I know.

I think if there is anything to be done here it would be to investigate
reducing the number of times the initramfs is regenerated in the first
place.

Thanks for the report, it was certainly worth investigating and
considering. I'm closing the cloned bug against flash-kernel with this
message, I'll leave it up to the initramfs-tools maintainers (or others)
if they want to reclone the original bug (where all the actual useful
info is) into something.

Ian.

> 
> On Mon, 2015-05-04 at 15:31 +0100, Ian Campbell wrote:
> > (CC initramfs-tools@packages, context is flash-kernel invocation not
> > being deferred via triggers during upgrade and ultimately running
> > several times in a dist-upgrade)
> > 
> > On Sat, 2015-04-04 at 10:49 +0100, Ian Campbell wrote:
> > > At first glance it seems like invocations via the initramfs-tools hooks
> > > are not being deferred.
> > 
> > This is because initramfs-tools.postinst contains:
> > # Regenerate initramfs whenever we go to dpkg state `installed'
> > if [ "x$1" != xtriggered ]; then
> > # this activates the trigger, if triggers are working
> > update-initramfs -u
> > else
> > # force it to actually happen
> > DPKG_MAINTSCRIPT_PACKAGE='' update-initramfs -u
> > fi
> > 
> > and flash-kernel uses [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] when deciding
> > to defer to a trigger. So the invocations of flash-kernel
> > via /etc/initramfs/post-update.d/flash-kernel end up never being
> > deferred.
> > 
> > I don't think initramfs-tools is wrong to do this per-se, but it does
> > mean that anything hooked off the post-update.d hooks cannot reliably
> > use triggers (dpkg-trigger uses $DPKG_MAINTSCRIPT_PACKAGE itself).
> > 
> > flash-kernel itself does something similar, but instead of manipulating
> > DPKG_MAINTSCRIPT_PACKAGE it instead sets FLASH_KERNEL_NOTRIGGER=1 and
> > keys off that.
> > 
> > It seems like the best solution would a patch to switch initramfs-tools
> > to a similar scheme, would such a patch be accepted?
> > 
> > If not then I will arrange for /etc/initramfs/post-update.d/flash-kernel
> > to signal to f-k somehow that triggers should be used despite the lack
> > of DPKG_MAINTSCRIPT_PACKAGE.
> > 
> > Ian.
> > 
> > 
> 
> 
> 


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

Bug#783074: flash-kernel: improvements to uboot-generic bootscript

[Ian Campbell]

On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
> > The changelog says "some imx systems", do you have a list I could drop
> > in a comment or should I just say "#Workaround lack of console on
> > someIMX systems"?
> 
> I can confirm that wandboard, cubox-i and hummingboard all default to
> console=ttymxc0, and several other boards by grepping through u-boot's
> include/configs. Some actually do "setenv bootargs
> console=ttymxc0,${baudrate}" before their various boot commands.
> 
> If you prefer a more specific comment, maybe "Workaround lack of
> baudrate included with console on various iMX systems (e.g. wandboard,
> cubox-i, hummingboard)." An exhaustive list might prove more trouble
> than it's worth. :)

For sure!

I was thinking about this some more and it occurred to me that
console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
inheriting the existing baud rate etc settings from the bootloader and
Just Work(tm).

That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
the kernel which is called if no options are given.

That code has been there since the beginning of git history. Did you try
with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
question, I think many people don't realise the baud etc is optional so
it never gets tried).

If you've tried without and it doesn't work then either that code isn't
called when I think, or it is broken. In either case I'm not too
inclined to investigate further than "does console=ttymxc0 work" and if
not then apply that bit of the patch.

(I'm going to apply the other two aspects now)

Ian.


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

Bug#787975: Scratchpad (JavaScript console) does not run scripts.

[christina_c]

 

Package: iceweasel 

Version: 38.0.1-5
Severity: normal 

Subject: iceweasel: Scratchpad (JavaScript console) does not run
scripts.

Dear Maintainer,

"Inspect" and "Display" also don't work. No error message, no log on the
console. Example:
alert("Scratchpad Test");
The Web Console command line works. Deleting the folder .mozilla in my
home directory also didn't help.

-- Package-specific info:

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

Name: Deutsch (DE) Language Pack locale
Location:
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-de
Status: enabled

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

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.5.2 (1.5.2-1.1))
Location:
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-7-plugin:amd64
Status: enabled

-- Addons package information
ii icedtea-7-plug 1.5.2-1.1 amd64 web browser plugin based on OpenJ
ii iceweasel 38.0.1-5 amd64 Web browser based on Firefox
ii iceweasel-l10n 1:38.0.1-5 all German language package for Icewe
ii xul-ext-debian 1.11-1 all Buttons for querying Debian-relat

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 iceweasel depends on:
ii debianutils 4.5.1
ii fontconfig 2.11.0-6.3
ii libasound2 1.0.28-1
ii libatk1.0-0 2.16.0-2
ii libc6 2.19-18
ii libcairo2 1.14.2-2
ii libdbus-1-3 1.8.18-1
ii libdbus-glib-1-2 0.102-1
ii libevent-2.0-5 2.0.21-stable-2
ii libffi6 3.1-2+b2
ii libfontconfig1 2.11.0-6.3
ii libfreetype6 2.5.2-4
ii libgcc1 1:5.1.1-8
ii libgdk-pixbuf2.0-0 2.31.4-2
ii libglib2.0-0 2.44.1-1
ii libgtk2.0-0 2.24.25-3
ii libhunspell-1.3-0 1.3.3-3
ii libnspr4 2:4.10.8-2
ii libnss3 2:3.19-1
ii libpango-1.0-0 1.36.8-3
ii libsqlite3-0 3.8.10.2-1
ii libstartup-notification0 0.12-4
ii libstdc++6 5.1.1-8
ii libvpx2 1.4.0-3
ii libx11-6 2:1.6.3-1
ii libxcomposite1 1:0.4.4-1
ii libxdamage1 1:1.1.4-2+b1
ii libxext6 2:1.3.3-1
ii libxfixes3 1:5.0.1-2+b2
ii libxrender1 1:0.9.8-1+b1
ii libxt6 1:1.1.4-1+b1
ii procps 2:3.3.9-9
ii zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii gstreamer1.0-libav 1.4.4-2
ii gstreamer1.0-plugins-good 1.4.5-2+b1

Versions of packages iceweasel suggests:
pn fonts-mathjax 
pn fonts-oflb-asana-math 
pn fonts-stix | otf-stix 
ii libcanberra0 0.30-2.1
pn libgnomeui-0 
ii libgssapi-krb5-2 1.12.1+dfsg-20
pn mozplugger 

-- no debconf information 

 

Bug#786657: apache2.4 in jessie/stable missing mod_imagemap

[Jean-Michel Vourgère]

Control: tags -1 moreinfo

On May 24th 2015, Steven Sumichrast wrote:
> In Wheezy 7.8 mod_imagemap was shipped with the apache2.2-bin package (
> https://packages.debian.org/wheezy/amd64/apache2.2-bin/filelist).  It
> appears that in the new stable system, apache2.4-bin is missing
> mod_imagemap (https://packages.debian.org/jessie/amd64/apache2-bin/filelist).
> I'm not aware of the module being renamed.
> 
> Additionally the module is not available for install via a standalone
> package.

Hello

Upstream decided to disable this module by default.

The main argument, as far as I can tell, is that the client side image
maps have been added in HTML 2.0 (Netscape version 1.4, circa 1992) and
this is totally obsolete on the server side.

The module code is still available upstream, it was just disabled, and
it is theoretically possible to add it back in Debian. But isn't it best
to stick to upstream decisions?

Do you really need that module or was that just a configuration error on
upgrade?

-- 
Nirgal


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

Bug#787960: libcurl3-gnutls: breaks bti

[Alessandro Ghedini]

On dom, giu 07, 2015 at 12:21:15 +0200, Vincent Lefevre wrote:
> Control: retitle -1 no longer works with https - breaks bti and curl
> 
> On 2015-06-07 00:16:15 +0200, Vincent Lefevre wrote:
> > After the upgrade to libcurl3-gnutls 7.42.1-2+b1, bti no longer works
> > at all. For instance:
> [...]
> 
> It also breaks curl:
> 
> $ curl https://www.vinc17.net/
> curl: (60) server certificate verification failed. CAfile: 
> /etc/ssl/certs/ca-certificates.crt CRLfile: none
> More details here: http://curl.haxx.se/docs/sslcerts.html

I can't reproduce any of this. Can you please run the command above with the
"-v" option and post the output? Also, what's the content of the file
/etc/ssl/certs/ca-certificates.crt?

Cheers


signature.asc
Description: Digital signature

Bug#783074: flash-kernel: improvements to uboot-generic bootscript

[Ian Campbell]

On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
> >> The kernel versioning its also make it possible to use a kernel without
> >> relying on the various vmlinuz, initrd, dtb smlinks being valid, or for
> >> troubleshooting an alternate version.
> >
> > What do you think about wrapping the load in a "for kver in -${kvers '';
> > do" and loading e.g. ${prefix}vmlinuz${kver}. IOW making it so that it
> > will try the suffixed version first but fallback to the symlinks if that
> > fails?
> 
> I like the idea, but the for loop implementation seems to ignore '', "",
> ' ' or " " in the loop... I'm not sure how to get it to respect an empty
> value.

In the end I'm going to go with just duplicating the entire block with
and without the kvers, which is a bit unsatisfactory but the best I
could manage with the syntax available.

I'm also planning to use:
if test -n "${fk_kvers}"; then
   fk_kvers='@@KERNEL_VERSION@@'
fi
(and then fk_kvers throughout)

Which should allow for a very rudimentary form of picking which kernel
you wanted by "setenv fk_kvers FOO; boot" (e.g. to boot older versions
in an emergency).

Ian.


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

Bug#784169: rhythmbox is broken after upgrade from wheezy to jessie, fails to play.

[Peter Roozemaal]

On 06/01/2015 05:40 AM, Michael Biebl wrote:
> Am 03.05.2015 um 20:35 schrieb MathFox:
> 
>> Dear Maintainer,
>>
>> Under wheezy I used rhythmbox for playing music. After upgrading to jessie
>> rhythmbox stopped playing music; at startup it shows "speaker muted" and 
>> after
>> pressing play it ends up in "paused" state without a way of getting out of 
>> it.
>> After quitting (closing the window) a rhythmbox process remains running.
> 
> ..
> 
>> pn  gstreamer1.0-pulseaudio
> 
> Can you try with pulseaudio and gstreamer1.0-pulseaudio installed?
> If you start rhythmbox on the console, do you get any output?
> If you use totem to play the audio file, does it work?
> 
Starring rhythmbox from the console gives error messages "can't open
display".

Note: the following tests are done after a kernel update, installing
pulseaudio and totem and a reboot.

Running rhythmbox from a terminal gives the following messages

(rhythmbox:1282): Gtk-WARNING **: Failed to register client:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files

(rhythmbox:1282): Rhythmbox-WARNING **: Could not load MPID typelib:
Typelib file for namespace 'MPID', version '3.0' not found

(rhythmbox:1282): Rhythmbox-WARNING **: Could not load RB typelib:
Typelib file for namespace 'RB', version '3.0' not found

(rhythmbox:1282): Rhythmbox-WARNING **: Could not load Peas typelib:
Typelib file for namespace 'Peas', version '1.0' not found

(rhythmbox:1282): Rhythmbox-WARNING **: Could not load PeasGtk typelib:
Typelib file for namespace 'PeasGtk', version '1.0' not found

(rhythmbox:1282): Gtk-WARNING **: Duplicate child name in GtkStack: Add
to Playlist


(rhythmbox:1282): Gtk-WARNING **: Duplicate child name in GtkStack: Add
to Playlist


(rhythmbox:1282): Gtk-WARNING **: Duplicate child name in GtkStack: Add
to Playlist


(rhythmbox:1282): Gtk-WARNING **: Duplicate child name in GtkStack: Add
to Playlist


(rhythmbox:1282): Gtk-WARNING **: Duplicate child name in GtkStack: Add
to Playlist

^C

(This is in a session that gives ~20 seconds of music till it stops
after adjusting the volume.)

Don't hear anything from totem after that too...

Greetings,

Peter.


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

Bug#783074: flash-kernel: improvements to uboot-generic bootscript

[Ian Campbell]

On Sun, 2015-06-07 at 10:27 +0100, Ian Campbell wrote:
> On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
> > > The changelog says "some imx systems", do you have a list I could drop
> > > in a comment or should I just say "#Workaround lack of console on
> > > someIMX systems"?
> > 
> > I can confirm that wandboard, cubox-i and hummingboard all default to
> > console=ttymxc0, and several other boards by grepping through u-boot's
> > include/configs. Some actually do "setenv bootargs
> > console=ttymxc0,${baudrate}" before their various boot commands.
> > 
> > If you prefer a more specific comment, maybe "Workaround lack of
> > baudrate included with console on various iMX systems (e.g. wandboard,
> > cubox-i, hummingboard)." An exhaustive list might prove more trouble
> > than it's worth. :)
> 
> For sure!
> 
> I was thinking about this some more and it occurred to me that
> console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
> inheriting the existing baud rate etc settings from the bootloader and
> Just Work(tm).
> 
> That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
> the kernel which is called if no options are given.
> 
> That code has been there since the beginning of git history. Did you try
> with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
> question, I think many people don't realise the baud etc is optional so
> it never gets tried).
> 
> If you've tried without and it doesn't work then either that code isn't
> called when I think, or it is broken. In either case I'm not too
> inclined to investigate further than "does console=ttymxc0 work" and if
> not then apply that bit of the patch.

Actually, the way you've structured the conditions it's utterly harmless
even if it turns out not to be needed, so I committed this bit too.

Ian.


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

Bug#787976: grilo-plugins-0.2: grilo-plugins crashes in video_sanitize_string

[Eugenio Accorsi]

Package: grilo-plugins-0.2
Version: 0.2.14-2
Severity: important
Tags: patch

Dear Maintainer,

grilo plugins crashes taking totem down with it (it depends on some file name I
think)
Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=748604

I rebuilded the package using the 4 patches in the bugreport and grilo don't
crash anymore.

Backtrace:
#0  video_sanitise_string (str=) at grl-local-metadata.c:277
#1  video_display_name_to_metadata (display_name=) at grl-local-
metadata.c:309
#2  video_guess_values_from_display_name (episode=,
season=, date=, showname=,
title=, display_name=) at grl-local-
metadata.c:327
#3  resolve_video (source=, rs=, flags=, key=) at grl-local-metadata.c:678
#4  grl_local_metadata_source_resolve (source=0x57620700,
rs=0x57da8130) at grl-local-metadata.c:1053
#5  0x72fc4612 in ?? () from /usr/lib/x86_64-linux-
gnu/libgrilo-0.2.so.1
#6  0x70638b4d in g_main_context_dispatch () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#7  0x70638f20 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x70638fcc in g_main_context_iteration () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#9  0x72fc101d in grl_wait_for_async_operation_complete () from
/usr/lib/x86_64-linux-gnu/libgrilo-0.2.so.1
#10 0x72fc5978 in grl_source_resolve_sync () from /usr/lib/x86_64
-linux-gnu/libgrilo-0.2.so.1
#11 0x77b9be14 in ?? () from /usr/lib/libtotem.so.0
#12 0x77b9c215 in ?? () from /usr/lib/libtotem.so.0
#13 0x72fc1fb7 in ?? () from /usr/lib/x86_64-linux-
gnu/libgrilo-0.2.so.1
#14 0x70638b4d in g_main_context_dispatch () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#15 0x70638f20 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x70638fcc in g_main_context_iteration () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#17 0x70bfa67c in g_application_run () from /usr/lib/x86_64-linux-
gnu/libgio-2.0.so.0
#18 0x650b in main ()



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

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

Versions of packages grilo-plugins-0.2 depends on:
ii  libarchive13 3.1.2-11
ii  libavahi-client3 0.6.31-5
ii  libavahi-common3 0.6.31-5
ii  libavahi-glib1   0.6.31-5
ii  libavahi-gobject00.6.31-5
ii  libc62.19-18
ii  libdmapsharing-3.0-2 2.9.30-1
ii  libgdata19   0.16.1-1
ii  libglib2.0-0 2.44.1-1
ii  libgmime-2.6-0   2.6.20-1+b1
ii  libgoa-1.0-0b3.16.2-1
ii  libgrilo-0.2-1   0.2.12-2
ii  libgstreamer1.0-01.4.5-2
ii  libjson-glib-1.0-0   1.0.4-1
ii  liblua5.2-0  5.2.3-1.1
ii  libmediaart-2.0-01.9.0-2
ii  liboauth01.0.1-1
ii  librest-0.7-00.7.93-1
ii  libsoup2.4-1 2.50.0-2
ii  libsqlite3-0 3.8.10.2-1
ii  libtotem-plparser18  3.10.3-1
ii  libtracker-sparql-1.0-0  1.4.0-3
ii  libxml2  2.9.1+dfsg1-5

Versions of packages grilo-plugins-0.2 recommends:
ii  dleyna-server  0.4.0-1

grilo-plugins-0.2 suggests no packages.
>From a05b159c330a7a65479bba35bc529d0934640627 Mon Sep 17 00:00:00 2001
From: "Jan Alexander Steffens (heftig)" 
Date: Tue, 19 May 2015 20:53:28 +0200
Subject: [PATCH 2/2] local-metadata: Fixes to video_sanitise_string non-alnum
 handling

- Extract loop condition into a helper function
- Use g_utf8_get_char to properly convert to unichar
- Be more defensive about g_utf8_find_prev_char returning NULL

https://bugzilla.gnome.org/show_bug.cgi?id=748604
---
 src/local-metadata/grl-local-metadata.c | 39 +++--
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/src/local-metadata/grl-local-metadata.c b/src/local-metadata/grl-local-metadata.c
index 45856be..c7f731e 100644
--- a/src/local-metadata/grl-local-metadata.c
+++ b/src/local-metadata/grl-local-metadata.c
@@ -242,6 +242,28 @@ grl_local_metadata_source_set_property (GObject  *object,
 
 /* === Utilities  */
 
+static gboolean
+is_nonalnum (const gchar *str)
+{
+  gunichar uchar;
+
+  if (str == NULL) {
+return FALSE;
+  }
+
+  uchar = g_utf8_get_char (str);
+
+  if (g_unichar_isalnum (uchar)) {
+return FALSE;
+  }
+
+  if (uchar == '!' || uchar == '?' || uchar == '.') {
+return FALSE;
+  }
+
+  return TRUE;
+}
+
 static gchar *
 video_sanitise_string (const gchar *str)
 {
@@ -270,22 +292,17 @@ video_sanitise_string (const gchar *str)
   }
 
   if (*line_end != '\0') {
-line_end = g_utf8_find_prev_char (line, line_end);
-
+/* After removing substring with blacklisted word, ignore non alpha-numeric
+

Bug#787977: ITP: smrtanalysis -- software suite for single molecule, real-time sequencing

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: smrtanalysis
   Version : 2.3.0
   Upstream Author : Pacific Biosciences 
* URL : http://pacbiodevnet.com
* License : BSD
   Programming Lang: C++, Python, R
   Description : software suite for single molecule, real-time 
sequencing


  SMRT® Analysis is a powerful, open-source bioinformatics software suite
  available for analysis of DNA sequencing data from Pacific Biosciences’
  SMRT technology.
  .
  Users can choose from a variety of analysis protocols that utilize 
PacBio®
  and third-party tools. Analysis protocols include de novo genome 
assembly,
  cDNA mapping, DNA base-modification detection, and long-amplicon 
analysis to

  determine phased consensus sequences.


This is intended as a metapackage to depend on all the components of
SMRTAnalysis, which are managed in separate SCM repositories at
. It will be maintained by
the Debian Med team at
http://anonscm.debian.org/cgit/debian-med/smrtanalysis.git

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


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

Bug#787978: RM: elinks-lite -- ROM; remove obsolete transition package

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove the binary package elinks-lite 0.12~pre6-5 from sid.
It's a transition package which isn't necessary any longer now
that jessie has been removed.

Cheers,
Moritz


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

Bug#783914: please add Dračí Historie (freeware)

[Alexandre Detiste]

control: tag -1 +pending

The .ico file looks nice, it could be translated to .png
and included in src:game-data-packager ,
as this is GPL'ed stuff.


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

Bug#787979: FTBFS: build-dependency not installable: linux-source-3.16

[Jakub Wilk]

Source: user-mode-linux
Version: 3.16-1um-0.1
Severity: serious
Tags: stretch sid 

user-mode-linux cannot be built in unstable. It build-depends on 
linux-source-3.16, which no longer exists.


--
Jakub Wilk


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

Bug#784169: update

[Peter Roozemaal]

Additional info:

More debugging points to an unreliable SD card, which triggers more
errors with newer Linux kernels. (And recovery attempts from 3.16
kernels make matters worse.)
Totem runs fine with mp3's from other file systems than the SD card.

Peter.


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

Bug#787980: dpkg: please normalize file permissions when creating control.tar

[Jérémy Bobbio]

Package: dpkg
Version: 1.18.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask toolchain

Hi!

As part of the “reproducible builds” effort, we are curretly trying
to have Debian package build identically despite being built under
different umasks.

dpkg creates the control.tar member of .deb files using GNU Tar. It will
thus pick up the permissions of the files on the filesystem. For the
specific case of control files, there is a very limited set of
acceptable permissions. It seems desirable to enforce this by
normalizing the recorded permissions by giving the
`--mode=go=rX,u+rw,a-s` option to tar.

The attached patch is based on the available master branch. The change
is also part of the `pu/reproducible_builds` branch available at:
https://anonscm.debian.org/cgit/reproducible/dpkg.git/

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


signature.asc
Description: Digital signature

Bug#787981: ITP: python-pbcore -- Python library for processing Pacific Biosciences data, files

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-pbcore
  Version : 1.0.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbcore
* License : BSD
  Programming Lang: Python
  Description : Python library for processing Pacific Biosciences 
data files


The pbcore package provides Python modules for processing Pacific 
Biosciences

data files and building PacBio bioinformatics applications. These modules
include tools to read/write PacBio data formats, sample data files for
testing and debugging, base classes, and utilities for building 
bioinformatics applications.

.
This package is part of the SMRTAnalysis suite ( 
 )


Maintenance will be by the Debian Med team at
Vcs-Git: git://anonscm.debian.org/debian-med/python-pbcore.git
Vcs-Browser: http://anonscm.debian.org/cgit/debian-med/python-pbcore.git

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


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

Bug#787982: ITP: python-pbh5tools -- tools for manipulating HDF5 files produced by, Pacific Biosciences sequencing instruments

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-pbh5tools
  Version : 0.8.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbh5tools
* License : BSD
  Programming Lang: Python
  Description : tools for manipulating HDF5 files produced by 
Pacific Biosciences sequencing instruments


This package provides functionality for manipulating and extracting data
from cmp.h5 and bas.h5 files produced by the Pacific Biosciences sequencers.
cmp.h5 files contain alignment information while bas.h5 files contain
base-call information.
.
This package is part of the SMRTAnalysis suite (
 )


Maintenance will be by the Debian Med team at
Vcs-Git: git://anonscm.debian.org/debian-med/python-pbh5tools.git
Vcs-Browser: http://anonscm.debian.org/cgit/debian-med/python-pbh5tools.git

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


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

Bug#785297: bug 785297 is forwarded to https://github.com/tatsuhiro-t/aria2/issues/346, tagging 785297

[Andreas Metzler]

On 2015-06-06 Magnus Holmgren  wrote:
> torsdagen den 4 juni 2015 19.03.50 skrev  Andreas Metzler:
>> Find attached a minimal patch for the debian package to include the
>> upstream fix.

> Do you want to do the NMU, with an appropriate delay, since you've already 
> posted the diff?

Hello,

Looks like wasted effort, the aria2 git repo shows activity:

+aria2 (1.19.0-1) unstable; urgency=medium
+
+  * New upstream release:
++ Fix FTBFS with linux-libc-dev 4.0.2-1 (Closes: #785294)
+
+ -- Kartik Mistry   Sat, 06 Jun 2015 23:37:00 +0200

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


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

Bug#766819: [pkg-cinnamon] Bug#766819: cinnamon freezes for a minute or so, when opening images or text with gnome/gtk apps and when closing them later on

[Fabio Fantoni]

Il 22/11/2014 22:57, Christoph Anton Mitterer ha scritto:
> Hey.
>
> Sorry for not having been very active here recently
>
> On Fri, 2014-11-21 at 20:20 +, Margarita Manterola wrote:
>> Have you been able to find out anything else regarding
>> the cinnamon vs afs bug?
> Well it does definitely still occur,... and as far as I can tell it in
> fact happens *always*, i.e. when AFS is active there's a tiny freeze in
> some GNOME programs.
> It's just that these very long freezes don't occur every time (in the
> sense of "for a given boot"), but I even saw those every now and then.
>
>
>> This seems to be something very specific to your setup,
>> so it would be really helpful if you can investigate a bit
>> further.
> Well that's a bit the problem,... there is not really much special about
> my AFS setup (actually it's everything at default)... and as I've said
> previously, the client was even deactivated until it got systemd ready
> and automagically re-activated itself.
>
>>   Particularly, it would be interesting if you can
>> verify if this happens on GNOME or not.
> I was only able to test it with GNOME classic, since Shell doesn't work
> here.
> There I've seen it as well... 
>
>
> I made some tests today, but right now I wasn't able to reproduce it,
> but as I've said, it comes and goes. 
>
>
>
> I guess this is not really a Cinnamon bug, but rather something in
> gtk/gvfs - since only apps with that seem to be affected.
>
> So perhaps the only bug in cinnamon is, that it somehow uses gvfs which
> can block the whole desktop - assuming my assumption is correct.
>
>
> Maybe we should reassign that to gvfs,... and perhaps wrt to
> systemd/openafs report a new bug, that afs client got automagically
> re-enabled, which it should not.
>
>
> Cheers,
> Chris.
>

Can someone test with cinnamon 2.6 if is it still reproducible please?





smime.p7s
Description: Firma crittografica S/MIME

Bug#763895: [pkg-cinnamon] Bug#763895: Bug#763895: cinnamon crashes when a window opens

[Fabio Fantoni]

Il 03/10/2014 18:31, Michal Suchanek ha scritto:
> Hello,
>
> thanks for your quick replies.
>
> Excerpts from Maximiliano Curia's message of Fri Oct 03 16:55:01 +0200 2014:
>> ¡Hola Michal!
>>
>> El 2014-10-03 a las 14:06 +, Michal Suchanek escribió:
>>> after finally running cinnamon I tried to open a terminal (evilvte) and
>>> cinnamon immediately crashed. I tried restarting it grom that fallback mode
>>> dialog but it crashed immediately again. Closing the terminal window allowed
>>> cinnamon to be restarted. I suspected evilvte is in some way truly evil and
>>> kills cinnamon but I created a new folder on the desktop, opened it, and
>>> cinnamon crashed again when the file manager window opened.
>> In the attached xsession-errors file I see a weird sequence of actions, and
>> I'm not sure if the output is mixed with some other session.
>> Can you please copy the file before trying to start a failing application?
> I attach a file befor and after crash.
>
> It seems metacity is used in fallback session and gnome panel is used
> also either in main or fallback session.
>
> Hence they run in the crashed session and without them cinnamon fails
> completely when an error occurs.
>
>> So we can see the output generated by the failing application (just the
>> difference pasted in paste.debian.org would be ideal).
>>
>>> Xsession: X session started for root at Fri Oct  3 14:00:41 UTC 2014
>> It's highly disrecommended to use a graphical session as root.
> I know about that. It however does not make any meaningful difference
> for single user system unless I were to create a separate user account
> for every application.
>
>>> W: [pulseaudio] main.c: This program is not intended to be run as root 
>>> (unless --system is specified).
>>> (cinnamon:2324): St-CRITICAL **: st_widget_get_theme_node called on the 
>>> widget [0xb9150658 StBoxLayout.menu-selected-app-box] which is not in the 
>>> stage.
>>>   JS LOG: Invalid network device type, is 14
>>> *WARN_ONCE*
>>> File ../../../../../../../src/mesa/drivers/dri/radeon/radeon_swtcl.c 
>>> function r100_swtcl_flush line 339
>>> Rendering was 1 commands larger than predicted size. We might overflow  
>>> command buffer.
>>> ***
>>> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. 
>>> See dmesg for more info.
>>> x-session-manager[2172]: WARNING: Application 'cinnamon.desktop' killed by 
>>> signal 15
>> I think the video driver you are using is dying when the composite manager
>> tries to start.
> It's dying at the time a window opens. Is starting a compositing manager
> delayed until that point?
>
> Either way, it looks like Mesa sends something unintelligible to the
> GPU.
>
> They talked about reworking and adding some new features to r100 so
> maybe there is an awesome new bug there.
>
>>>   JS LOG: About to start Cinnamon
>>>   JS LOG: Cinnamon started at Fri Oct 03 2014 14:01:01 GMT+ (UTC)
>>> (cinnamon:2421): St-CRITICAL **: st_widget_get_theme_node called on the 
>>> widget [0xba07c670 StBoxLayout.menu-selected-app-box] which is not in the 
>>> stage.
>>>   JS LOG: Invalid network device type, is 14
>>> drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. 
>>> See dmesg for more info.
>> Mmh, and it also dies in the fallback mode.
>>
>>> x-session-manager[2172]: WARNING: App 'cinnamon.desktop' respawning too 
>>> quickly
>>> x-session-manager[2172]: CRITICAL: We failed, but the fail whale is dead. 
>>> Sorry
>> That's the end of the cinnamon session.
>>
>>> (gnome-panel:2437): Gtk-CRITICAL **: gtk_accelerator_parse_with_keycode: 
>>> assertion 'accelerator != NULL' failed
>> I don't know why you are running gnome-panel, but that's not cinnamon 
>> related.
>> So, this seems to be another desktop environment session, did you start it or
>> was automatically started?
> It starts automagically when cinnamon fails.
>
>> Can you please let us know if you can use any composite window manager at 
>> all?
>>
> Presumably I am running a compositing manager because xcompmgr refuses
> to start on the excuse that a compositing manager is running.
>
> Is metacity doing compositing?
>
>> Also, there are no traces of evitvte or the file manager failing in this log.
>>
> They aren't really failing. They just open a window that makes cinnamon
> crash and keep running.
>
> The file manager is running anyway so there would be no trace of it in the 
> log.
>
> Thanks
>
> Michal
>

Can someone test with cinnamon 2.6 please? Cinnamon and muffin have
commits with fix/improvements probably related.



smime.p7s
Description: Firma crittografica S/MIME

Bug#765917: [pkg-cinnamon] Bug#765917: [cinnamon] task cinnamon:12709 blocked for more than 120 seconds.

[Fabio Fantoni]

Il 19/10/2014 10:46, Valentin Lorentz ha scritto:
> Package: cinnamon
> Version: 2.2.16-1
> Severity: important
>
> Hi,
>
> I wasn't doing anything in particular (I just opened a LibreOffice
> document), and then cinnamon froze. (I could still move the cursor and
> the music was still playing.)
> Using “killall -9 cinnamon” from a TTY had no effect (ie. cinnamon
> wasn't killed).
>
> I then killed cinnamon-session to be able to log in again, and after
> logging in, cinnamon did not start (empty screen with only the default
> Debian background).
>
> I also got this in the dmesg (note that sdc6 is a partition on my
> external hard disk, which has been disconnected for hours):
>
> [70943.796546] systemd-logind[31321]: New session c40 of user lightdm.
> [70949.123569] systemd-logind[31321]: New session 93 of user progval.
> [70949.506660] EXT4-fs warning (device sdc6): __ext4_read_dirblock:681:
> error reading directory block (ino 2, block 0)
> [70949.506970] EXT4-fs warning (device sdc6): __ext4_read_dirblock:681:
> error reading directory block (ino 2, block 0)
> [70949.507591] EXT4-fs warning (device sdc6): __ext4_read_dirblock:681:
> error reading directory block (ino 2, block 0)
> [70949.507620] EXT4-fs warning (device sdc6): __ext4_read_dirblock:681:
> error reading directory block (ino 2, block 0)
> [70949.507643] EXT4-fs warning (device sdc6): __ext4_read_dirblock:681:
> error reading directory block (ino 2, block 0)
> [70968.146315] INFO: task cinnamon:12709 blocked for more than 120 seconds.
> [70968.148151]   Tainted: G   O 3.14.4-amd64 #1
> [70968.149957] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [70968.151823] cinnamonD 8801d20d1178 0 12709  12706
> 0x0004
> [70968.151833]  8801d20d0d60 0086 00014340
> 00014340
> [70968.151841]  8800cc057fd8 8801d20d0d60 880003e5bda8
> 8801c4dba800
> [70968.151847]  8800cc057b40 880003e5be88 8801c4dba800
> 8800bd436d40
> [70968.151854] Call Trace:
> [70968.151880]  [] ? __fuse_request_send+0xb5/0x270 [fuse]
> [70968.151901]  [] ? prepare_to_wait_event+0xf0/0xf0
> [70968.151922]  [] ?
> fuse_dentry_revalidate+0x12d/0x300 [fuse]
> [70968.151934]  [] ? lookup_fast+0x25e/0x2b0
> [70968.151946]  [] ? link_path_walk+0x1a3/0x840
> [70968.151957]  [] ? d_rehash+0x15/0x20
> [70968.151974]  [] ? path_lookupat+0x56/0x790
> [70968.151987]  [] ? do_wp_page+0x39e/0x7e0
> [70968.151999]  [] ? complete_walk+0x42/0xd0
> [70968.152009]  [] ? filename_lookup+0x21/0xc0
> [70968.152025]  [] ? user_path_at_empty+0x4f/0x90
> [70968.152031]  [] ? from_kgid_munged+0x9/0x20
> [70968.152040]  [] ? cp_new_stat+0x135/0x150
> [70968.152048]  [] ? vfs_fstatat+0x41/0x90
> [70968.152055]  [] ? SYSC_newlstat+0x1d/0x40
> [70968.152061]  [] ? system_call_fastpath+0x16/0x1b

Can someone test with cinnamon 2.6 if is it still reproducible please?


>
>
> --- System information. ---
> Architecture: amd64
> Kernel: Linux 3.14.4-amd64
>
> Debian Release: jessie/sid
> 800 testing ftp.fr.debian.org
>
> --- Package information. ---
> Depends (Version) | Installed
> ==-+-==
>
> caribou | 0.4.15-1
> cinnamon-common (= 2.2.14-3) | 2.2.16-1
> cinnamon-control-center (>= 2.2) | 2.2.11-3
> cinnamon-desktop-data (>= 2.2) | 2.2.3-2
> cinnamon-screensaver (>= 2.2) | 2.2.4-5+b1
> cinnamon-session (>= 2.2) | 2.2.2-4
> cinnamon-settings-daemon (>= 2.2) | 2.2.4.repack-6
> cjs (>= 2.2) | 2.2.2-2
> cups-pk-helper | 0.2.5-2
> gir1.2-accountsservice-1.0 | 0.6.37-3+b1
> gir1.2-caribou-1.0 | 0.4.15-1
> gir1.2-clutter-1.0 | 1.20.0-1
> gir1.2-cogl-1.0 | 1.18.2-2
> gir1.2-gconf-2.0 | 3.2.6-3
> gir1.2-gdkpixbuf-2.0 | 2.30.8-1+b1
> gir1.2-gkbd-3.0 | 3.6.0-1
> gir1.2-glib-2.0 | 1.42.0-2
> gir1.2-cmenu-3.0 | 2.2.0-3
> gir1.2-nmgtk-1.0 | 0.9.10.0-2
> gir1.2-gnomebluetooth-1.0 | 3.14.0-1
> gir1.2-gnomedesktop-3.0 | 3.14.0-1
> gir1.2-gtk-3.0 | 3.14.1-1
> gir1.2-gtkclutter-1.0 | 1.6.0-1
> gir1.2-javascriptcoregtk-3.0 | 2.4.6-1
> gir1.2-networkmanager-1.0 | 0.9.10.0-3
> gir1.2-pango-1.0 | 1.36.8-2
> gir1.2-polkit-1.0 | 0.105-7
> gir1.2-soup-2.4 | 2.48.0-1
> gir1.2-upowerglib-1.0 | 0.99.1-3
> gir1.2-webkit-3.0 | 2.4.6-1
> gkbd-capplet | 3.6.0-1
> gnome-icon-theme-symbolic (>= 2.91) | 3.12.0-1
> gnome-session-bin | 3.14.0-2
> gnome-settings-daemon (>= 2.91.5.1) | 3.14.0-2
> gsettings-desktop-schemas (>= 0.1.7) | 3.14.0-1
> libjs-jquery | 1.7.2+dfsg-3.2
> mesa-utils | 8.2.0-1
> nemo (>= 2.2) | 2.2.4-2
> network-manager-gnome | 0.9.10.0-2
> policykit-1-gnome | 0.105-2
> python-dbus | 1.2.0-2+b3
> python-gconf | 2.28.1+dfsg-1
> python-gi-cairo | 3.14.0-1
> python-imaging | 2.5.1-1
> python-lxml | 3.4.0-1
> python-pam | 0.4.2-13.1
> python-pexpect | 3.2-1
> python-pyinotify | 0.9.4-1
> gir1.2-meta-muffin-0.0 | 2.2.6-4
> dconf-gsettings-backend | 0.22.0-1
> OR gsettings-backend |
> python:any |
> libatk1.0-0 (>= 1.12.4) | 2.14.0-1
> libc6 (>= 2.

Bug#787983: kicad: Crash on save first time

[Sven Arvidsson]

Package: kicad
Version: 0.20141025+bzr4029-2
Severity: normal

Hi,

The first time I start kicad I get a reproducible segfault by simply
doing File → Save.

This only happens the first time, when there is no noname.pro file.

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

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

Versions of packages kicad depends on:
ii  kicad-common  0.20141025+bzr4029-2
ii  libc6 2.19-18
ii  libgcc1   1:5.1.1-7
ii  libgl1-mesa-glx [libgl1]  10.5.5-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libstdc++65.1.1-7
ii  libwxbase3.0-03.0.2-1+b1
ii  libwxgtk3.0-0 3.0.2-1+b1
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1

kicad recommends no packages.

Versions of packages kicad suggests:
pn  extra-xdg-menus  
pn  kicad-doc-en | kicad-doc-fr | kicad-doc-de | kicad-doc-es | kicad-d  

-- 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#787741: [empathy-skype] meta-contacts does not work with skype

[Alexander Kudrevatykh]

I can link two jabber contacts to one meta-contact, so I don't think
there is general problem with empathy.
When I try to link skype contact I see that some skype contact linked,
but with some UUID in it, and original contact have different UUID. If I
link it multiply times multiply contacts linked with different UUID's in
name.

On Fri, 05 Jun 2015 14:44:23 +0530 Ritesh Raj Sarraf  wrote:
> Package: empathy-skype
> Followup-For: Bug #787741
> 
> I think this is a generic problem with empathy. It does not seem to be
> allowing meta contact.
> 
> Just plain empathy, does it allow meta contact for you ?
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.0.4+ (SMP w/4 CPU cores)
> Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.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#780553: [pkg-cinnamon] Bug#780553: additional information

[Fabio Fantoni]

Il 16/03/2015 06:07, Andrew Assim ha scritto:
> I discovered the Software rendering mode of cinnamon does not have the
> same problem. With software rendering, cinnamon is using 260% of the CPU
> and system is not very usable. 

I did a fast test with cinnamon 2.6 and I was unable to reproduce it but
I not tried in fallback mode (software rendering).

Can someone test with cinnamon 2.6 if is it still reproducible please?

>
> 00:02.0 VGA compatible controller: Intel Corporation Core Processor
> Integrated Graphics Controller (rev 02)
>
> modinfo i915:
>
> filename:   
> /lib/modules/3.16.0-4-amd64/kernel/drivers/gpu/drm/i915/i915.ko
> license:GPL and additional rights
> description:Intel Graphics
> author: Tungsten Graphics, Inc.
> depends:drm_kms_helper,drm,i2c-core,video,button,i2c-algo-bit
> intree: Y
> vermagic:   3.16.0-4-amd64 SMP mod_unload modversions 
> parm:   modeset:Use kernel modesetting [KMS] (0=DRM_I915_KMS
> from .config, 1=on, -1=force vga console preference [default]) (int)
> parm:   panel_ignore_lid:Override lid status (0=autodetect,
> 1=autodetect disabled [default], -1=force lid closed, -2=force lid open)
> (int)
> parm:   powersave:Enable powersavings, fbc, downclocking, etc.
> (default: true) (int)
> parm:   semaphores:Use semaphores for inter-ring sync (default:
> -1 (use per-chip defaults)) (int)
> parm:   enable_rc6:Enable power-saving render C-state 6.
> Different stages can be selected via bitmask values (0 = disable; 1 =
> enable rc6; 2 = enable deep rc6; 4 = enable deepest rc6). For example, 3
> would enable rc6 and deep rc6, and 7 would enable everything. default:
> -1 (use per-chip default) (int)
> parm:   enable_fbc:Enable frame buffer compression for power
> savings (default: -1 (use per-chip default)) (int)
> parm:   lvds_downclock:Use panel (LVDS/eDP) downclocking for
> power savings (default: false) (int)
> parm:   lvds_channel_mode:Specify LVDS channel mode (0=probe
> BIOS [default], 1=single-channel, 2=dual-channel) (int)
> parm:   lvds_use_ssc:Use Spread Spectrum Clock with panels
> [LVDS/eDP] (default: auto from VBT) (int)
> parm:   vbt_sdvo_panel_type:Override/Ignore selection of SDVO
> panel mode in the VBT (-2=ignore, -1=auto [default], index in VBT BIOS
> table) (int)
> parm:   reset:Attempt GPU resets (default: true) (bool)
> parm:   enable_hangcheck:Periodically check GPU activity for
> detecting hangs. WARNING: Disabling this can cause system wide hangs.
> (default: true) (bool)
> parm:   enable_ppgtt:Override PPGTT usage. (-1=auto [default],
> 0=disabled, 1=aliasing, 2=full) (int)
> parm:   enable_psr:Enable PSR (default: false) (int)
> parm:   preliminary_hw_support:Enable preliminary hardware
> support. (int)
> parm:   disable_power_well:Disable the power well when possible
> (default: true) (int)
> parm:   enable_ips:Enable IPS (default: true) (int)
> parm:   fastboot:Try to skip unnecessary mode sets at boot time
> (default: false) (bool)
> parm:   prefault_disable:Disable page prefaulting for
> pread/pwrite/reloc (default:false). For developers only. (bool)
> parm:   invert_brightness:Invert backlight brightness (-1 force
> normal, 0 machine defaults, 1 force inversion), please report PCI device
> ID, subsystem vendor and subsystem device ID to
> dri-de...@lists.freedesktop.org, if your machine needs it. It will then
> be included in an upcoming module version. (int)
> parm:   disable_display:Disable display (default: false) (bool)
> parm:   disable_vtd_wa:Disable all VT-d workarounds (default:
> false) (bool)
> parm:   enable_cmd_parser:Enable command parsing (1=enabled
> [default], 0=disabled) (int)
>
> https://lists.alioth.debian.org/mailman/listinfo/pkg-cinnamon-team
> to unsubscribe: 
> mailto:pkg-cinnamon-team-requ...@lists.alioth.debian.org?subject=unsubscribe
>
>
>




smime.p7s
Description: Firma crittografica S/MIME

Bug#787984: brickos: please make the build reproducible

[Maria Valentina Marin]

Source: brickos
Version: 0.9.0.dfsg-10
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi,

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

The attached patch removes $datetime from the file footer-no-sf.htm.
Once applied the binary package brickos-doc can be built reproducibly in
our current experimental framework. The binary package brickos though is
still unreproducible.

Please also consider forwarding this patch upstream.

Thanks!
akira

 [1]: https://wiki.debian.org/ReproducibleBuilds
Description: Remove $datetime from file footer-no-sf.htm to make package reproducible

--- brickos-0.9.0.dfsg.orig/doc/html/footer-no-sf.htm
+++ brickos-0.9.0.dfsg/doc/html/footer-no-sf.htm
@@ -10,7 +10,7 @@
 
 
 
-Generated on $datetime for $projectname by http://www.doxygen.org/index.html";>
+Generated for $projectname by http://www.doxygen.org/index.html";>
 
  $doxygenversion
 

Bug#768073: status request

[Geert Stappers]

Hello,

What is the status of the ITP of "lxd -- The Linux Container Daemon"?

At https://linuxcontainers.org/lxd/downloads/ I couldn't find
the Ubuntu packaging stuff.


Groeten
Geert Stappers
-- 
$ host people.progress-technologies.net
Host people.progress-technologies.net not found: 3(NXDOMAIN)


signature.asc
Description: Digital signature

Bug#787884: dictionaries-common: Emacs integration needs updating for 24.4

[Reuben Thomas]

​Thanks very much for both the work you've put in, and the explanation.​


-- 
http://rrt.sc3d.org

Bug#774149: Is there a workaround for the Can't mount ntfs drive (Transport endpoint is not connected)

[shirish शिरीष]

Hi all,
I just got hit by few days back, got time and was able to track it down :-

Before insertion of the external hdd

[$] ls -la /media

total 48
drwxr-xr-x  12 root root 4096 Jun  7 11:34 .
drwxr-xr-x  25 root root 4096 Jun  6 21:51 ..
lrwxrwxrwx   1 root root6 Jul 25  2013 cdrom -> cdrom0
drwxr-xr-x   2 root root 4096 Jul 25  2013 cdrom0
drwxr-x---+  3 root root 4096 Jun  6 11:15 shirish
lrwxrwxrwx   1 root root4 Jun  7 11:34 usb -> usb0
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb0
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb1
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb2
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb3
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb4
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb5
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb6
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb7

After insertion of the external hdd :-

[$] ls -la /media

ls: cannot access /media/usb0: Transport endpoint is not connected
total 44
drwxr-xr-x  12 root root 4096 Jun  7 11:34 .
drwxr-xr-x  25 root root 4096 Jun  6 21:51 ..
lrwxrwxrwx   1 root root6 Jul 25  2013 cdrom -> cdrom0
drwxr-xr-x   2 root root 4096 Jul 25  2013 cdrom0
drwxr-x---+  3 root root 4096 Jun  6 11:15 shirish
lrwxrwxrwx   1 root root4 Jun  7 11:34 usb -> usb0
d??  ? ??   ?? usb0
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb1
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb2
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb3
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb4
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb5
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb6
drwxr-xr-x   2 root root 4096 Jun  7 11:34 usb7

I did two changes in the usbmount.conf file.

[$] cat /etc/usbmount/usbmount.conf | grep fuseblk
FILESYSTEMS="vfat ext2 ext3 ext4 hfsplus ntfs fuseblk"

probably ntfs wasn't necessary but don't know hence keeping it there
till somebody tells me otherwise.

[$] cat /etc/usbmount/usbmount.conf | grep VERBOSE
VERBOSE=yes

I do  not understand if the following error is because of usbmount or
some other package.

[$] usbhid-dump

libusb: error [_get_usbfs_fd] libusb couldn't open USB device
/dev/bus/usb/005/007: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
Failed to find and open the devices: Access denied (insufficient
permissions) (ERROR_ACCESS)

I did read the last message as well, what does that mean ? I have both
usbdisk2 as well as usbmount.

Would removing/purging usbmount bring back the how external  hdd
automount or does it go deeper ?

Also I have both usbmount as well as udisks2 installed. Could that be
an issue? usbmount can easily be purged , usbdisks2 takes another few
softwares with it


Look forward to knowing what is best to do in the current situation
till the above issue is resolved to everyone's interests .

I did a post of the same at
http://forums.debian.net/viewtopic.php?f=5&t=122679 and a user kiyop
did share a workaround I knew but was not remembering the switches for
it (basically manually mounting it as root).

It does have the disadvantage that it doesn't show up in nautilus
unless you open nautilus as root ( know it's a bad bad idea) so have
to severe connection to the net when doing that way.

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


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

Bug#784041: torbrowser-launcher: Bug prevails in 0.1.9-1+deb8u1

[Alexandre D.]

Package: torbrowser-launcher
Version: 0.1.9-1+deb8u1
Followup-For: Bug #784041

Dear Maintainer,

I upgraded to 0.1.9-1+deb8u1 but still have the same problem. Please see the 
output below.

Regards
Alexandre


$ torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.1.9
https://github.com/micahflee/torbrowser-launcher
Initializing Tor Browser Launcher
Importing keys
gpg: key 63FEE659: "Erinn Clark " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
gpg: key 93298290: "Tor Browser Developers (signing key) 
" not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
Starting launcher dialog
LATEST VERSION 4.5.1
Checked for update within 24 hours, skipping
TBB is not installed, attempting to install 4.5.1
Running task: download_sha256
Downloading https://www.torproject.org/dist/torbrowser/4.5.1/sha256sums.txt
Updating over Tor
Finished receiving body: Response body fully received
Running task: download_sha256_sig
Downloading https://www.torproject.org/dist/torbrowser/4.5.1/sha256sums.txt.asc
Updating over Tor
Finished receiving body: Response body fully received
Running task: download_tarball
Downloading 
https://www.torproject.org/dist/torbrowser/4.5.1/tor-browser-linux64-4.5.1_en-US.tar.xz
Updating over Tor
Finished receiving body: Response body fully received
Running task: verify
Verifying signature
gpg: assuming signed data in 
`/home/x/.cache/torbrowser/download/sha256sums.txt'
gpg: Signature made Mon 11 May 2015 16:57:21 CEST using RSA key ID D40814E0
gpg: Good signature from "Tor Browser Developers (signing key) 
"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
 Subkey fingerprint: BA1E E421 BBB4 5263 180E  1FC7 2E1A C68E D408 14E0
Running task: extract
Extracting tor-browser-linux64-4.5.1_en-US.tar.xz
Running task: run
Running 
/home/x/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/start-tor-browser
Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 911, 
in dispatcher
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 1462, 
in _finishResponse_WAITING
self._giveUp(Failure(reason))
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 1515, 
in _giveUp
self._disconnectParser(reason)
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 1503, 
in _disconnectParser
parser.connectionLost(reason)
---  ---
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 532, 
in connectionLost
self.response._bodyDataFinished()
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 911, 
in dispatcher
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/twisted/web/_newclient.py", line 1154, 
in _bodyDataFinished_CONNECTED
self._bodyProtocol.connectionLost(reason)
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
378, in connectionLost
self.all_done(reason)
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
395, in response_finished
self.run_task()
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
332, in run_task
self.verify()
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
565, in verify
self.run_task()
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
336, in run_task
self.extract()
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
609, in extract
self.run_task()
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
340, in run_task
self.run()
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/launcher.py", line 
640, in run
subprocess.call([self.common.paths['tbb']['start']])
  File "/usr/lib/python2.7/subprocess.py", line 522, in call
return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
raise child_exception
exceptions.OSError: [Errno 2] No such file or directory


-- System Information:
Debian Release: 8.1
  Architecture: amd64 (x86_64)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages torbrowser-launcher depends on:
ii  gnupg1.4.18-7
ii  python   2.7.9-1
ii  python-gtk2  2.24.0-4
ii  python-lzma  0.5.3-2+b1
ii  python-parsley   1.2-1
ii  python-psutil2.1.1-1+b1
ii  python-twisted   14.0.2-3
ii  python-txsocksx  1.13.0.3-1
ii  tor  0.2.5.12-1
ii  wmctrl   1.07-7

torbrowser-launcher recommends no packages.

Bug#787259: Acknowledgement (start error with pbuilder-satisfydepends-gdebi)

[Mattia Rizzolo]

Control: severity -1 important


On Sun, May 31, 2015 at 3:34 PM, Jörg Frings-Fürst
 wrote:
> The output of "sudo DIST=vivid pbuilder --update && DIST=vivid pdebuild | tee
> ../update_build_with_PBUILDERSATISFYDEPENDSCMD.log"
> ist attached.

there is not the --update bits.
And here the aptitude resolver just works (after the --update, since i
don't use that one usually)

> The results of all important values described in the wiki are faulty.

sorry, not sure i understand this sentence...

> So I sat back the severity to grave.

grave means "makes the package in question unusable or mostly so, or
causes data loss, or introduces a security hole allowing access to the
accounts of users who use the package.".
This is not since pbuilder ships other resolvers, just use one of them
until the bug gets fixed. Or is there a particular reason why you want
to use the gdebi one?




-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


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

Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0

[Fabian Greffrath]

Hi Bernhard et al.,

Am Samstag, den 06.06.2015, 14:59 +0200 schrieb Bernhard Übelacker: 
> Hello Fabian,
> after some more searching and testing here is my "opinion" on this issue:

thank you for your analysis of the issue. However, I think I have come
up with a simpler fix meanwhile: By declaring the affected variables as
"static" I make sure they are allocated at build time (well, sort of)
with proper alignment instead of at run-time within an unknown FPU mode.

Could you please confirm that the attached patch fixes the issue?

Thank you so much!

- Fabian


> 
> 
> - OCaml versions 4.01 (used in Jessie) and before are not doing stack
>   alignment on 16 byte boundaries [1].
> 
> - GCC does 16 byte stack alignment (at least when using SSE instructions)
>   at compile time.
> 
> - Now when calling libmp3lame0 from lame executable (gcc) this works just 
> fine.
>   But calling from liquidsoap (ocaml) we end up calling libmp3lame0 with a 
> unaligned
>   stack therefore getting the SIGSEGV on the "movaps %xmm0,0x20(%esp)".
>   (See the second stack and the address of vec_xrpow_max in [2].)
> 
> 
> But until now I could not fully proove my theory because:
> - OCaml version 4.02 is just in experimental. Using this version would need to
>   compile also all the packages depending on ocaml.
> - Just using this patch in [1] is also not binary compatible with the packages
>   depending on ocaml, therefore needing them all to recompile too.
> 
> For this reason chances for such a change to OCaml to enter Jessie are low?
> 
> 
> One thing did avoid the crash, that was adding 
> "__attribute__((aligned(0x20)))"
> to the vecfloat_union used inside libmp3lame0 [3].
> Requesting an alignment of 0x10 seems without effect.
> (Probably because GCC does this already and is therefore removed.)
> 
> 
> Options we have, if above could be proven right:
> - change libmp3lame0 [3] (at least for stable), even when it is not guilty
> - test rebuilding OCaml and all dependents with the patch in [1]
> - wait if problem vanishes when OCaml 4.02 enters unstable/testing.
> - get someone from debian-ocaml-maint involved.
> 
> 
> [1] http://caml.inria.fr/mantis/view.php?id=6038#c11630
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438#22
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438#87
> 
> 
> Kind regards,
> Bernhard
> 

--- a/libmp3lame/vector/xmm_quantize_sub.c
+++ b/libmp3lame/vector/xmm_quantize_sub.c
@@ -61,11 +61,13 @@ init_xrpow_core_sse(gr_info * const cod_
 int upper4 = (upper / 4) * 4;
 int rest = upper-upper4;
 
-const vecfloat_union fabs_mask = {{ 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
-const __m128 vec_fabs_mask = _mm_loadu_ps(&fabs_mask._float[0]);
-vecfloat_union vec_xrpow_max;
-vecfloat_union vec_sum;
-vecfloat_union vec_tmp;
+static const vecfloat_union fabs_mask = {{ 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
+static __m128 vec_fabs_mask;
+static vecfloat_union vec_xrpow_max;
+static vecfloat_union vec_sum;
+static vecfloat_union vec_tmp;
+
+vec_fabs_mask = _mm_loadu_ps(&fabs_mask._float[0]);
 
 _mm_prefetch((char *) cod_info->xr, _MM_HINT_T0);
 _mm_prefetch((char *) xrpow, _MM_HINT_T0);



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

Bug#787960: libcurl3-gnutls: breaks bti

[Alessandro Ghedini]

On dom, giu 07, 2015 at 01:44:36 +0200, Vincent Lefevre wrote:
> On 2015-06-07 11:40:56 +0200, Alessandro Ghedini wrote:
> > I can't reproduce any of this. Can you please run the command above
> > with the "-v" option and post the output?
> 
> xvii:~> curl -v https://www.vinc17.net/
> *   Trying 92.243.22.117...
> * Connected to www.vinc17.net (92.243.22.117) port 443 (#0)
> * found 180 certificates in /etc/ssl/certs/ca-certificates.crt

Ok, nevermind, that looks ok. Looking at your original report again, I noticed
the following:

> Versions of packages libcurl3-gnutls depends on:
>  [...]
>  ii  libgnutls-deb0-28  3.3.14-2

Essentially you have installed an older version of libgnutls-deb0-28 (the
current one is 3.3.15-5). I think the problem is that the older libgnutls uses
a different version of nettle (libnettle.so.4) than the one libcurl3-gnutls
uses (libnettle.so.6), and they somehow interfere with each other since nettle
doesn't use symbols versioning.

Could you update libgnutls-deb0-28 and see what happens? In any case it doesn't
look like a libcurl bug, although maybe the versioned depends on libgnutls could
be strengthened (it's currently calculated automatically by dpkg-shlibdeps).

Cheers


signature.asc
Description: Digital signature

Bug#782761: linux-tools: Please include tools/hv daemons in a binary package

[Hideki Yamane]

Control: tags -1 +patch

Hi,

 Here's a rough patch for hyperv daemons package (not tested yet)
 I'll try it later, but anyway for the record. 


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane
diff -Nru linux-tools-4.0.2/debian/build/tools/hv/Makefile linux-tools-4.0.2/debian/build/tools/hv/Makefile
--- linux-tools-4.0.2/debian/build/tools/hv/Makefile	1970-01-01 09:00:00.0 +0900
+++ linux-tools-4.0.2/debian/build/tools/hv/Makefile	2015-05-28 19:53:33.0 +0900
@@ -0,0 +1,13 @@
+srcdir := $(top_srcdir)/tools/hv
+
+# Make sure we don't override top_srcdir in the sub-make.  'unexport
+# top_srcdir' is *not* sufficient; nor is adding 'MAKEFLAGS=' to the
+# sub-make command line.
+unexport MAKEFLAGS
+
+all:
+ cd $(top_srcdir)/tools/hv; $(MAKE) all
+
+
+clean:
+ cd $(top_srcdir)/tools/hv; $(MAKE) clean
diff -Nru linux-tools-4.0.2/debian/changelog linux-tools-4.0.2/debian/changelog
--- linux-tools-4.0.2/debian/changelog	2015-05-11 11:53:13.0 +0900
+++ linux-tools-4.0.2/debian/changelog	2015-06-07 20:07:42.0 +0900
@@ -1,3 +1,10 @@
+linux-tools (4.0.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * create hyperv-daemons package (Closes: #782761)
+
+ -- Hideki Yamane   Thu, 28 May 2015 10:23:52 +0900
+
 linux-tools (4.0.2-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru linux-tools-4.0.2/debian/control linux-tools-4.0.2/debian/control
--- linux-tools-4.0.2/debian/control	2015-05-11 12:06:30.0 +0900
+++ linux-tools-4.0.2/debian/control	2015-06-07 21:06:18.0 +0900
@@ -60,3 +60,10 @@
  This package provides the server component 'usbipd' and the client tool
  'usbip'.
 
+Package: hyperv-daemons
+Architecture: amd64
+Section: admin
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Hyper-V daemons
+ Hyper-V daemons: hv-fcopy-daemon, hv-kvp-daemon, hv-vss-daemon
+
diff -Nru linux-tools-4.0.2/debian/control.md5sum linux-tools-4.0.2/debian/control.md5sum
--- linux-tools-4.0.2/debian/control.md5sum	2015-05-11 12:06:30.0 +0900
+++ linux-tools-4.0.2/debian/control.md5sum	2015-06-07 21:06:18.0 +0900
@@ -1,4 +1,4 @@
 ac3acacf0cde6d2cc424f28241bb0857  debian/bin/gencontrol.py
-78da1757427bbfdfaa8e54c64e5d627a  debian/changelog
-711fd0ce9d080e6cf27efddb74863670  debian/templates/control.main.in
+42a333dc4e58b0836836374d25b1c963  debian/changelog
+4ff71cfb84261912360a63710a5d830f  debian/templates/control.main.in
 5205a9db9cb5241ea836fb20502bf045  debian/templates/control.source.in
diff -Nru linux-tools-4.0.2/debian/copyright linux-tools-4.0.2/debian/copyright
--- linux-tools-4.0.2/debian/copyright	2013-09-25 09:18:33.0 +0900
+++ linux-tools-4.0.2/debian/copyright	2015-06-07 19:58:56.0 +0900
@@ -30,3 +30,8 @@
 Files: debian/*
 Copyright: 2006-2012 Debian kernel team
 License: GPL-2
+
+Files: debian/*.services
+Copyright: 2013-2014 Tomas Hozza 
+   2015 Hideki Yamane 
+License: GPL-2
diff -Nru linux-tools-4.0.2/debian/hv_fcopy_daemon.service linux-tools-4.0.2/debian/hv_fcopy_daemon.service
--- linux-tools-4.0.2/debian/hv_fcopy_daemon.service	1970-01-01 09:00:00.0 +0900
+++ linux-tools-4.0.2/debian/hv_fcopy_daemon.service	2015-05-28 20:47:49.0 +0900
@@ -0,0 +1,10 @@
+[Unit]
+Description=Hyper-V FCOPY daemon
+ConditionVirtualization=microsoft
+ConditionPathExists=/dev/vmbus/hv_fcopy
+
+[Service]
+ExecStart=/usr/sbin/hv_fcopy_daemon -n
+
+[Install]
+WantedBy=multi-user.target
diff -Nru linux-tools-4.0.2/debian/hv_kvp_daemon.service linux-tools-4.0.2/debian/hv_kvp_daemon.service
--- linux-tools-4.0.2/debian/hv_kvp_daemon.service	1970-01-01 09:00:00.0 +0900
+++ linux-tools-4.0.2/debian/hv_kvp_daemon.service	2015-05-28 20:46:54.0 +0900
@@ -0,0 +1,10 @@
+[Unit]
+Description=Hyper-V KVP daemon
+ConditionVirtualization=microsoft
+
+[Service]
+Type=simple
+ExecStart=/usr/sbin/hv_kvp_daemon -n
+
+[Install]
+WantedBy=multi-user.target
diff -Nru linux-tools-4.0.2/debian/hv_vss_demon.service linux-tools-4.0.2/debian/hv_vss_demon.service
--- linux-tools-4.0.2/debian/hv_vss_demon.service	1970-01-01 09:00:00.0 +0900
+++ linux-tools-4.0.2/debian/hv_vss_demon.service	2015-05-28 20:46:33.0 +0900
@@ -0,0 +1,9 @@
+[Unit]
+Description=Hyper-V VSS daemon
+ConditionVirtualization=microsoft
+
+[Service]
+ExecStart=/usr/sbin/hv_vss_daemon -n
+
+[Install]
+WantedBy=multi-user.target
diff -Nru linux-tools-4.0.2/debian/hyperv-daemons.install linux-tools-4.0.2/debian/hyperv-daemons.install
--- linux-tools-4.0.2/debian/hyperv-daemons.install	1970-01-01 09:00:00.0 +0900
+++ linux-tools-4.0.2/debian/hyperv-daemons.install	2015-06-07 21:05:15.0 +0900
@@ -0,0 +1,2 @@
+tools/hv/hv*daemon	usr/sbin/
+debian/*.service	lib/systemd/system/
diff -Nru linux-tools-4.0.2/debian/rules.gen linux-tools-4.0.2/debian/rules.gen
--- linux-tools-4.0.2/debian/rules.gen	2015-05-11 12:06:30.0 +0900
+++ linux-tools-4.0.2/debian/rules.gen	2015

Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0

[Bernhard Übelacker]

Hello Fabian,
your patch fixes the issue.

But I fear by using static we potentially introduce a race condition,
if there are any applications encoding in two threads?

(May I ask if there are any reasons against "__attribute__((aligned(0x20)))"?)

Kind regards,
Bernhard


I used following to build with your patch:

mkdir libmp3lame0-with-static-var; cd libmp3lame0-with-static-var
apt-get source libmp3lame0
wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=117;filename=lame-static-vecfloat-msse.patch;bug=786438";
 -O lame-static-vecfloat-msse.patch
cd lame-3.99.5+repack1/
patch -p1 < ../lame-static-vecfloat-msse.patch
dpkg-buildpackage -b -uc -us
cd ..
su -c "dpkg -i libmp3lame0_3.99.5+repack1-7_i386.deb 
libmp3lame-dev_3.99.5+repack1-7_i386.deb"


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

Bug#787985: doomsday-compat should default to gamemode=doom2 if not specified differently

[Fabian Greffrath]

Package: doomsday
Version: 1.14.5-2
Severity: normal
Tags: patch

Hi there,

in its current form, the doosday-compat script does not set a gamemode
by default. This means, if started without an additional "-iwad" or
"-game" argument (but even with an additional "-file" argument) the
game falls back into its Ring-0 mode instead of starting an actual
game. In contrast, every other doom engine falls back to starting Doom
2 when no other argument is given. Since the very purpose of the
doomsday-compat script is to emulate the command line behaviour of
"every other doom engine", I had to modify it accordingly.

That is, I have set the gamemode variable from an empty string to
"doom2". Since this will not set the iwadpath variable, I had to add
some more logic to the final part of the script.

Please note that this will also significantly facilitate creating
packages for PWADs with game-data-packager, since this calls "doom
-file /path/to/pwad" in the desktop files.

Thank you,

Fabian


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

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

Versions of packages doomsday depends on:
ii  libc6 2.19-18
ii  libfluidsynth11.1.6-2
ii  libgcc1   1:5.1.1-7
ii  libgl1-mesa-glx [libgl1]  10.5.5-1
ii  libqt4-network4:4.8.6+git155-g716fbae+dfsg-2
ii  libqt4-opengl 4:4.8.6+git155-g716fbae+dfsg-2
ii  libqtcore44:4.8.6+git155-g716fbae+dfsg-2
ii  libqtgui4 4:4.8.6+git155-g716fbae+dfsg-2
ii  libsdl-mixer1.2   1.2.12-11+b1
ii  libsdl1.2debian   1.2.15-11
ii  libstdc++65.1.1-7
ii  libx11-6  2:1.6.3-1
ii  libxrandr22:1.4.2-1+b1
ii  libxxf86vm1   1:1.1.4-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages doomsday recommends:
ii  doom-wad-shareware [doom-wad]  1.9.fixed-2
pn  fluid-soundfont-gm 
ii  freedm [doom-wad]  0.9-1
ii  freedoom [boom-wad]0.9-1
ii  game-data-packager 41

doomsday suggests no packages.

-- no debconf information
diff --git a/debian/doomsday-compat b/debian/doomsday-compat
index a0fb1f4..05bda09 100755
--- a/debian/doomsday-compat
+++ b/debian/doomsday-compat
@@ -6,7 +6,7 @@
 # - Doomsday expects the -iwad parameter to give a directory containing
 #   IWAD files and loads one depending on the additional -game parameter.
 
-# Copyright © 2013 Fabian Greffrath 
+# Copyright © 2013-2015 Fabian Greffrath 
 # This package is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
 # the Free Software Foundation; either version 2 of the License, or
@@ -29,7 +29,7 @@ next_is_iwad=0
 next_is_pwad=0
 
 iwaddir=""
-gamemode=""
+gamemode="doom2"
 
 for arg in "$@"
 do
@@ -142,6 +142,9 @@ fi
 if [ -n "$iwaddir" -a -n "$gamemode" ]
 then
 	eval $DOOMSDAY -iwad $iwaddir -game $gamemode $cmdline
+elif [ -n "$gamemode" ]
+then
+	eval $DOOMSDAY -game $gamemode $cmdline
 else
 	eval $DOOMSDAY "$@"
 fi

Bug#760947: systemd: Does not start consoles configured in /etc/inittab

[Michael Biebl]

Control: reassign -1 release-notes

Am 07.06.2015 um 08:32 schrieb Samuel Thibault:
> Michael Biebl, le Sun 07 Jun 2015 01:41:59 +0200, a écrit :
>> /etc/inittab is a sysvinit specific config file, which systemd won't
>> read. This is not going to change.
>>
>> If you have custom changes to /etc/inittab, those need to be converted
>> into systemd equivalents manually, if necessary.
> 
> As I said in a previous mail, that's not what I call a seamless upgrade.
> It be at least documented in the release notes or on
> https://wiki.debian.org/systemd

I agree, let's reassign this to release-notes and handle it there.


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



signature.asc
Description: OpenPGP digital signature

Bug#787961: bti: action public no longer works

[gregor herrmann]

Control: tag -1 + upstrem confirmed
Control: forward -1 https://github.com/gregkh/bti/issues/37

On Sun, 07 Jun 2015 00:31:06 +0200, Vincent Lefevre wrote:

> While something like
> 
>   bti --config ~/.bti-twitter --action friends
> 
> returns immediately, the command
> 
>   bti --config ~/.bti-twitter --action public
> 
> hangs with a lots of network activity.

Thanks.

Confirmed & forwarded upstream as
https://github.com/gregkh/bti/issues/37


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: The Who: Won't Get Fooled Again (Full Length)


signature.asc
Description: Digital Signature

Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0

[Fabian Greffrath]

Hi Bernhard,

Am Sonntag, den 07.06.2015, 14:36 +0200 schrieb Bernhard Übelacker: 
> your patch fixes the issue.

\o/

> But I fear by using static we potentially introduce a race condition,
> if there are any applications encoding in two threads?

I see, maybe we could add a "security net" there (e.g. another static
variable that is set to 1 at the beginning of the function and to 0 at
the end and a "while (variable)" loop just before that at the
beginning).

> (May I ask if there are any reasons against "__attribute__((aligned(0x20)))"?)

Hm, because (a) it should not even be necessary and (b) it is not
portable to non-GCC compilers. The variables are already properly
aligned, but not if the FPU is in x387 mode.

Cheers,

Fabian



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

Bug#750895: from_filename

[debian]

Confirmed, I get exactly the same error message using Jessie's standard 
packages (python3 3.4.0 and python3-tempita 0.5.2).



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

Bug#787986: po-Update-Simplified-Chinese-programs-translation.patch

[lumin]

Package: dpkg
Version: 1.18.2
Severity: wishlist

Hi dpkg devs,

This is a routine update of zh_CN.po.
What's new this time is:

 * I used to generate patches in an traditional way:
  diff -ru
   This time I generated that patch in such way:
  git format-patch

I hope my change of tool to use would save you several seconds.
BTW, I'm planning to make another update before release of 1.18.2,
at that time I would append new patch here.

Thanks.
-- 
Regards,
  C.D.Luminate
From 526e3c8f7272032a7e56bb647b0d642ec7ab285a Mon Sep 17 00:00:00 2001
From: Zhou Mo 
Date: Sun, 7 Jun 2015 12:51:39 +
Subject: [PATCH] po: Update Simplified Chinese programs translation

---
 po/zh_CN.po | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/po/zh_CN.po b/po/zh_CN.po
index 4ff780d..f2c58c4 100644
--- a/po/zh_CN.po
+++ b/po/zh_CN.po
@@ -16,7 +16,7 @@ msgstr ""
 "Project-Id-Version: dpkg 1.18.x\n"
 "Report-Msgid-Bugs-To: debian-d...@lists.debian.org\n"
 "POT-Creation-Date: 2015-05-30 00:17+0200\n"
-"PO-Revision-Date: 2015-05-21 05:45+\n"
+"PO-Revision-Date: 2015-06-07 05:45+\n"
 "Last-Translator: Zhou Mo \n"
 "Language-Team: Chinese (simplified) \n"
 "Language: zh_CN\n"
@@ -1514,10 +1514,9 @@ msgid ""
 msgstr "获取建议的新符号链接 %.250s 的状态失败，它将替代符号链接 %.250s"
 
 #: src/archives.c
-#, fuzzy, c-format
-#| msgid "cannot open archive part file '%.250s'"
+#, c-format
 msgid "newline not allowed in archive object name '%.255s'"
-msgstr "无法打开存档的分块文件 %.250s"
+msgstr "归档对象名称 “%.255s” 中不允许换行"
 
 #: src/archives.c
 #, c-format
@@ -4569,15 +4568,14 @@ msgid "unable to stat file name '%.250s'"
 msgstr "无法获取文件名 %.250s"
 
 #: dpkg-deb/build.c
-#, fuzzy, c-format
-#| msgid "newline in field name '%.*s'"
+#, c-format
 msgid "newline not allowed in pathname '%s'"
-msgstr "在字段名 %.*s 中有换行符"
+msgstr "路径名 “%s” 不允许换行符"
 
 #: dpkg-deb/build.c
 #, c-format
 msgid "failed to write filename to tar pipe (%s)"
-msgstr "写入文件名到 tar 的管道(%s)失败"
+msgstr "写入文件名到 tar 管道 (%s) 失败"
 
 #: dpkg-deb/build.c
 msgid "data member"
-- 
2.1.4

Bug#649449: firmware-iwlwifi: "Card state received: HW:Kill SW:On" and "Not sending command - RF KILL"

[dayer]

Sorry for the big delay. I don't know why the email never arrived to my inbox.

The problem has continued. For example with kernel 3.16.7-ckt9-3.

dmesg after the connection has been broken:

[ 3031.670872] iwl3945 :02:00.0: Card state received: HW:Kill SW:On
[ 3031.671615] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 3031.673602] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673628] iwl3945 :02:00.0: Error sending C_REM_STA:
enqueue_hcmd failed: -5
[ 3031.673636] iwl3945 :02:00.0: Error removing station xx:xx:xx:xx:xx:xx
[ 3031.673698] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673723] iwl3945 :02:00.0: Error sending C_QOS_PARAM:
enqueue_hcmd failed: -5
[ 3031.673729] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673753] iwl3945 :02:00.0: Error sending C_RXON:
enqueue_hcmd failed: -5
[ 3031.673758] iwl3945 :02:00.0: Error setting new configuration (-5).
[ 3031.673763] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673786] iwl3945 :02:00.0: Error sending C_RXON_ASSOC:
enqueue_hcmd failed: -5
[ 3031.673794] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673817] iwl3945 :02:00.0: Error sending C_RXON_ASSOC:
enqueue_hcmd failed: -5
[ 3031.673827] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673850] iwl3945 :02:00.0: Error sending C_RXON:
enqueue_hcmd failed: -5
[ 3031.673854] iwl3945 :02:00.0: Error setting new configuration (-5).
[ 3031.673880] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673885] iwl3945 :02:00.0: Error sending C_LEDS:
enqueue_hcmd failed: -5
[ 3031.673916] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.673921] iwl3945 :02:00.0: Error sending C_RXON:
enqueue_hcmd failed: -5
[ 3031.673943] iwl3945 :02:00.0: Error setting new configuration (-5).
[ 3031.677688] iwl3945 :02:00.0: Not sending command - RF KILL
[ 3031.677697] iwl3945 :02:00.0: Error sending C_RXON:
enqueue_hcmd failed: -5
[ 3031.677721] iwl3945 :02:00.0: Error setting new configuration (-5).
[ 3031.680054] iwl3945 :02:00.0: Master Disable Timed Out, 100 usec
[ 3031.689923] cfg80211: Calling CRDA to update world regulatory domain
[ 3031.710936] cfg80211: World regulatory domain updated:
[ 3031.710941] cfg80211:  DFS Master region: unset
[ 3031.710961] cfg80211:   (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 3031.710964] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz),
(N/A, 2000 mBm), (N/A)
[ 3031.710967] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz),
(N/A, 2000 mBm), (N/A)
[ 3031.710969] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz),
(N/A, 2000 mBm), (N/A)
[ 3031.710972] cfg80211:   (517 KHz - 525 KHz @ 8 KHz,
16 KHz AUTO), (N/A, 2000 mBm), (N/A)
[ 3031.710993] cfg80211:   (525 KHz - 533 KHz @ 8 KHz,
16 KHz AUTO), (N/A, 2000 mBm), (0 s)
[ 3031.710996] cfg80211:   (549 KHz - 573 KHz @ 16 KHz),
(N/A, 2000 mBm), (0 s)
[ 3031.710998] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz),
(N/A, 2000 mBm), (N/A)
[ 3031.711001] cfg80211:   (5724 KHz - 6372 KHz @ 216
KHz), (N/A, 0 mBm), (N/A)


And according to rfkill:

# rfkill list all
0: Toshiba Bluetooth: Bluetooth
Soft blocked: no
Hard blocked: yes
1: phy2: Wireless LAN
Soft blocked: no
Hard blocked: yes


If I want to use another wireless interface (external) I've to disable
the iwl3945 module or networkmanager thinks that the Wi-Fi switch is
off.
It's like I switch off the physical switch. It could be a physical
problem derivative of the age of the laptop.

Regards,


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

Bug#787911: [Reportbug-maint] Bug#787911: reportbug: Read config from XDG_CONFIG_HOME/debian/reportbugrc.

[Rodolphe PELLOUX-PRAYER]

Le 06/06/2015 17:34, Sandro Tosi a écrit :
> control: tags -1 + moreinfo
> 
> On Sat, Jun 6, 2015 at 4:54 AM, Rodolphe PELLOUX-PRAYER
>  wrote:
>> Here a patch to allow use of XDG_CONFIG_HOME/debian/reportbugrc for settings.
> 
> what's the advantage? 

Mainly, organize config files in home directory in following the xdg
basedir spec [1]. Note that this patch didn't remove the previous config
file path, it just adds the possibility to move the config file in this
new xdg dir.

> why under the 'debian' namespace?

Well, I guess I would like that most config files related to debian
tools are in the same place (I proposed similar patches that purpose to
dput [2] and git-buildpackage [3] for now).

But if XDG_CONFIG_HOME/debian dir is not appropriate,
XDG_CONFIG_HOME/reportbugrc would be ok.

Regards,
Rodolphe

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787840
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787519



signature.asc
Description: OpenPGP digital signature

Bug#787938: libjpeg-turbo: please use versioned Provides in sid

[Ondřej Surý]

On Sat, Jun 6, 2015, at 17:22, Thorsten Glaser wrote:
> Source: libjpeg-turbo
> Version: 1:1.4.0-7
> Severity: normal
> 
> Hi,
> 
> libjpeg62-turbo Provides libjpeg62, but does so without a
> version number. Several utilities Depends libjpeg62 with
> a version number. Since a while, we have versioned Provides,
> which makes this actually work. Please use them.

I think those utilities need binNMU. This hasn't been problem for
transitioning whole archive from libjpeg8 to libjpeg62 to
libjpeg62-turbo, so I don't see how this might be a problem for m68k.

> Proof: I just hand-patched libjpeg-turbo binaries: replace
> all 1:1.4.0-7 with 1:1.4.0-7+p in all control files, then
> change the line in libjpeg62-turbo control to:
> Provides: libjpeg62 (= 1:1.4.0-7+p)

This won't work in unstable where libjpeg62 is also provided by
src:libjpeg62 (= 1:6b2-2).

> This allows me to continue building packages on m68k where
> not everything has been rebuilt against libjpeg62-turbo yet
> (except those that already use libjpeg8 or libjpeg9 ofc).

You need to fix this by binNMUing those.

Cheers,
-- 
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#787638: [php-maint] Bug#787638: Acknowledgement (php5-curl: php segfaults immediately with php5-curl installed)

[Ondřej Surý]

Control: reassign -1 libcurl3-gnutls
Control: affects -1 php5-curl
Control: found -1 libcurl3-gnutls/7.42.1-2
Control: fixed -1 libcurl3-gnutls/7.42.1-2+b1

Reassigning to libcurl3-gnutls for further investigation (if needed) by
src:curl maintainer.

Cheers,
Ondrej

On Wed, Jun 3, 2015, at 19:45, Nick Black wrote:
> looks like this got resolved with the 7.42.1-2+b1 libcurl3-gnutls update
> that just rolled down. i can verify this update fixed things for me.
> 
> -- 
> nick black -=- http://www.nick-black.com
> to make an apple pie from scratch, you need first invent a universe.
> 
> ___
> 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#787987: python-mode: Error on installation of python-mode (1:6.1.3-2)

[Enno]

Package: python-mode
Version: 1:6.1.3-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
installation of python-mode via aptitude
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
install python-mode via aptitude
   * What was the outcome of this action?
Selecting previously unselected package python-mode.
(Reading database ... 147189 files and directories currently installed.)
Preparing to unpack .../python-mode_1%3a6.1.3-2_all.deb ...
Unpacking python-mode (1:6.1.3-2) ...
Setting up python-mode (1:6.1.3-2) ...
ERROR: python-mode is broken - called emacs-package-install as a new-style 
add-on, but has no compat file.
Install python-mode for emacs
Install python-mode for emacs24
install/python-mode: Handling install for emacsen flavor emacs24
Wrote /usr/share/emacs24/site-lisp/python-mode/doctest-mode.elc
Wrote /usr/share/emacs24/site-lisp/python-mode/python-mode.elc
Wrote /usr/share/emacs24/site-lisp/python-mode/completion/pycomplete.elc

   * What outcome did you expect instead?
Selecting previously unselected package python-mode.
(Reading database ... 147189 files and directories currently installed.)
Preparing to unpack .../python-mode_1%3a6.1.3-2_all.deb ...
Unpacking python-mode (1:6.1.3-2) ...
Setting up python-mode (1:6.1.3-2) ...
Install python-mode for emacs
Install python-mode for emacs24
install/python-mode: Handling install for emacsen flavor emacs24
Wrote /usr/share/emacs24/site-lisp/python-mode/doctest-mode.elc
Wrote /usr/share/emacs24/site-lisp/python-mode/python-mode.elc
Wrote /usr/share/emacs24/site-lisp/python-mode/completion/pycomplete.elc


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

Kernel: Linux 3.2.65-mash-rt94
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python-mode depends on:
ii  emacs46.1
ii  emacs24-lucid [emacsen]  24.4+1-5
ii  python   2.7.5-5

Versions of packages python-mode recommends:
pn  pychecker  
pn  pymacs 

Versions of packages python-mode suggests:
pn  pylint   
pn  python-ropemacs  

-- 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#787866: autogen: after upgrade to 5.18.5 autogen no longer works

[Nikos Mavrogiannopoulos]

On Sat, 2015-06-06 at 16:18 -0700, Bruce Korb wrote:

> In that log, I find:
> 
> > Compiling '[ -~]' with bits 0x1 <<<=== compiled as extended RE
> > CASE no match: `c' MATCH_FULL vs. `[ -~]'
> I think there is a RE library problem.  The code is as follows:
> > /*
> >  *  On the first call for this macro, compile the expression
> >  */
> > if (cur_macro->md_pvt == NULL) {
> > void *mat = VOIDP(pattern);
> > regex_t * re  = AGALOC(sizeof(*re), "select match full re");
> >
> > if (OPT_VALUE_TRACE > TRACE_EXPRESSIONS) {
> > fprintf(trace_fp, TRACE_SEL_MATCH_FULL,
> >  pattern, cur_macro->md_res);
> This function returns FAILURE, and that is incorrect.
> This code has not changed in many years (16).
> Last January, I changed the casting of 'pattern' to coerce it into a "void *"
> without any const attributes, but functionally no changes for 16 years.
> The following program should replicate the same test that fails in AutoGen.
> If this succeeds, then the question is, "what is different in the execution 
> env?"
> If this fails, on the other hand, then you need to look to the regcomp 
> library.

I've compiled and run the attached version of that program and it
succeeds (no valgrind warnings either). 

The differences in the environment during build are the following three
variables.
+MAKEFLAGS=
+MAKELEVEL=1
+MFLAGS=

#include 
#include 
#include 
#include 
#include 

#define VOIDP(_p)  ((void *)(unsigned long)(_p))

static void
compile_re(regex_t * re, char const * pat, int flags)
{
 int rerr = regcomp(re, VOIDP(pat), flags);
 if (rerr != 0) {
 char erbf[ 1024 ];
 regerror(rerr, re, erbf, sizeof(erbf));
 fprintf(stderr, "error\n");
 abort();
 }
}

static int
check_full_match(char const * sample, char const * pattern)
{
 regmatch_t m[2];
 regex_t * md_pvt;

 /*
  *  On the first call for this macro, compile the expression
  */
 void *mat = VOIDP(pattern);
 regex_t * re  = malloc(sizeof(*re));

 compile_re(re, mat, 1);
 md_pvt = re;

 // In this function, the RE must match the entire string.
 //
 if (regexec(re, sample, (size_t)2, m, 0)
 != 0)
 return 0;

 if (  (m[0].rm_eo != (int)strlen( sample ))
|| (m[0].rm_so != 0))
 return 0;
 return 1;
}

int main(int argc, char ** argv) {
 if (! check_full_match("c", "[ -~]"))
 printf("FAILED\n");
 return 0;
}

Bug#787988: duplicity: Pydrive backend gives: "Error: [('asn1 encoding routines', ...

[Alexandre D.]

Package: duplicity
Version: 0.7.02-2
Severity: normal

Dear Maintainer,

When I'm trying to run duplicity with the pydrive backend as described in the 
manpage, having installed pydrive according to the instructions and converted a 
Google Service account with the command " Download the .p12 key file of the 
account and convert it to the .pem format "openssl pkcs12 -in XXX.p12 -nodes 
-nocerts > pydriveprivatekey.pem", I get the following error:

$ GOOGLE_DRIVE_ACCOUNT_KEY=pydriveprivatekey.pem duplicity --encrypt-key foo 
--use-agent /home/foo/ pydrive://my...@developer.gserviceaccount.com/foo/
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1526, in 
with_tempdir(main)
  File "/usr/bin/duplicity", line 1520, in with_tempdir
fn()
  File "/usr/bin/duplicity", line 1361, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1070, 
in ProcessCommandLine
backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 961, 
in set_backend
globals.backend = backend.get_backend(bend)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in 
get_backend
obj = get_backend_object(url_string)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in 
get_backend_object
return factory(pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/pydrivebackend.py", 
line 53, in __init__
file_list = self.drive.ListFile({'q': "'Root' in parents"}).GetList()
  File "/usr/local/lib/python2.7/dist-packages/pydrive/apiattr.py", line 154, 
in GetList
for x in self:
  File "/usr/local/lib/python2.7/dist-packages/pydrive/apiattr.py", line 138, 
in next
result = self._GetList()
  File "/usr/local/lib/python2.7/dist-packages/pydrive/auth.py", line 53, in 
_decorated
self.auth.Authorize()
  File "/usr/local/lib/python2.7/dist-packages/pydrive/auth.py", line 422, in 
Authorize
self.service = build('drive', 'v2', http=self.http)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/util.py", line 137, 
in positional_wrapper
return wrapped(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/googleapiclient/discovery.py", 
line 196, in build
resp, content = http.request(requested_url)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/util.py", line 137, 
in positional_wrapper
return wrapped(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
541, in new_request
self._refresh(request_orig)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
769, in _refresh
self._do_refresh_request(http_request)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
795, in _do_refresh_request
body = self._generate_refresh_request_body()
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
1425, in _generate_refresh_request_body
assertion = self._generate_assertion()
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line 
1554, in _generate_assertion
private_key, self.private_key_password), payload)
  File "/usr/local/lib/python2.7/dist-packages/oauth2client/crypt.py", line 
169, in from_string
pkey = crypto.load_pkcs12(key, password).get_privatekey()
  File "/usr/lib/python2.7/dist-packages/OpenSSL/crypto.py", line 2216, in 
load_pkcs12
_raise_current_error()
  File "/usr/lib/python2.7/dist-packages/OpenSSL/_util.py", line 22, in 
exception_from_error_queue
raise exceptionType(errors)
Error: [('asn1 encoding routines', 'ASN1_D2I_READ_BIO', 'not enough data')]

Regards
Alexandre

-- System Information:
Debian Release: 8.1
  APT prefers stable (only duplicity is testing)
  Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64
Locale: (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages duplicity depends on:
ii  libc62.19-18
ii  librsync10.9.7-10
ii  python   2.7.9-1
ii  python-lockfile  1:0.8-2

Versions of packages duplicity recommends:
ii  python-oauthlib  0.6.3-1
ii  python-paramiko  1.15.1-1
ii  python-urllib3   1.9.1-3
ii  rsync3.1.1-3

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
pn  python-boto 
pn  python-cloudfiles   
ii  python-gdata2.0.18+dfsg1-2
pn  python-swiftclient  
pn  tahoe-lafs  

-- 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#734794: (no subject)

[Ritesh Raj Sarraf]

On Saturday 06 June 2015 12:09 AM, Patrick Schleizer wrote:
>> > When you add/remove *partitions*, yes. That's understood.
> Can you please elaborate on this?
>
> What would be the right course of action, so we don't have to hardcode
> "sleep 2"? Is there any command that would wait until kpartx is ready?
> Or that would tell us whether it's safe now or not to use kpartx?

It is a timing problem. And the timing can greatly vary based on the
amount of task your machine is performing at that time.

Given the current limitations, the wise option I thought was to make
kpartx try a little longer. For this, I've submitted a patch upstream
increasing kpartx's retry from 3 seconds to 5 seconds. Why 5 seconds ? I
have no logical reasoning.

If it gets accepted upstream, it will show up in the next release.
Meanwhile, if you want to test it, you can pick the patch from the
upstream mailing list and try.
https://www.redhat.com/archives/dm-devel/2015-May/msg00087.html

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System



signature.asc
Description: OpenPGP digital signature

Bug#786587: libcgi-pm-perl: change to tempfile handling in 4.05 breaks Ikiwiki

[Simon McVittie]

forwarded 786587 https://github.com/leejo/CGI.pm/issues/178

On Sat, 23 May 2015 at 09:07:55 +0200, Jonas Smedegaard wrote:
> Ikiwiki attachment plugin messes internally with tempfile object and
> stopped working with the change in 4.05.

On closer examination, this is not actually the case: ikiwiki's preferred
code path uses a documented API. It might not have been documented at the
time it was added (the comment in ikiwiki implied that it wasn't), but it
is now:

"""
If you need to you
can access the temporary file directly. You can access the temp file for a file
upload by passing the file name to the tmpFileName() method:

my $filename= $query->param( 'uploaded_file' );
my $tmpfilename = $query->tmpFileName( $filename );
"""

However, it seems that this no longer works: tmpFileName now expects a
file-handle, as received from $query->upload('uploaded_file'). I've
reported this upstream, .

I have what appears to be a valid workaround for ikiwiki (trying the result
of upload() before or after the result of param()), which I'll test and
upload soon.

If the preferred code path fails, ikiwiki does try to use CGI.pm
internals before giving up entirely, but that's only there as a
workaround for Perl 5.8-era CGI.pm. I might delete that, since Perl 5.8
is a decade old at this point.

S


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

Bug#787938: libjpeg-turbo: please use versioned Provides in sid

[Thorsten Glaser]

Ondřej Surý dixit:

>I think those utilities need binNMU. This hasn't been problem for

You can only binNMU things when their dependencies are
installable, which isn’t always the case when you have
a lot of these things.

>> change the line in libjpeg62-turbo control to:
>> Provides: libjpeg62 (= 1:1.4.0-7+p)
>
>This won't work in unstable where libjpeg62 is also provided by
>src:libjpeg62 (= 1:6b2-2).

It does (debian-ports *only* have unstable): if one package
pulls in libjpeg62-turbo, then the Provides is fulfilled,
and any further dependency on libjpeg62 for which the
version is <= 1:1.4.0-7+p is ignored.

>> This allows me to continue building packages on m68k where
>> not everything has been rebuilt against libjpeg62-turbo yet
>> (except those that already use libjpeg8 or libjpeg9 ofc).
>
>You need to fix this by binNMUing those.

I need to be able to binNMU things. I’m currently fighting
some circular B-D issues (e.g. curl/curl-filters/ghostscript),
running into a libjpeg issue on the way doesn’t help.

Why do you fight this? Adding the version to Provides helps
in *some* cases on debian-ports architectures and doesn’t
hurt anything. I don’t understand.

bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)


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

Bug#784709: [PATCH] use lsblk to attemp to guess partition's fs type

[Philippe Coval]

If not found it will fallback to use other tools.

Note that fs_type function is not expected to return error code
different than zero even if it failed to detect type.

If filesystem is undermined then "NOT-DETECTED" will be echoed.

This change will prevent mount to hang on extended part (#768902)

Signed-off-by: Philippe Coval 
Bug-Debian: 768902
---
 common.sh| 23 ++-
 linux-boot-probes/common/50mounted-tests |  2 +-
 os-probes/common/50mounted-tests |  1 +
 3 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/common.sh b/common.sh
index 30e245e..f89c07d 100644
--- a/common.sh
+++ b/common.sh
@@ -106,14 +106,27 @@ item_in_dir () {
 # We can't always tell the filesystem type up front, but if we have the
 # information then we should use it. Note that we can't use block-attr here
 # as it's only available in udebs.
+# If not detected after different attempts then "NOT-DETECTED" will be printed
+# because function is not supposed to exit error codes.
 fs_type () {
+   local fstype=""
if (export PATH="/lib/udev:$PATH"; type vol_id) >/dev/null 2>&1; then
-   PATH="/lib/udev:$PATH" vol_id --type "$1" 2>/dev/null
-   elif type blkid >/dev/null 2>&1; then
-   blkid -o value -s TYPE "$1" 2>/dev/null
-   else
-   return 0
+   PATH="/lib/udev:$PATH" \
+   fstype=$(vol_id --type "$1" 2>/dev/null \
+   || echo "")
+   [ "$fstype" = "" ] || { echo "$fstype" ; return 0; }
+   fi
+   if type lsblk >/dev/null 2>&1 ; then
+   fstype=$(lsblk --nodeps --noheading --output fstype -- "$1" || 
echo "")
+   [ "$fstype" = "" ] || { echo "$fstype" ; return 0; }
+   fi
+   if type blkid >/dev/null 2>&1; then
+   fstype=$(blkid -o value -s TYPE "$1" 2>/dev/null \
+   || echo "")
+   [ "$fstype" = "" ] || { echo "$fstype" ; return 0; }
fi
+   echo "NOT-DETECTED"
+   return 0
 }
 
 parse_proc_mounts () {
diff --git a/linux-boot-probes/common/50mounted-tests 
b/linux-boot-probes/common/50mounted-tests
index 41e26e6..ee1e9f2 100755
--- a/linux-boot-probes/common/50mounted-tests
+++ b/linux-boot-probes/common/50mounted-tests
@@ -5,7 +5,7 @@ set -e
 
 partition="$1"
 
-types="$(fs_type "$partition")" || types=NOT-DETECTED
+types="$(fs_type "$partition")"
 if [ "$types" = NOT-DETECTED ]; then
debug "$1 type not recognised; skipping"
exit 0
diff --git a/os-probes/common/50mounted-tests b/os-probes/common/50mounted-tests
index 561163b..67744bd 100755
--- a/os-probes/common/50mounted-tests
+++ b/os-probes/common/50mounted-tests
@@ -6,6 +6,7 @@ partition="$1"
 . /usr/share/os-prober/common.sh
 
 types="$(fs_type "$partition")" || types=NOT-DETECTED
+[ "" != "$types" ] || types=NOT-DETECTED
 if [ "$types" = NOT-DETECTED ]; then
debug "$1 type not recognised; skipping"
exit 0
-- 
2.1.4


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

Bug#786442: some lines don't appear in some messages

[Thijs Kinkhorst]

On Thu, May 21, 2015 20:20, Carlos Carvalho wrote:
> Package: squirrelmail
> Version: 2:1.4.23~svn20120406-2
> Severity: grave
>
> Below is a message that doesn't display in squirrelmail; Its single line
> doesn't appear. When clicking "reply" it appears quoted, as it should.

Thanks. I've committed a fix upstream and will upload this to Debian if it
does not give any problems.


Cheers,
Thijs


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

Bug#787989: multistrap: fails with suite jessie and stretch (sid works)

[Johannes Schauer]

Package: multistrap
Version: 2.2.1
Severity: normal

Hi,

suppose the following configuration:

[General]
arch=
directory=
cleanup=true
noauth=false
explicitsuite=false
unpack=true
bootstrap=Debian
aptsources=Debian

[Debian]
packages=apt
source=http://http.debian.net/debian
keyring=debian-archive-keyring
suite=jessie

then I'll get the following error:

Setting up systemd (215-17+deb8u1) ...
Failed to read /proc/cmdline. Ignoring: No such file or directory
Failed to open /dev/urandom: Function not implemented
dpkg: error processing package systemd (--configure):
 subprocess installed post-installation script returned error exit 
status 1
Setting up dmsetup (2:1.02.90-2.2) ...
dpkg: dependency problems prevent configuration of systemd-sysv:
 systemd-sysv depends on systemd; however:
  Package systemd is not configured yet.
 systemd-sysv depends on systemd (= 215-17+deb8u1); however:
  Package systemd is not configured yet.

dpkg: error processing package systemd-sysv (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of init:
 init depends on systemd-sysv | sysvinit-core | upstart; however:
  Package systemd-sysv is not configured yet.
  Package sysvinit-core is not installed.
  Package upstart is not installed.

dpkg: error processing package init (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.19-18) ...
Errors were encountered while processing:
 systemd
 systemd-sysv
 init
ERR: dpkg configure reported an error.
Native mode configuration reported an error!
I: Tidying up apt cache and list data.

Multistrap system reported 1 error in 
/home/josch/annex/personal/projects/lxc-multistrap/multitest/.
I: Tidying up apt cache and list data.

The full log is attached.

When replacing jessie by stretch, the problem is the same.

When replacing jessie by sid, then multistrap works fine.

cheers, josch
multistrap 2.2.1 using jessie.conf
multistrap 2.2.1 using jessie.conf
Defaulting architecture to native: amd64
multistrap building amd64 multistrap on 'amd64'
I: Setting /home/josch/annex/personal/projects/lxc-multistrap/multitest/lib64 
-> /home/josch/annex/personal/projects/lxc-multistrap/multitest/lib symbolic 
link.
I: Installing debian-archive-keyring 
Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
  libounit-ocaml-dev pandoc-data
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 444 not upgraded.
Need to get 40.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://http.debian.net/debian/ stable/main debian-archive-keyring all 
2014.3 [40.1 kB]
Fetched 40.1 kB in 0s (179 kB/s)
Download complete and in download only mode
Getting package lists: APT_CONFIG="/tmp/multistrap.l3JuGc" apt-get  -o 
Apt::Architecture=amd64 -o 
Dir::Etc::TrustedParts=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/trusted.gpg.d
 -o 
Dir::Etc::Trusted=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/trusted.gpg.d/trusted.gpg
 -o Apt::Get::Download-Only=true -o Apt::Install-Recommends=false -o 
Dir=/home/josch/annex/personal/projects/lxc-multistrap/multitest/ -o 
Dir::Etc=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/ 
-o 
Dir::Etc::Parts=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/apt.conf.d/
 -o 
Dir::Etc::PreferencesParts=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/preferences.d/
 -o APT::Default-Release=* -o 
Dir::State=/home/josch/annex/personal/projects/lxc-multistrap/multitest/var/lib/apt/
 -o 
Dir::State::Status=/home/josch/annex/personal/projects/lxc-multistrap/multitest/var/lib/dpkg/status
 -o Dir::Cache=/home/josch/annex
 /personal/projects/lxc-multistrap/multitest/var/cache/apt/ update
Get:1 http://http.debian.net jessie InRelease [134 kB]
Get:2 http://http.debian.net jessie/main Sources [7,059 kB]
Get:3 http://http.debian.net jessie/main amd64 Packages [6,768 kB]
Get:4 http://http.debian.net jessie/main Translation-en [4,585 kB]
Fetched 18.5 MB in 6s (2,665 kB/s)
Reading package lists...
I: Calculating required packages.
APT_CONFIG="/tmp/multistrap.l3JuGc" apt-get  -o Apt::Architecture=amd64 -o 
Dir::Etc::TrustedParts=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/trusted.gpg.d
 -o 
Dir::Etc::Trusted=/home/josch/annex/personal/projects/lxc-multistrap/multitest/etc/apt/trusted.gpg.d/trusted.gpg
 -o Apt::Get::Dow

Bug#787721: Error from Xorg after typical GNOME hangup

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Jun  4, 2015 at 18:15:02 +0530, Jeffrin Jose wrote:

> Package: xserver-xorg-core
> Version: 2:1.17.1-2
> 
> I started X session using xinit command  and  after starting typical gnome 
> session
> X window related seems to hang.
> 
> Here my "uname -a"  output
> --x-x-x--x--x---
> $uname -a
> Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) 
> x86_64 GNU/Linux
> $
> -x--x---x--x---x---
> 
> I have attached a part of  relevent log file
> 
Please attach full logs and config.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#734794: (no subject)

[Patrick Schleizer]

Does upstream know about this issue?

What would be the real fix to solve this timing problem?

Are there commands, such as:

- 'kpartx --wait-until-ready' that waits as long as required or,

- 'kpartx --is-ready' that exits 0 or 1 accordingly.

Or would implementing those up to 'kpartx' or another project?

Cheers,
Patrick


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

Bug#786586: ikiwiki: attachment plugin broken - any upload fail

[Simon McVittie]

Control: tags 786586 + pending fixed-upstream
Control: unblock 786587 by 786586

On Sat, 23 May 2015 at 08:58:34 +0200, Jonas Smedegaard wrote:
> Ikiwiki attachment plugin seems to inspect internal structure of the
> tempfile which smells exactly like the kind of thing warned about.

It only does this if the documented procedure fails. (A comment
in the attachment plugin says tmpFileName is undocumented, but
in fact it's documented now.)

Unfortunately, that documented procedure regressed in the
4.x series, and now we have to do something different
(namely passing the filehandle to tmpFileName,
not the user-supplied filename).

Worked around upstream in
,
and will be in the next ikiwiki release; disconnecting the CGI.pm bug
because I think this is a regression in CGI.pm, not just ikiwiki doing
the wrong thing.

S


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

Bug#787992: fflas-ffpack: please make the build reproducible Source:

[Maria Valentina Marin]

Source: fflas-ffpack
Version: 1.6.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi,

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

The attached patch changes the value of HTML_TIMESTAMP in the two files,
doc/Doxyfile and doc/DoxyfileDev from YES to NO.  Once applied
fflas-ffpack can be built reproducibly in our current experimental
framework.

Patching these doxyfiles is necessary in this case because of the
following reasons:

1. Even though the doxygen upstream changed the default value of
HTML_TIMESTAMP from YES to NO this does not affect this package because
the value of HTML_TIMESTAMP is explicitly set to YES.

2. Upstream's doxyfiles cannot reliably be modified to change the value
of HTML_TIMESTAMP during the build process because dh_doxygen is only
run after the build already completed and even adding a new dh command
cannot solve the problem because there exists no sane and reliable
solution to detect the file which will be used as the configuration file
for doxygen (it is not always called doxyfile).

3. In case of this source package a patch against upstream is necessary
in contrast to a patch against Debian rules because this source package
does not call doxygen in debian/rules.

Please also consider forwarding this patch upstream.

Thank You!
akira 
[1]: https://wiki.debian.org/ReproducibleBuilds
Description: Change HTML_TIMESTAMP option from YES to NO to make package reproducible

--- fflas-ffpack-1.6.0.orig/doc/Doxyfile
+++ fflas-ffpack-1.6.0/doc/Doxyfile
@@ -974,7 +974,7 @@ HTML_COLORSTYLE_GAMMA  = 80
 # page will contain the date and time when the page was generated. Setting
 # this to NO can help when comparing the output of multiple runs.
 
-HTML_TIMESTAMP = YES
+HTML_TIMESTAMP = NO
 
 # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
 # files or namespaces will be aligned in HTML using tables. If set to
--- fflas-ffpack-1.6.0.orig/doc/DoxyfileDev
+++ fflas-ffpack-1.6.0/doc/DoxyfileDev
@@ -974,7 +974,7 @@ HTML_COLORSTYLE_GAMMA  = 80
 # page will contain the date and time when the page was generated. Setting
 # this to NO can help when comparing the output of multiple runs.
 
-HTML_TIMESTAMP = YES
+HTML_TIMESTAMP = NO
 
 # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
 # files or namespaces will be aligned in HTML using tables. If set to

Bug#787993: Sloppy license for CSS and ICON templates

[Osamu Aoki]

Package: publican
Version: 4.2.6-1
Severity: wishlist

This is about GFDL license of the ICON and CSS template files under
publican-*/datadir/Common_Content/  The debian/copyright has:

# Please improve this section when explicit GFDL licensing is added to source
# code
Files: datadir/Common_Content/*
Copyright: 2007-2009 Red Hat, Inc.
License: GFDL
 Not explicitly stated in source code, so here's the mail excerpt from Jeff
 Fearn. Full mail can be found at
 https://www.redhat.com/archives/publican-list/2009-August/msg00055.html
 .
 Return-Path: 
 Delivered-To: unknown
 Message-ID: <4a947e2d.7070...@redhat.com>
 Date: Wed, 26 Aug 2009 10:13:33 +1000
 From: Jeffrey Fearn 
 Organization: Red Hat Inc.
 MIME-Version: 1.0
 To: Publican list 
 Subject: Re: [publican-list] Adjusting copyright information
 References: <87r5v097yw@vertex.dottedmag.net>
 In-Reply-To: <87r5v097yw@vertex.dottedmag.net>
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 .
 ...
 > datadir/Common_Content/*: no copyright/license information
 hmm that content is all GFDL license, anyone know if I need to specify this 
per file or can I do it in one place?

Files under
 /usr/share/publican/Common_Content/brand-template/images/*.png
 /usr/share/publican/Common_Content/common/*/css/*.css
as installed in the system from these template files should be in the
permissive license following the other GNU tools such as autoconf,
automake, libtrool, ...  :-)

FYI: The CSS should be in code like license.  GFDL does not make sense
for CSS. The code parts of this package are licensed mostly under:
 License: Artistic | GPL-1+

So if asked properly, upstream may not say GFDL for ICONS and CSS.

Only document text data *.xml should use GFDL, IMHO.

Osamu

PS: Now Debian release notes and other DDP files use CSS inspired by
this CSS.  Since I wanted to document it in the upcoming debmake-doc
package properly, I came to check this license situation.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (99, 'testing'), (98, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages publican depends on:
ii  docbook-xml  4.5-7.2
ii  docbook-xsl  1.78.1+dfsg-1
ii  docbook-xsl-ns   1.78.1+dfsg-1
ii  docbook5-xml 5.0-2
ii  fop  1:1.1.dfsg2-1
ii  gettext  0.19.3-2
ii  libarchive-zip-perl  1.39-1
ii  libconfig-simple-perl4.59-6
ii  libdatetime-format-dateparse-perl0.05-1
ii  libdatetime-perl 2:1.12-1
ii  libdbd-sqlite3-perl  1.44-1
ii  libdbi-perl  1.631-3+b1
ii  libfile-copy-recursive-perl  0.38-1
ii  libfile-find-rule-perl   0.33-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-inplace-perl 0.20-1
ii  libfile-pushd-perl   1.009-1
ii  libfile-slurp-perl   .19-4
ii  libfile-which-perl   1.09-1
ii  libhtml-format-perl  2.11-1
ii  libhtml-formattext-withlinks-andtables-perl  0.02-1
ii  libhtml-formattext-withlinks-perl0.14-1
ii  libhtml-template-perl2.95-1
ii  libhtml-tree-perl5.03-1
ii  libhtml-wikiconverter-markdown-perl  0.06-1
ii  libhtml-wikiconverter-perl   0.68-2
ii  libimage-magick-perl [perlmagick]8:6.8.9.9-5
ii  libimage-size-perl   3.232-1
ii  libio-string-perl1.08-3
ii  liblingua-en-fathom-perl 1.15-1
ii  liblist-moreutils-perl   0.33-2+b1
ii  liblocale-maketext-gettext-perl  1.28-2
ii  liblocale-maketext-lexicon-perl  1.00-1
ii  liblocale-msgfmt-perl0.15-1
ii  liblocale-po-perl0.24-1
ii  librsvg2-bin 2.40.5-1
ii  libsort-versions-perl1.60-1
ii  libstring-similarity-perl1.04-1+b2
ii  libsyntax-highlight-engine-kate-perl 0.09+dfsg-1
ii  libtemplate-perl 2.24-1.2+b1
ii  libtext-csv-xs-perl  1.11-2
ii  libxml-libxml-perl   2.0116+dfsg-1+deb8u1
ii  libxml-libxslt-perl  1.92-1+b1
ii  libxml-simple-perl   2.20-1
ii  libxml-treebuilder-perl  

Bug#787784: Subject: xserver-xorg-core: xserver crashes with sis chipset

[Julien Cristau]

On Fri, Jun  5, 2015 at 01:58:55 +0200, Stéphane Blondon wrote:

> Package: xserver-xorg-core
> Version: 2:1.17.1-2
> Severity: important
> 
> 
> The xserver crashes with the latest version in testing version:
> xserver-xorg-core=2:1.17.1-2 xserver-xorg-video-vesa=1:2.3.3-1+b4
> 
> It works with:
> aptitude install xserver-xorg-core=2:1.16.4-1
> xserver-xorg-video-vesa=1:2.3.3-1+b3
> (forcing a downgrade to those versions fix the problem.)
> 
> The CPU architecure is x86 and the video chipset is a SiS.
> 
Sounds like a dupe of #787144
> 
> [ 19346.935] (II) VESA(0): initializing int10
> [ 19346.940] (EE) VESA(0): Cannot read int vect
> [ 19346.940] (II) UnloadModule: "vesa"

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#785642: [Pkg-mailman-hackers] Bug#785642: queue runner dies with uncaught UnicodeDecodeError

[Thijs Kinkhorst]

severity 785642 important
thanks

On Mon, May 18, 2015 19:18, Wouter Verhelst wrote:
> I received a message from one of my list admins that he couldn't send a
> mail to his list. Investigating turned up the following in
> /var/log/mailman/error:
>
> May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't
> decode byte 0xe9 in position 18: invalid continuation byte
> May 17 15:32:20 2015 (981) Traceback (most recent call last):
>   File "/var/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop
> self._onefile(msg, msgdata)
>   File "/var/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile
> keepqueued = self._dispose(mlist, msg, msgdata)
>   File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in
> _dispose
> more = self._dopipeline(mlist, msg, msgdata, pipeline)
>   File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in
> _dopipeline
> sys.modules[modname].process(mlist, msg, msgdata)
>   File "/var/lib/mailman/Mailman/Handlers/CookHeaders.py", line 239, in
> process
> i18ndesc = uheader(mlist, mlist.description, 'List-Id',
> maxlinelen=998)
>   File "/var/lib/mailman/Mailman/Handlers/CookHeaders.py", line 65, in
> uheader
> return Header(s, charset, maxlinelen, header_name, continuation_ws)
>   File "/usr/lib/python2.7/email/header.py", line 183, in __init__
> self.append(s, charset, errors)
>   File "/usr/lib/python2.7/email/header.py", line 267, in append
> ustr = unicode(s, incodec, errors)
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18:
> invalid continuation byte
>
> May 17 15:32:20 2015 (981) SHUNTING:
> 1431869540.389822+156779307d54473d0eb732994bb67eee95733285

This seems to be a bug in python-email rather than Mailman. I think it
doesn't make sense to set errors to "strict" rather than something like
"replace" when the intention is to parse stuff so free-formed, under-specd
and user-controlled as email.

Nonetheless, Mailman could override this upstream choice and contruct the
Header class with "replace". I will file a request upstream.


Cheers,
Thijs


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

Bug#787990: game-data-packager: implement mirror checking scheme

[Alexandre Detiste]

Package: game-data-packager
Version: 42
Severity: wishlist


Nothing last forever on the internet. (GeoCities, GoogleCode...)

The URL in .yaml files needs to be actively/passively monitored.

*) active monitoring: this would need a custom spider

*) passive monitoring: set-up a custom web server as a last-resort
   that is appended to the list of servers found in the .yaml file

   This server doesn't even need to store all the files;
   the missing one would be listed as 404 in access.log.

   At this point, the user would have already faced on or
   several other broken links, so an extra one isn't that ugly.

   ~~~

   Then the access.log on the server can be monitored with a
   cron job and a list of broken link regularly computed
   and emailed to gdp@packages.d.o
   (todo: check threshold, stuff it in a DB...).

   I really don't care about gathering IP addresses of random
   g-d-p users; this can be hosted anywhere.

(see attached flowchart)

Alexandre



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

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

Versions of packages game-data-packager depends on:
ii  fakeroot1.20.2-1
ii  python3 3.4.2-2
ii  python3-debian  0.1.27
ii  python3-yaml3.11-2
pn  python3:any 

game-data-packager recommends no packages.

Versions of packages game-data-packager suggests:
ii  arj   3.10.22-13
ii  binutils  2.25-8
ii  cabextract1.6-1
ii  cdparanoia3.10.2+debian-11
ii  dynamite  0.1.1-2
ii  gcc   4:4.9.2-4
ii  gir1.2-gtk-3.03.14.5-1
ii  gir1.2-pango-1.0  1.36.8-3
ii  innoextract   1.4-1+b1
ii  lgc-pg1.2.6-1
ii  lhasa [lzh-archiver]  0.3.0-2
ii  make  4.0-8.1
ii  p7zip-full9.20.1~dfsg.1-4.1
ii  python3-gi3.14.0-1
ii  unace-nonfree 2.5-8
pn  unrar-nonfree 
ii  unshield  1.0-1
ii  unzip 6.0-17
ii  vorbis-tools  1.4.0-6

-- Configuration Files:
/etc/game-data-packager.conf changed [not included]

-- no debconf information


mirror_qa.pdf
Description: Adobe PDF document

Bug#787991: ITP: gmt-dcw -- Digital Chart of the World (DCW) for GMT

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: gmt-dcw
  Version : 1.1.1
  Upstream Author : Paul Wessel 
* URL : http://www.soest.hawaii.edu/pwessel/dcw/index.html
* License : LGPL-3+
  Programming Lang: N/A
  Description : Digital Chart of the World (DCW) for GMT

DCW-GMT is an enhancement to the original 1:1,000,000 scale vector basemap
of the world available from the Princeton University Digital Map and
Geospatial Information Center and from GeoCommunity at
http://data.geocomm.com/readme/dcw/dcw.html.
This data is for use by GMT, the Generic Mapping Tools.


The package is required for GMT 5 and will be maintained along with the
other gmt packages in the Debian GIS team.


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

Bug#787241: closed by Julien Cristau (Re: Bug#787241: xserver-xorg-video-intel: VT never returns from powersave on Haswell)

[Stephen Kitt]

Control: reopen -1
Control: reassign -1 xserver-xorg-video-intel
Control: found -1 xserver-xorg-video-intel/2:2.99.917-1
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=90804

Hi Julien,

On Sun, 07 Jun 2015 14:12:07 +, ow...@bugs.debian.org (Debian Bug
Tracking System) wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the xfce4-power-manager package:
> 
> #787241: xserver-xorg-video-intel: VT never returns from powersave on
> Haswell
> 
> It has been closed by Julien Cristau .

I'm the original submitter of the bug, and I'm still seeing it, without
xfce4-power-manager being involved.

Regards,

Stephen


pgpSoA6nc3Har.pgp
Description: OpenPGP digital signature

Bug#787960: libcurl3-gnutls: breaks bti

[Vincent Lefevre]

On 2015-06-07 14:14:29 +0200, Alessandro Ghedini wrote:
> On dom, giu 07, 2015 at 01:44:36 +0200, Vincent Lefevre wrote:
> > Versions of packages libcurl3-gnutls depends on:
> >  [...]
> >  ii  libgnutls-deb0-28  3.3.14-2
> 
> Essentially you have installed an older version of libgnutls-deb0-28 (the
> current one is 3.3.15-5).

The reason is that 3.3.15-5 breaks wget:

xvii:~> wget  https://www.vinc17.net/
--2015-06-07 17:23:54--  https://www.vinc17.net/
Resolving www.vinc17.net (www.vinc17.net)... 92.243.22.117, 
2001:4b98:dc0:45:216:3eff:fe9b:eb2f
Connecting to www.vinc17.net (www.vinc17.net)|92.243.22.117|:443... connected.
zsh: segmentation fault (core dumped)  wget https://www.vinc17.net/

This is bug 784009.

> I think the problem is that the older libgnutls uses a different
> version of nettle (libnettle.so.4) than the one libcurl3-gnutls uses
> (libnettle.so.6), and they somehow interfere with each other since
> nettle doesn't use symbols versioning.
> 
> Could you update libgnutls-deb0-28 and see what happens?

It works.

> In any case it doesn't look like a libcurl bug, although maybe the
> versioned depends on libgnutls could be strengthened (it's currently
> calculated automatically by dpkg-shlibdeps).

The missing versioned dependency is a bug, in particular when there is
a legitimate reason to block some broken version (see above). And users
don't always do full upgrade at the same time.

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


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

Bug#787875: steadyflow: FTBFS with valac 0.28

[Rodolphe PELLOUX-PRAYER]

Package: steadyflow
Version: 0.2.0-1.1
Followup-For: Bug #787875

Dear Maintainer,

Please apply the attached patch to fix this ftbfs.

Regards,
Rodolphe

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

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

Versions of packages steadyflow depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gvfs-backends1.24.1-2+b1
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-18
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libgee2  0.6.8-2
ii  libglib2.0-0 2.44.1-1
ii  libgtk-3-0   3.14.5-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3

steadyflow recommends no packages.

steadyflow suggests no packages.

-- no debconf information
>From 8a69e5adedc64aaf8c16ffb7c8e8cf23b416c5a8 Mon Sep 17 00:00:00 2001
From: Rodolphe PELLOUX-PRAYER 
Date: Sun, 7 Jun 2015 16:33:27 +0200
Subject: [PATCH] Fix ambiguous references between GLib.ListStore and
 Gtk.ListStore GLib.ListStore is a new class in GIO and creates a conflict in
 Vala 0.28.

Closes: #787875
---
 ...us-references-between-GLib.ListStore-and-.patch | 33 ++
 debian/patches/series  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch

diff --git a/debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch b/debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
new file mode 100644
index 000..6e94cd9
--- /dev/null
+++ b/debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
@@ -0,0 +1,33 @@
+From: Rodolphe PELLOUX-PRAYER 
+Date: Sun, 7 Jun 2015 16:31:32 +0200
+Subject: Fix ambiguous references between GLib.ListStore and Gtk.ListStore
+
+GLib.ListStore is a new class in GIO and creates a conflict in Vala 0.28
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787875
+---
+ Steadyflow/FileListController.vala | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Steadyflow/FileListController.vala b/Steadyflow/FileListController.vala
+index 43a65c4..ae71222 100644
+--- a/Steadyflow/FileListController.vala
 b/Steadyflow/FileListController.vala
+@@ -27,7 +27,7 @@ public class FileListController : GLib.Object {
+ 	private static const double REDRAW_SEC = 0.2;
+ 
+ 	private TreeView tree;
+-	private ListStore model;
++	private Gtk.ListStore model;
+ 	private string filter = "";
+ 	private Timer redraw_timer;
+ 
+@@ -46,7 +46,7 @@ public class FileListController : GLib.Object {
+ 		column.pack_start (renderer, true);
+ 		column.set_cell_data_func (renderer, set_cell_data);
+ 		
+-		model = new ListStore.newv ({ typeof (IDownloadFile) });
++		model = new Gtk.ListStore.newv ({ typeof (IDownloadFile) });
+ 		tree.set_model (model);
+ 		tree.append_column (column);
+ 		
diff --git a/debian/patches/series b/debian/patches/series
index 288bc08..5ce2fd9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 fix-ambiguous-reference.patch
+0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
-- 
2.1.4

Bug#787994: ITP: gmt-gshhg -- Global Self-consistent Hierarchical High-resolution Geography (GSHHG)

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: gmt-gshhg
  Version : 2.3.4
  Upstream Author : Paul Wessel 
* URL : http://www.soest.hawaii.edu/pwessel/gshhg/index.html
* License : LGPL-3+
  Programming Lang: N/A
  Description : Global Self-consistent Hierarchical High-resolution 
Geography (GSHHG)

GSHHG is a high-resolution shoreline data set amalgamated from two databases:
Global Self-consistent Hierarchical High-resolution Shorelines (GSHHS) and
CIA World Data Bank II (WDBII). GSHHG contains vector descriptions at five
different resolutions of land outlines, lakes, rivers, and political
boundaries. This data is for use by GMT, the Generic Mapping Tools.


This package replaces gmt-gshhs and is required for GMT 5, it will be
maintained along with the other gmt packages in the Debian GIS team.


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

Bug#787995: lrzsz: please make the build reproducible

[Dhole]

Source: lrzsz
Version: 0.12.21-7
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch removes extra timestamps from the gzip files and
sets the files mtime to a known value (last debian package changelog
date) before calling `dpkg --build` to generate the binary packages.
Once applied, lrzsz can be built reproducibly in our current
experimental framework.

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

-- 
Dhole
diff --git a/lrzsz-0.12.21/debian/rules b/lrzsz-0.12.21/debian/rules
index c24655b..8a75cbc 100755
--- a/lrzsz-0.12.21/debian/rules
+++ b/lrzsz-0.12.21/debian/rules
@@ -13,6 +13,7 @@ endif
 CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS   = $(shell dpkg-buildflags --get CFLAGS)
 LDFLAGS  = $(shell dpkg-buildflags --get LDFLAGS)
+BUILD_DATE=$(shell dpkg-parsechangelog --show-field Date)
 export CPPFLAGS
 export CFLAGS
 export LDFLAGS
@@ -60,9 +61,9 @@ endif
install -p -m 0644 -D ChangeLog debian/tmp/usr/share/doc/lrzsz/changelog
install -p -m 0644 -D debian/changelog 
debian/tmp/usr/share/doc/lrzsz/changelog.Debian
 
-   find debian/tmp/usr/share/man -type f -print0 | xargs -0 gzip -9
+   find debian/tmp/usr/share/man -type f -print0 | xargs -0 gzip -9n
find debian/tmp/usr/share/doc -type f ! -name copyright ! -name 
'*.html' \
-   \( -name 'changelog*' -o -size +8 \) -print0 | xargs -0 gzip -9
+   \( -name 'changelog*' -o -size +8 \) -print0 | xargs -0 gzip -9n
 
ln -s rz.1.gz debian/tmp/usr/share/man/man1/rb.1.gz
ln -s rz.1.gz debian/tmp/usr/share/man/man1/rx.1.gz
@@ -78,6 +79,8 @@ endif
 
dpkg-shlibdeps debian/tmp/usr/bin/*
dpkg-gencontrol -isp -plrzsz
+   find debian/tmp -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build debian/tmp ..
 
 binary-indep:


signature.asc
Description: OpenPGP digital signature

Bug#643697: libdbd-mock-perl: mock sessions no longer return results

[gregor herrmann]

Version: 1.45-1

On Wed, 28 Sep 2011 14:44:56 -0400, Frédéric Brière wrote:

> Package: libdbd-mock-perl
> Version: 1.41-1
> Severity: normal
> 
> The attached script illustrates the problem.

According to the upstream ticket at
https://rt.cpan.org/Public/Bug/Display.html?id=71438 , this problem
should be fixed with 1.45. Closing the bug accordingly.


Cheers,
gregor 


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bob Dylan: Knocking on Heavens Door


signature.asc
Description: Digital Signature

Bug#787996: cloop: please make the build reproducible

[Dhole]

Source: cloop
Version: 3.14.1.2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch tells tar to set the files timestamps to a known
value (last debian package changelog date). Once applied, cloop can be
built reproducibly in our current experimental framework.

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

-- 
Dhole
diff --git a/cloop-3.14.1.2/debian/rules b/cloop-3.14.1.2/debian/rules
index 80a8480..6e33449 100755
--- a/cloop-3.14.1.2/debian/rules
+++ b/cloop-3.14.1.2/debian/rules
@@ -7,6 +7,7 @@ include /usr/share/dpkg/architecture.mk
 CFLAGS += -flto
 CXXFLAGS += -flto
 LDFLAGS += -flto
+BUILD_DATE := $(shell dpkg-parsechangelog --show-field=Date)
 
 XDIR=debian/cloop-src/usr/src/modules/cloop
 
@@ -28,4 +29,4 @@ override_dh_auto_install:
cp Makefile *.c *.h README ChangeLog $(XDIR)
cd debian && install rules.m-a ../$(XDIR)/debian/rules && cp -r po 
compat control* copyright *_KVERS_* README.Debian changelog ../$(XDIR)/debian
dh_fixperms -i -Xrules
-   cd debian/cloop-src/usr/src && XZ_OPT=-9 tar --xz -c -f cloop.tar.xz 
modules && rm -rf modules
+   cd debian/cloop-src/usr/src && XZ_OPT=-9 tar --xz -c 
--mtime="$(BUILD_DATE)" -f cloop.tar.xz modules && rm -rf modules


signature.asc
Description: OpenPGP digital signature

Bug#787998: perdition: please make the build reproducible

[Dhole]

Source: perdition
Version: 2.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch removes extra timestamps from the gzip files. Once
applied, perdition can be built reproducibly in our current experimental
framework.

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

-- 
Dhole
diff --git a/perdition-2.1/debian/rules b/perdition-2.1/debian/rules
index 542c195..a018e65 100755
--- a/perdition-2.1/debian/rules
+++ b/perdition-2.1/debian/rules
@@ -61,22 +61,22 @@ install: build
chmod 755 $(pwd)/debian/tmp/usr/share/doc/perdition
install -c -m 644 perdition/db/nis/README.perditiondb_nis \
  $(pwd)/debian/tmp/usr/share/doc/perdition/README.perditiondb_nis
-   gzip --best \
+   gzip --best -n \
  $(pwd)/debian/tmp/usr/share/doc/perdition/README.perditiondb_nis
install -c -m 644 README \
  $(pwd)/debian/tmp/usr/share/doc/perdition/README
-   gzip --best $(pwd)/debian/tmp/usr/share/doc/perdition/README
+   gzip --best -n $(pwd)/debian/tmp/usr/share/doc/perdition/README
install -c -m 644 ChangeLog \
  $(pwd)/debian/tmp/usr/share/doc/perdition/changelog
-   gzip --best $(pwd)/debian/tmp/usr/share/doc/perdition/changelog
+   gzip --best -n $(pwd)/debian/tmp/usr/share/doc/perdition/changelog
install -c -m 644 TODO \
  $(pwd)/debian/tmp/usr/share/doc/perdition/TODO
-   gzip --best $(pwd)/debian/tmp/usr/share/doc/perdition/TODO
+   gzip --best -n $(pwd)/debian/tmp/usr/share/doc/perdition/TODO
 
mkdir -p $(pwd)/debian/tmp/usr/share/doc/perdition-ldap
install -c -m 644 perdition/db/ldap/perdition.schema \
  $(pwd)/debian/tmp/usr/share/doc/perdition-ldap/perdition.schema
-   gzip --best \
+   gzip --best -n \
  $(pwd)/debian/tmp/usr/share/doc/perdition-ldap/perdition.schema
 
dh_movefiles --source=debian/tmp


signature.asc
Description: OpenPGP digital signature

Bug#787997: scotch: please make the build reproducible

[Dhole]

Source: scotch
Version: 5.1.12b.dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch removes extra timestamps from the gzip files. Once
applied, scotch can be built reproducibly in our current experimental
framework.

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

-- 
Dhole
diff --git a/scotch-5.1.12b.dfsg/debian/rules b/scotch-5.1.12b.dfsg/debian/rules
index 1b5dd0d..c1364cd 100755
--- a/scotch-5.1.12b.dfsg/debian/rules
+++ b/scotch-5.1.12b.dfsg/debian/rules
@@ -117,7 +117,7 @@ install: build
cp debian/ptscotch_esmumps.1 int/share/man/man1 
 #  Fix lintian warnings
for file in $(shell ls int/bin); do \
-  (cd int/share/man/man1 && gzip -9 $$file.1); \
+  (cd int/share/man/man1 && gzip -9n $$file.1); \
done
 
for file in $(shell ls int/bin); do \


signature.asc
Description: OpenPGP digital signature

Bug#787999: libwebcam: please make the build reproducible

[Dhole]

Source: libwebcam
Version: 0.2.4-1.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch removes extra timestamps from the gzip files. Once
applied, libwebcam can be built reproducibly in our current experimental
framework.

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

-- 
Dhole
Description: Make libwebcam build reproducible
 The following patch makes the calls to gzip discard the timestamp of files
 when compressing, so no time metadata is stored. This way the build becomes
 reproducible.
 .
 libwebcam (0.2.4-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Removes timestamps from gzip
Author: Dhole 
Bug-Debian: https://bugs.debian.org/770982

---

--- libwebcam-0.2.4.orig/uvcdynctrl/CMakeLists.txt
+++ libwebcam-0.2.4/uvcdynctrl/CMakeLists.txt
@@ -58,7 +58,7 @@ add_definitions (-DHAVE_CONFIG_H)
 
 #create man pages
 execute_process (
-   COMMAND sh -c "rm -f ${CMAKE_CURRENT_BINARY_DIR}/*.gz; 
cp ${CMAKE_CURRENT_SOURCE_DIR}/uvcdynctrl.1_ 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl.1; cp 
${CMAKE_CURRENT_SOURCE_DIR}/uvcdynctrl.1_ 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl-${UVCDYNCTRL_VERSION}.1; gzip --best 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl-${UVCDYNCTRL_VERSION}.1; gzip --best 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl.1;"
+   COMMAND sh -c "rm -f ${CMAKE_CURRENT_BINARY_DIR}/*.gz; 
cp ${CMAKE_CURRENT_SOURCE_DIR}/uvcdynctrl.1_ 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl.1; cp 
${CMAKE_CURRENT_SOURCE_DIR}/uvcdynctrl.1_ 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl-${UVCDYNCTRL_VERSION}.1; gzip --best -n 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl-${UVCDYNCTRL_VERSION}.1; gzip --best -n 
${CMAKE_CURRENT_BINARY_DIR}/uvcdynctrl.1;"
RESULT_VARIABLE MAN_BUILD_RESULT

 )


signature.asc
Description: OpenPGP digital signature

Bug#788000: libranlip: please make the build reproducible

[Dhole]

Source: libranlip
Version: 1.0-4.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch removes extra timestamps from the gzip files and
sets the files mtime to a known value (last debian package changelog
date) before calling `dpkg --build` to generate the binary packages.
Once applied, libranlip can be built reproducibly in our current
experimental framework.

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

-- 
Dhole
diff --git a/libranlip-1.0/Makefile.in b/libranlip-1.0/Makefile.in
index df35f5d..8225ad4 100644
--- a/libranlip-1.0/Makefile.in
+++ b/libranlip-1.0/Makefile.in
@@ -409,7 +409,7 @@ am__remove_distdir = \
 || { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
  && rm -fr $(distdir); }; }
 
-GZIP_ENV = --best
+GZIP_ENV = --best -n
 distuninstallcheck_listfiles = find . -type f -print
 distcleancheck_listfiles = find . -type f -print
 
diff --git a/libranlip-1.0/debian/rules b/libranlip-1.0/debian/rules
index 6ca7323..9f389e3 100755
--- a/libranlip-1.0/debian/rules
+++ b/libranlip-1.0/debian/rules
@@ -3,6 +3,7 @@
 # Copyright (c) 2005 Juan Esteban Monsalve Tobon 
 
 STRIP  = strip --remove-section=.comment --remove-section=.note
+BUILD_DATE=$(shell dpkg-parsechangelog --show-field Date)
 
 build:
$(checkdir)
@@ -54,7 +55,7 @@ binary-arch: checkroot build
cp -p debian/changelog 
debian/libranlip1c2/usr/share/doc/libranlip1c2/changelog.Debian
cp -p docs/ranlip.ps debian/libranlip1c2/usr/share/doc/libranlip1c2/
cp -p examples/ranliptest* examples/makefile 
debian/libranlip1c2/usr/share/doc/libranlip1c2/examples
-   cd debian/libranlip1c2/usr/share/doc/libranlip1c2 && gzip -9 
changelog.Debian ranlip.ps examples/*
+   cd debian/libranlip1c2/usr/share/doc/libranlip1c2 && gzip -9n 
changelog.Debian ranlip.ps examples/*
 
ln -s libranlip1c2 debian/libranlip-dev/usr/share/doc/libranlip-dev
 
@@ -64,6 +65,8 @@ binary-arch: checkroot build
chown -R root.root debian/libranlip1c2
chmod -x debian/libranlip1c2/usr/lib/ranlip/*
chmod -R go=rX debian/libranlip1c2
+   find debian/libranlip1c2 -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build debian/libranlip1c2 ..
 
dpkg-gencontrol -isp -plibranlip-dev -Pdebian/libranlip-dev
@@ -71,6 +74,8 @@ binary-arch: checkroot build
chown -R root.root debian/libranlip-dev
chmod -x debian/libranlip-dev/usr/lib/ranlip/libranlip.a 
debian/libranlip-dev/usr/lib/ranlip/libranlip.la
chmod -R go=rX debian/libranlip-dev
+   find debian/libranlip-dev -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build debian/libranlip-dev ..
 
 define checkdir


signature.asc
Description: OpenPGP digital signature

Bug#788001: libf2c2: please make the build reproducible

[Dhole]

Source: libf2c2
Version: 1.0-4.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Hi!

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

The attached patch sets the files mtime to a known value (last debian
package changelog date) before calling `dpkg --build` to generate the
binary packages. Once applied, libf2c2 can be built reproducibly in our
current experimental framework.

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

-- 
Dhole
diff --git a/libf2c2-20090411/debian/rules b/libf2c2-20090411/debian/rules
index 3081474..2354c5f 100755
--- a/libf2c2-20090411/debian/rules
+++ b/libf2c2-20090411/debian/rules
@@ -10,6 +10,7 @@ prefix-dev=debian/libf2c2-dev
 prefix=debian/libf2c2
 
 DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+BUILD_DATE=$(shell dpkg-parsechangelog --show-field Date)
 
 dir=$(package)-$(version)
 file=$(package)_$(version)-$(debian)
@@ -144,7 +145,11 @@ endif
chown -R root.root ${prefix}
chmod -R go-ws ${prefix-dev}
chmod -R go-ws ${prefix}
+   find ${prefix-dev} -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build ${prefix-dev}  ..
+   find ${prefix} -depth -newermt '$(BUILD_DATE)' -print0 | \
+   xargs -0r touch --no-dereference --date='$(BUILD_DATE)'
dpkg --build ${prefix}  ..
 
 


signature.asc
Description: OpenPGP digital signature

Bug#784709: [PATCH] use lsblk to attemp to guess partition's fs type

[Ben Hutchings]

On Sun, 2015-06-07 at 15:51 +0200, Philippe Coval wrote:
> If not found it will fallback to use other tools.
> 
> Note that fs_type function is not expected to return error code
> different than zero even if it failed to detect type.
> 
> If filesystem is undermined then "NOT-DETECTED" will be echoed.
> 
> This change will prevent mount to hang on extended part (#768902)
[...]

Please fix blkid instead of working around it.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Bug#787877: clinica: FTBFS with valac 0.28

[Rodolphe PELLOUX-PRAYER]

Source: clinica
Followup-For: Bug #787877

Dear Maintainer,

Please apply the attached patch to fix this ftbfs.

Regards,
Rodolphe

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

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 7a27775901a43fb52d24323a1432f0b22281837d Mon Sep 17 00:00:00 2001
From: Rodolphe PELLOUX-PRAYER 
Date: Sun, 7 Jun 2015 18:09:01 +0200
Subject: [PATCH] Fix ambiguous references between GLib.ListStore and
 Gtk.ListStore GLib.ListStore is a new class in GIO and creates a conflict in
 Vala 0.28.

Closes: #787877
---
 ...us-references-between-GLib.ListStore-and-.patch | 87 ++
 debian/patches/series  |  1 +
 2 files changed, 88 insertions(+)
 create mode 100644 debian/patches/0001-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/0001-Fix-ambiguous-references-between-GLib.ListStore-and-.patch b/debian/patches/0001-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
new file mode 100644
index 000..d0d82d6
--- /dev/null
+++ b/debian/patches/0001-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
@@ -0,0 +1,87 @@
+From: Rodolphe PELLOUX-PRAYER 
+Date: Sun, 7 Jun 2015 18:07:19 +0200
+Subject: Fix ambiguous references between GLib.ListStore and Gtk.ListStore
+
+GLib.ListStore is a new class in GIO and creates a conflict in Vala 0.28
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787877
+---
+ libclinica/DoctorListStore.vala  | 2 +-
+ libclinica/EventListStore.vala   | 2 +-
+ libclinica/MedicineTreeView.vala | 4 ++--
+ libclinica/PatientListStore.vala | 2 +-
+ libclinica/VisitListStore.vala   | 2 +-
+ 5 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/libclinica/DoctorListStore.vala b/libclinica/DoctorListStore.vala
+index e87237b..ca63f36 100644
+--- a/libclinica/DoctorListStore.vala
 b/libclinica/DoctorListStore.vala
+@@ -22,7 +22,7 @@ using Gtk;
+ 
+ namespace Clinica {
+ 
+-public class DoctorListStore : ListStore {
++public class DoctorListStore : Gtk.ListStore {
+ 
+ 	enum Field {
+ 		DOCTOR,
+diff --git a/libclinica/EventListStore.vala b/libclinica/EventListStore.vala
+index 74bf4c1..83edac1 100644
+--- a/libclinica/EventListStore.vala
 b/libclinica/EventListStore.vala
+@@ -22,7 +22,7 @@
+  
+  namespace Clinica {
+ 
+-public class EventListStore : ListStore {
++public class EventListStore : Gtk.ListStore {
+ 
+ /**
+  * @brief Fields present in the store, i.e. header of
+diff --git a/libclinica/MedicineTreeView.vala b/libclinica/MedicineTreeView.vala
+index fac4b99..bc17e81 100644
+--- a/libclinica/MedicineTreeView.vala
 b/libclinica/MedicineTreeView.vala
+@@ -23,13 +23,13 @@ namespace Clinica {
+ 
+ public class MedicineTreeView : Gtk.TreeView {
+ 
+-private ListStore medicine_store { get; set; }
++private Gtk.ListStore medicine_store { get; set; }
+ 
+ private ResourceManager resource_manager { get; set; }
+ 
+ public MedicineTreeView (ResourceManager resources) {
+ resource_manager = resources;
+-medicine_store = new ListStore (3, typeof (string), typeof (string), typeof (Medicine));
++medicine_store = new Gtk.ListStore (3, typeof (string), typeof (string), typeof (Medicine));
+ set_model (medicine_store);
+ 
+ /* Create necessary columns */
+diff --git a/libclinica/PatientListStore.vala b/libclinica/PatientListStore.vala
+index f09a7f0..054c89d 100644
+--- a/libclinica/PatientListStore.vala
 b/libclinica/PatientListStore.vala
+@@ -22,7 +22,7 @@ using Gtk;
+ 
+ namespace Clinica {
+ 
+-public class PatientListStore : ListStore {
++public class PatientListStore : Gtk.ListStore {
+ 
+ 	enum Field {
+ 		PATIENT,
+diff --git a/libclinica/VisitListStore.vala b/libclinica/VisitListStore.vala
+index 33b74a3..705e93f 100644
+--- a/libclinica/VisitListStore.vala
 b/libclinica/VisitListStore.vala
+@@ -22,7 +22,7 @@ using Gtk;
+ 
+ namespace Clinica {
+ 
+-	public class VisitListStore : ListStore {
++	public class VisitListStore : Gtk.ListStore {
+ 	
+ 		enum Field {
+ 			VISIT,
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..67634fd
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
-- 
2.1.4

Bug#788002: easytag: crashes when opening a directory containing an mp3 with a long comment

[Anne C. Hanna]

Package: easytag
Version: 1:2.2.6-dmo1
everity: normal

When I open a directory containing an mp3 with a long comment, easytag crashes
with the following message:


(easytag:20858): Gdk-ERROR **: The program 'easytag' received an X Window System
error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 18615 error_code 11 request_code 130 (MIT-SHM) minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


Sometimes the error doesn't happen until I change from the directory with the
problematic file in it to another directory, but if I include the directory name
in the command line when starting easytag, easytag always crashes during
scanning of the directory.

The podcast at the following link reliably causes the crash for me:

http://traffic.libsyn.com/starshipsofa/StarShipSofa_No_389_George_R._R._Martin.mp3

 - Anne


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

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

Versions of packages easytag depends on:
ii  libc6   2.19-18
ii  libflac81.3.1-2
ii  libgcc1 1:5.1.1-8
ii  libgdk-pixbuf2.0-0  2.31.4-2
ii  libglib2.0-02.44.1-1
ii  libgtk-3-0  3.14.5-1
ii  libid3-3.8.3c2a 3.8.3-16
ii  libid3tag0  0.15.1b-11
ii  libogg0 1.3.2-1
ii  libopus01.1-2
ii  libopusfile00.6-1
ii  libpango-1.0-0  1.36.8-3
ii  libspeex1   1.2~rc1.2-1
ii  libstdc++6  5.1.1-8
ii  libtag-extras1  1.0.1-3
ii  libtag1c2a  1.9.1-2.1
ii  libvorbis0a 1.3.4-2
ii  libvorbisfile3  1.3.4-2
ii  libwavpack1 4.70.0-1

easytag recommends no packages.

easytag 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#783683: cron started with -f (foreground), killing processes on restart

[Christian Kastner]

Hi,

On 2015-06-06 21:33, Christoph Berg wrote:
> Re: Christian Kastner 2015-05-03 <554626d8.4090...@kvr.at>
 I'd strongly opt to change the KillMode as mentioned above.
 #debian-devel seems to agree, so I'm upgrading this bug to RC.
 (critical as it's killing "random" processes)
>>>
>>> A particular reason why the current behavior is bad is that it is
>>> common practise to start user daemons using @reboot cronjobs.
>>
>> I was wondering what the use case for this was, but that seems plausible.
>>
>> Regardless, I committed a fix for the sole fact that it's a significant
>> deviation from past behavior, as you pointed out.
>>
>> I've prepared packages for both jessie and unstable.
> 
> I had hoped to see this fixed in today's point release. What happened
> with the jessie package?

I'm afraid I couldn't get a hold of Javier regarding an upload. I myself
don't have upload rights yet.

I meant to take care of this before I went AFK for the weekend, but I
forgot about this :-/ If an upload to jessie-p-u is still a possibility
and you'd like to sponsor, a package for jessie has been prepared on the
"jessie" branch. It was already ACKed by the RT, see #785573.

Regards,
Christian


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

Bug#788003: smokeping package fails to run with fping

[Bernd Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: smokeping
Version: 2.6.8-2

When I install `smokeping` via `apt-get` the daemon fails to start,
cause of
"""
Starting latency logger daemon: smokepingERROR:
/etc/smokeping/config.d/Probes, line 5: ERROR: FPing 'binary' does not
point to an executable
"""

This is quiet a minor bug:

$ grep fping /etc/smokeping/config.d/Probes
binary = /usr/bin/fping
$ which fping
/usr/local/sbin/fping

This should be fixed easily.

Another thing is the ownership of produced rrd-files. They are created
for 'root' but I think 'smokeping:www-data' might be suites better.

I'm running Debian Wheezy.

- -- 
Bernd Naumann 

PGP:   0xA150A04F via pool.sks-keyservers.net
XMPP:  b...@weimarnetz.de

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJVdG/FAAoJEEYW3OihUKBPkiwQALOGhEmFeBhucASit+q48w0Z
B3zXRmvI0ovxWAareqaQu3RdRhE+GygaOXKArp42099ediBZrHMy8ZlqhRuDQ/19
sVW73hsTV0SbspOHA8wcTxnRj96W/A2eyi0jujh2CoDOB3wYuxg8BrjCSQAVGsjQ
2yOI38ITHt1/JeJcbaKJePeywbO4lTb92k2wSWLHGjIcqjohPRfYXFdNsoD67Xbi
ZkaP4rrwbu8Xl/mRt5HRuoB6jc4H4POxIf+aFsUvxnntGhhNznq2EMUwc6QC2YTD
Du6Lj+IczJrGicxuR5+A9ipVr5KFo6aIb/AQiBVV7ienUe8Sz8lkBihayofiUuaN
qZOsPutwT/3nw7ENlJ0DUM5o/J6rcbOJY1ydPAEop7yzz5byFlXP3AIxxeReZ5Qe
ZtyYndG1dTprn2w7oRyfTpDV6tXyRH9NeEQ20zFNWrZ712GIROspcmlml0Ghutbw
EI436KQ59T8XR/4XJQo6JP73KaNUlBPO6U1nmDy4MC/QZwG7PykA1Pj+a64Ptn5v
A3VdsCxcjUODh/PW3KAhNT6TJEjP8p7+TGlcIeDkNxdipR3BQOerwlKefeuR2k80
O/wsoeN6/JWgMW4YRCsZVL3tc3ePaXpTAy3TIt1SwzM5Uhurd2lKtaaNZGt0c2EX
V+ZQG2ZKBE0tso2Sq8aw
=p8xS
-END PGP SIGNATURE-


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

Bug#787989: multistrap: fails with suite jessie and stretch (sid works)

[Neil Williams]

tag 787989 + moreinfo
thanks

On Sun, 07 Jun 2015 15:58:13 +0200
Johannes Schauer  wrote:

> Package: multistrap
> Version: 2.2.1
> Severity: normal
> 
>   packages=apt
>   source=http://http.debian.net/debian
>   keyring=debian-archive-keyring
>   suite=jessie
> 
> then I'll get the following error:
> 
>   Setting up systemd (215-17+deb8u1) ...
>   Failed to read /proc/cmdline. Ignoring: No such file or
> directory Failed to open /dev/urandom: Function not implemented
>   dpkg: error processing package systemd (--configure):
>subprocess installed post-installation script returned error
> exit status 1 Setting up dmsetup (2:1.02.90-2.2) ...
>   dpkg: dependency problems prevent configuration of
> systemd-sysv: systemd-sysv depends on systemd; however:
> Package systemd is not configured yet.
>systemd-sysv depends on systemd (= 215-17+deb8u1); however:
> Package systemd is not configured yet.

Generally, package failures are due to issues within the package, not
bugs in multistrap. This looks especially likely as an upgrade of a
package in sid does not show the same problem.

multistrap isn't doing anything different for the different suites
other than pulling different versions of the packages. It's possible
that the update (at this stage, it's not even clear which package is at
fault) in sid will make it into a future point release of Jessie.
Stretch will, presumably, fix itself as the testing migrations continue.

>   ERR: dpkg configure reported an error.
>   Native mode configuration reported an error!
>   I: Tidying up apt cache and list data.
>   
>   Multistrap system reported 1 error
> in /home/josch/annex/personal/projects/lxc-multistrap/multitest/. I:
> Tidying up apt cache and list data.
> 
> The full log is attached.
> 
> When replacing jessie by stretch, the problem is the same.
> 
> When replacing jessie by sid, then multistrap works fine.

It might be worth investigating whether the jessie / stretch chroots can
be configured manually and what steps are required to do so.

In the absence of information on what multistrap could actually have
done and why packages in sid "just work", there isn't much that can be
done with this report.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpY1FcxN3R4P.pgp
Description: OpenPGP digital signature

Bug#783074: flash-kernel: improvements to uboot-generic bootscript

[Vagrant Cascadian]

On 2015-06-07, Ian Campbell wrote:
> On Mon, 2015-05-04 at 12:01 -0700, Vagrant Cascadian wrote:
>> I can confirm that wandboard, cubox-i and hummingboard all default to
>> console=ttymxc0, and several other boards by grepping through u-boot's
>> include/configs. Some actually do "setenv bootargs
>> console=ttymxc0,${baudrate}" before their various boot commands.
>> 
>> If you prefer a more specific comment, maybe "Workaround lack of
>> baudrate included with console on various iMX systems (e.g. wandboard,
>> cubox-i, hummingboard)." An exhaustive list might prove more trouble
>> than it's worth. :)
>
> For sure!
>
> I was thinking about this some more and it occurred to me that
> console=ttymxc0 (or indeed any console=ttyFOO) ought really to be
> inheriting the existing baud rate etc settings from the bootloader and
> Just Work(tm).

It defaults to 9600 baud (u-boot defaults to 115200), and consequently
the serial console looks like gibberish.


> That lead me to drivers/tty/serial/imx.c:imx_console_get_options() in
> the kernel which is called if no options are given.
>
> That code has been there since the beginning of git history. Did you try
> with just console=ttymxc0 and it didn't work? (Sorry if this is a silly
> question, I think many people don't realise the baud etc is optional so
> it never gets tried).
>
> If you've tried without and it doesn't work then either that code isn't
> called when I think, or it is broken. In either case I'm not too
> inclined to investigate further than "does console=ttymxc0 work" and if
> not then apply that bit of the patch.

I haven't investigated the kernel code, but my experience shows that
without specifying the baud rate it defaults to 9600.

9600 baud seems a bit antiquated at this point... :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#783222: grun: upstream has moved to github

[Étienne Gilli]

Tags: patch

Hi,

Here's a patch to update the homepage.

Please let me know if there's any problem with this patch.
Thanks for this 'newcomer' bug!

Bye,

-- 
Étienne
Update upstream homepage (Closes: #783222).

diff -u grun-0.9.3/debian/control grun-0.9.3/debian/control
--- grun-0.9.3/debian/control
+++ grun-0.9.3/debian/control
@@ -5,7 +5,7 @@
 Build-Depends: debhelper (>> 5.0.0), autotools-dev, libgtk2.0-dev, gettext
 Build-Conflicts: libgtk1.2-dev
 Standards-Version: 3.7.3
-Homepage: http://grun.googlecode.com/
+Homepage: https://github.com/lrgc/grun
 
 Package: grun
 Architecture: any
diff -u grun-0.9.3/debian/changelog grun-0.9.3/debian/changelog
--- grun-0.9.3/debian/changelog
+++ grun-0.9.3/debian/changelog
@@ -1,3 +1,10 @@
+grun (0.9.3-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control: Update upstream homepage (Closes: #783222).
+
+ -- Étienne Gilli   Sun, 07 Jun 2015 16:39:44 +0200
+
 grun (0.9.3-1) unstable; urgency=low
 
   * New maintainer. Many thanks to oohara for all his previous work.


signature.asc
Description: Digital signature

Bug#787989: multistrap: fails with suite jessie and stretch (sid works)

[Johannes Schauer]

Hi,

Quoting Neil Williams (2015-06-07 18:31:07)
> It might be worth investigating whether the jessie / stretch chroots can be
> configured manually and what steps are required to do so.
> 
> In the absence of information on what multistrap could actually have
> done and why packages in sid "just work", there isn't much that can be done
> with this report.

adding a hook which adds /dev/random and /dev/urandom before package
configuration fixes this problem.

Is this the info you were asking for?

In a maybe related note: after filing this bug I also saw the configuration of
openssh-server fail because of a missing /dev/random. But I'm sure this used to
work earlier (about half a year ago) as I was calling
/usr/share/multistrap/device-table.pl in my setupscript and at least in the
past that used to be enough (and I don't think that openssh-server did not
require /dev/random to generate its private keys in the past).  Was the point
at which setupscripts are executed maybe changed in one of the recent
multistrap releases?

Anyway, both my problems are now fixed by creating the respective device nodes
in a native hook before configuration.

Maybe you want to add a jessie.conf with the right hook to multistrap just as
there is a sid.conf because I imagine that multistrap-ing Jessie might be
desired by more people than just me until Stretch is released?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#788004: [INTL:ca] Catalan debconf templates translation

[Innocent De Marchi]

Package: arb
Version: 6.0.2-1
Tags: l10n patch
Severity: wishlist


Hello,

 Please, update the Catalan debconf.po translation.

I. De Marchi


ca.po
Description: application/gettext

Bug#768524: Could you list what's missing?

[Tiago Bortoletto Vaz]

Hi Toby, it seems you're really busy and can't give the time needed to
finish the musescore package. That's fine, we're all volunteers here :)

So I'm asking you to make public what exactly is missing to get the
package done, then I (or others) can help you there and make many
musescore users happy in the next days. I will have some free time in
the next week and would love to dedicate some hours to push 2.0.1 to
Sid.

Bests,

-- 
tiago


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

Bug#787814: get-iplayer: unable to download anything

[James Bottomley]

On Fri, 05 Jun 2015 15:24:09 +0100 Peter J Ross  wrote:
> On Fri, 05 Jun 2015 12:04:52 +0100 =?utf-8?b?SnVoYSBKw6R5a2vDpA==?= 
>  wrote:
> > Not a SCALAR reference at /usr/bin/get-iplayer line 7099.
> 
> This has been fixed upstream in version 2.93.
> 
> Current upstream version is 2.94.

I confirm this.  Simply copying get_iplayer version 2.94 from the git
repository over the existing binary file makes everything work again.

Can we update the version please?  Having a non-working package doesn't
really help anyone.


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

Bug#787878: midori: FTBFS with valac 0.28

[Rodolphe PELLOUX-PRAYER]

Source: midori
Followup-For: Bug #787878

Dear Maintainer,

Please apply the attached patch to fix this ftbfs.

Regards,
Rodolphe

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

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 7cef18b2df4c75ed7bdd595ab214bc0b43cf49dd Mon Sep 17 00:00:00 2001
From: Rodolphe PELLOUX-PRAYER 
Date: Sun, 7 Jun 2015 18:44:32 +0200
Subject: [PATCH] Fix ambiguous references between GLib.ListStore and
 Gtk.ListStore GLib. ListStore is a new class in GIO and creates a conflict in
 Vala 0.28.

Closes: #787878
---
 ...us-references-between-GLib.ListStore-and-.patch | 33 ++
 debian/patches/series  |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch

diff --git a/debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch b/debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
new file mode 100644
index 000..6ffc391
--- /dev/null
+++ b/debian/patches/0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
@@ -0,0 +1,33 @@
+From: Rodolphe PELLOUX-PRAYER 
+Date: Sun, 7 Jun 2015 18:42:41 +0200
+Subject: Fix ambiguous references between GLib.ListStore and Gtk.ListStore
+
+GLib.ListStore is a new class in GIO and creates a conflict in Vala 0.28
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787878
+---
+ extensions/history-list.vala | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/extensions/history-list.vala b/extensions/history-list.vala
+index 44af649..ac5dcb2 100644
+--- a/extensions/history-list.vala
 b/extensions/history-list.vala
+@@ -265,7 +265,7 @@ namespace HistoryList {
+ }
+ 
+ private void create_widgets () {
+-ListStore model;
++Gtk.ListStore model;
+ TreeIter iter;
+ TreeIter? active_iter = null;
+ 
+@@ -277,7 +277,7 @@ namespace HistoryList {
+ 
+ var tab_closing_behavior = this.hl_manager.get_integer ("TabClosingBehavior");
+ 
+-model = new ListStore (2, typeof (string), typeof (int));
++model = new Gtk.ListStore (2, typeof (string), typeof (int));
+ 
+ model.append (out iter);
+ model.set (iter, TabClosingBehaviorModel.TEXT, _("Do nothing"),
diff --git a/debian/patches/series b/debian/patches/series
index 5367257..ba823fd 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 add-debian-searches
+0002-Fix-ambiguous-references-between-GLib.ListStore-and-.patch
-- 
2.1.4

Bug#788005: libfreerdp-plugins-standard: urbdrc-client.so missing (USB redirection)

[Lionel Elie Mamane]

Package: libfreerdp-plugins-standard
Version: 1.1.0~git20140921.1.440916e+dfsg1-4
Severity: normal

The client channel urbdrc, which is used for USB redirection is
missing.

$ xfreerdp /v:host /usb:id,dev:091e:260f
Loading Dynamic Virtual Channel urbdrc
LoadLibraryA: /usr/lib/x86_64-linux-gnu/freerdp/urbdrc-client.so: cannot open 
shared object file: No such file or directory



-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libfreerdp-plugins-standard depends on:
ii  libasound2   1.0.28-1
ii  libavcodec56 6:11.3-1+deb8u1
ii  libavutil54  6:11.3-1+deb8u1
ii  libc62.19-18
ii  libcups2 1.7.5-11
ii  libfreerdp-common1.1.0   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-utils1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libglib2.0-0 2.42.1-1
ii  libgstreamer-plugins-base0.10-0  0.10.36-2
ii  libgstreamer0.10-0   0.10.36-1.5
ii  libpcsclite1 1.8.13-1
ii  libpulse05.0-13
ii  libssl1.0.0  1.0.1k-3
ii  libwinpr-crt0.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-environment0.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-file0.1 1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-handle0.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-heap0.1 1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-interlocked0.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-library0.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-path0.1 1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-synch0.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-sysinfo0.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-thread0.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libwinpr-utils0.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxml2  2.9.1+dfsg1-5
ii  libxrandr2   2:1.4.2-1+b1
ii  zlib1g   1:1.2.8.dfsg-2+b1

libfreerdp-plugins-standard recommends no packages.

libfreerdp-plugins-standard 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#768524: Could you list what's missing?

[Toby St Clere Smithe]

Dear Tiago,

Many thanks for the offer. I've got to give a conference presentation
tomorrow, but after that's done, (I promise!) I will write up a list of
what's missing, including pushing my own changes to the pkg-multimedia
git repository. I'll send another message to this bug tomorrow night.

Best,

Toby

Tiago Bortoletto Vaz  writes:
> Hi Toby, it seems you're really busy and can't give the time needed to
> finish the musescore package. That's fine, we're all volunteers here :)
>
> So I'm asking you to make public what exactly is missing to get the
> package done, then I (or others) can help you there and make many
> musescore users happy in the next days. I will have some free time in
> the next week and would love to dedicate some hours to push 2.0.1 to
> Sid.
>
> Bests,


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

Bug#782475: Bug#787542: libudev1-udeb depends on missing libcap2

[Christian Kastner]

Hi all,

On 2015-06-03 00:02, Cyril Brulebois wrote:
> Michael Biebl  (2015-06-02):
>> Control: block -1 by 782475
>> Am 02.06.2015 um 18:11 schrieb Cyril Brulebois:
>>> libudev1-udeb depends on missing libcap2. I suspect the easiest would be
>>> to drop libcap2 support from the udeb build. An alternative would be to
>>> try and add a udeb in libcap2. I'd rather have the former happen, so
>>
>> Unfortunately, the libcap dependency is not really optional, i.e. it can
>> not be turned off with a --disable-libcap configure switch.
> 
> Yeah, I tried to briefly look at debian/rules and configure.ac…
> 
>> While we could try and hack the build system and ifdeffing this code
>> out, I'd much prefer if we didn't have to do that and simply build a
>> udeb for libcap
>>
>> Matthias already provided a patch for that [1].
>>
>> @Christian, you mentioned that you were ok with this patch and wanted to
>> include this in your next upload. Would be great if you can proceed with
>> the upload now that v220 is in unstable which depends on it.
> 
> Since Christian mentioned in his reply a fix might land this weekend,
> I'm fine with getting an extra udeb (provided it's small enough, which
> shouldn't be much of an issue for such a lib), especially since this has
> been tested in a derivative beforehands.

Sorry for the delay, I was AFK until just now.

I've prepared a quick upload consisting of only Matthias' patch, minus
the superfluous d/shlibs.local as discussed in Michael's follow-up to
the patch.

I do still need a sponsor, though. For whomever is willing to act as
such, a source package can be obtained from the following link,

http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-9.dsc

or, alternatively, via the git repo

git://anonscm.debian.org/collab-maint/libcap2.git

using gbp.

Please let me know if there is anything else I can do.

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#787989: multistrap: fails with suite jessie and stretch (sid works)

[Neil Williams]

tag 787989 - moreinfo
retitle 787989 add native hook to create /dev/random for jessie support
thanks

On Sun, 07 Jun 2015 18:44:10 +0200
Johannes Schauer  wrote:

> Quoting Neil Williams (2015-06-07 18:31:07)
> > It might be worth investigating whether the jessie / stretch
> > chroots can be configured manually and what steps are required to
> > do so.
> > 
> > In the absence of information on what multistrap could actually have
> > done and why packages in sid "just work", there isn't much that can
> > be done with this report.
> 
> adding a hook which adds /dev/random and /dev/urandom before package
> configuration fixes this problem.
> 
> Is this the info you were asking for?

Yes, absolutely. Thanks.
 
> In a maybe related note: after filing this bug I also saw the
> configuration of openssh-server fail because of a
> missing /dev/random. But I'm sure this used to work earlier (about
> half a year ago) as I was
> calling /usr/share/multistrap/device-table.pl in my setupscript and
> at least in the past that used to be enough (and I don't think that
> openssh-server did not require /dev/random to generate its private
> keys in the past).  Was the point at which setupscripts are executed
> maybe changed in one of the recent multistrap releases?

The actual multistrap script has not changed substantially since the
version in Jessie - some extra support scripts were removed and a patch
was applied for apt's Etc::Dir directive support.

> Anyway, both my problems are now fixed by creating the respective
> device nodes in a native hook before configuration.

Thanks, I'll look at a default hook for jessie (or an example hook to
add /dev/random to any suite) at that point.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpTdOW15jfXj.pgp
Description: OpenPGP digital signature

Bug#785642: [Pkg-mailman-hackers] Bug#785642: Bug#785642: queue runner dies with uncaught UnicodeDecodeError

[Thijs Kinkhorst]

Hoi Wouter,

I got some questions back from upstream, can you help?


Actually, the traceback says what's happening is CookHeaders is trying
to create the List-Id: header to be added to the message.

It tries to create a header of the form:

List-Id: list description 

And the exception occurs when trying to rfc 2047 encode the list's
description in the charset of the list's preferred language. This
exception should be occurring on every list post. Is that the case?

Also, what is the list's preferred_language and what is the raw value of
the list's description attribute. Obtain this info with something like:

$ bin/withlist list1
Loading list list1 (unlocked)
The variable `m' is the list1 MailList instance
>>> m.preferred_language
'en'
>>> m.description
'My List one'
>>>

(of course the list name and responses will be different in your case.)


Cheers,
Thijs


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