Bug#810603: Do you intend to upload soonish?

[Andreas Tille]

Hi Adrian,

you did respond quite quickly to Bas' bug report.  Do you intend to
upload soon?  I'm just asking to decide whether I inform the release
team about a pending transition which I did not yet so far since four
out of five affected packages are just uploaded and cen64-qt is the last
one.  If it would take longer than end of this week (for whatever reason
you might have) I'll go on and bother the release team with this
additional work to observe the transition which I would have liked to
save them otherwise.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#810871: [buildd-tools-devel] Bug#810871: Bug#810871: [sbuild] Please provide a way to set an environment variable to the build directory

[Johannes Schauer]

Hi,

Quoting Katsuhiko Nishimra (2016-01-14 04:53:37)
> On Thu, 14 Jan 2016 00:37:19 +0100 Johannes Schauer  wrote:
> > 
> > Is this documentation not working for you:
> > 
> > https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild
> 
> Yes, I've followed the instructions above and encountered cache misses.

I would like to understand why this fails now so I CC-ed Ian Campbell who seems
to be responsible for the last big overhaul of that section in the wiki.

sbuild has been choosing a randomized build path for a long time so I don't
know why it apparently doesn't work anymore all of a sudden.

Maybe something changed in more recent ccache versions?

> > If you just need a stable build path, is the --build-path option not
> > working for you?
> 
> Ah, it's one way.
> I haven't noticed that stable build paths are not a problem even in the
> case where parallel builds are invoked.
> 
> But, if we can specify something like 
>  $build_environment = { 'CCACHE_BASEDIR' => '%BUILD_DIR%'};
> is it more versatile?

Being able to use the percent escapes like this is not supported yet but I can
see how it could be useful to be able to do so. I'll think about it from a more
general perspective.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#810956: libimage-geometry0d: Package description seems to belong to another package

[Beatrice Torracca]

Package: libimage-geometry0d
Severity: minor

Hi!

package description reads:

«Description: camera_calibration_parsers Robot OS package
 This package is part of Robot OS (ROS). It contains routines for
 reading and writing camera calibration parameters.»

but the long description is the same of package libcamera-calibration-parsers0.

The same description is also in libcv-bridge0d.

I don't know the ROS packages but I think these might not be the
correct descriptions.

Thanks,

beatrice

Bug#803869: vtk6: FTBFS with FFmpeg 2.9

[Andreas Tille]

On Wed, Jan 13, 2016 at 11:26:46PM +0100, Andreas Cadhalpun wrote:
> On 13.01.2016 14:54, Andreas Tille wrote:
> > I pinged ftpmaster yesterday to consider accepting VTK.  Hope this
> > helps ...
> 
> Thanks. Unfortunately it got rejected meanwhile...

Anton promissed a re-upload with fixes - hope it does not take that
long again ... 

-- 
http://fam-tille.de

Bug#810955: ITP: golang-github-kennygrant-sanitize -- Functions for sanitizing text in golang strings

[Nathan Osman]

I completely forgot to mention that I have already created Debian 
packaging for the library and put it on Launchpad. You can view the 
source code here[1] or check out the branch with Bazaar using:


bzr branchlp:~hectane/hectane/golang-github-kennygrant-sanitize-debian

The Debian package is released under the MIT license but since I am the 
author, I can release it under another FOSS license if it makes things 
any easier.


[1]: 
http://bazaar.launchpad.net/~hectane/hectane/golang-github-kennygrant-sanitize-debian/files

Bug#810923: [Pkg-libvirt-maintainers] Bug#810923: virtinst: virt-install fails to create working ppc64 (& other non-native) VMs

[Guido Günther]

severity 810923 normal
reassigen 810923 qemu-system-ppc
affects 810923 libvirt-daemon
subscribe 810923 a...@sigxcpu.org
thanks

On Wed, Jan 13, 2016 at 02:22:26PM -0500, Robbie Harwood wrote:
[..snip..]
> 2016-01-13 18:49:40.822+: starting up libvirt version: 1.3.0, package: 2 
> (Guido Günther  Wed, 06 Jan 2016 00:04:12 +0100), qemu 
> version: 2.5.0 (Debian 1:2.5+dfsg-3), hostname: thriss
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
> HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none 
> /usr/bin/qemu-system-ppc64 -name rhel6-ppc64 -S -machine 
> pseries-2.5,accel=tcg,usb=off -cpu POWER8 -m 2048 -realtime mlock=off -smp 
> 1,sockets=1,cores=1,threads=1 -uuid 98d818e6-b5c5-43b1-8381-da6ca420aec8 
> -no-user-config -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-rhel6-ppc64/monitor.sock,server,nowait
>  -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
> -no-shutdown -boot strict=on -device 
> ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device 
> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4
>  -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 
> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 
> -device spapr-vscsi,id=scsi0,reg=0x2000 -device 
> virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive 
> file=/var/lib/libvirt/images/rhel6-ppc64.img,if=none,id=drive-scsi0-0-0-0,format=raw
>  -device 
> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
>  -drive 
> file=/home/bos/rharwood/iso/RHEL-6.7-20150702.0-Server-ppc64-dvd1.iso,if=none,id=drive-scsi0-0-0-1,readonly=on,format=raw
>  -device 
> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1
>  -netdev tap,fd=29,id=hostnet0 -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:c7:37,bus=pci.0,addr=0x3
>  -chardev pty,id=charserial0 -device 
> spapr-vty,chardev=charserial0,reg=0x3000 -device usb-tablet,id=input0 
> -device usb-kbd,id=input1 -device usb-mouse,id=input2 -vnc 127.0.0.1:0 
> -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x1 -chardev 
> spicevmc,id=charredir0,name=usbredir -device 
> usb-redir,chardev=charredir0,id=redir0 -chardev 
> spicevmc,id=charredir1,name=usbredir -device 
> usb-redir,chardev=charredir1,id=redir1 -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -object 
> rng-random,id=objrng0,filename=/dev/random -device 
> virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -msg timestamp=on
> char device redirected to /dev/pts/3 (label charserial0)
> qemu: fatal: Trying to execute code outside RAM or ROM at 0xf92169f8

This looks like a problem in QEMU. If it's triggered by the above
configuration created by libvirt I cannot tell. You can try to reduce
the config to a working one by running it in the console to track this
down.

Cheers,
 -- Guido

Bug#808880: Package uploaded

[Thomas Goirand]

Hi,

Since I've seen no progress in this RFS, that the latest keystoneauth1
needs it (which blocked me), and I know Paultag is a busy person, I have
sponsored the upload of this package.

However, I still didn't get a reply on the important topic which I
raise: why not pushing this package to the PKG OpenStack group, rather
than the DPMT, as this seems to be a better fit? I don't see any other
reverse dependency in the archive but the one I just mentioned above.
Please reply to this question.

Cheers,

Thomas Goirand (zigo)

Bug#810955: ITP: golang-github-kennygrant-sanitize -- Functions for sanitizing text in golang strings

[Nathan Osman]

Package: wnpp
Severity: wishlist
Owner: Nathan Osman 

* Package name: golang-github-kennygrant-sanitize
  Version : 1.0
  Upstream Author : Kenny Grant 
* URL : https://github.com/kennygrant/sanitize
* License : BSD
  Programming Lang: Go
  Description : Functions for sanitizing text in golang strings

Provides functions that replace or remove characters from strings that 
contain HTML or non-ASCII characters, allowing the string to be used 
where plaintext or safe filenames are expected.


I am looking for a sponsor for this package and I am willing to be the
maintainer.

Bug#810953: cclive: Prepare for libquvi-0.9 transition

[Tim Lunn]

Package: cclive
Version: 0.9.3
Severity: normal

The attached patch includes the changes needed to build against libquvi-0.9.


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-5-generic (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru cclive-0.7.16/debian/changelog cclive-0.9.3/debian/changelog
--- cclive-0.7.16/debian/changelog	2015-07-09 18:51:00.0 +1000
+++ cclive-0.9.3/debian/changelog	2016-01-14 18:05:06.0 +1100
@@ -1,3 +1,13 @@
+cclive (0.9.3-1) UNRELEASED; urgency=medium
+
+  * New upstream release for libquvi-0.9 support
+  * debian/control.in:
+- Add build-deps on libglib2.0-dev and libglibmm-2.4-dev
+- Bump build-deps on libquvi-0.9-dev and libboost
+  * d/p/fix-FTBFS-missing-includes.patch: fix build failure due to missing includes
+
+ -- Tim Lunn   Thu, 14 Jan 2016 15:18:18 +1100
+
 cclive (0.7.16-2.1) unstable; urgency=medium
 
   * Non maintainer upload.
diff -Nru cclive-0.7.16/debian/control cclive-0.9.3/debian/control
--- cclive-0.7.16/debian/control	2014-05-12 07:21:51.0 +1000
+++ cclive-0.9.3/debian/control	2016-01-14 15:47:00.0 +1100
@@ -6,12 +6,14 @@
 Build-Depends: debhelper (>= 9),
  dh-autoreconf,
  libcurl4-gnutls-dev,
+ libglib2.0-dev,
+ libglibmm-2.4-dev,
  libpcre3-dev,
- libquvi-dev (>= 0.2.16.1),
- libboost-filesystem-dev,
- libboost-iostreams-dev,
- libboost-program-options-dev,
- libboost-date-time-dev,
+ libquvi-0.9-dev,
+ libboost-filesystem-dev (>= 1.49),
+ libboost-iostreams-dev (>= 1.49),
+ libboost-program-options-dev (>= 1.49),
+ libboost-date-time-dev (>= 1.49),
  asciidoc,
  pkg-config
 Standards-Version: 3.9.5
diff -Nru cclive-0.7.16/debian/patches/fix-FTBFS-missing-includes.patch cclive-0.9.3/debian/patches/fix-FTBFS-missing-includes.patch
--- cclive-0.7.16/debian/patches/fix-FTBFS-missing-includes.patch	1970-01-01 10:00:00.0 +1000
+++ cclive-0.9.3/debian/patches/fix-FTBFS-missing-includes.patch	2016-01-14 16:53:16.0 +1100
@@ -0,0 +1,48 @@
+Index: cclive-0.9.3/src/cc/error.h
+===
+--- cclive-0.9.3.orig/src/cc/error.h
 cclive-0.9.3/src/cc/error.h
+@@ -29,6 +29,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ namespace cc
+ {
+Index: cclive-0.9.3/src/cc/options.h
+===
+--- cclive-0.9.3.orig/src/cc/options.h
 cclive-0.9.3/src/cc/options.h
+@@ -38,6 +38,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ #include 
+Index: cclive-0.9.3/src/cc/sig.h
+===
+--- cclive-0.9.3.orig/src/cc/sig.h
 cclive-0.9.3/src/cc/sig.h
+@@ -28,6 +28,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ namespace cc
+ {
+Index: cclive-0.9.3/src/cc/error.cpp
+===
+--- cclive-0.9.3.orig/src/cc/error.cpp
 cclive-0.9.3/src/cc/error.cpp
+@@ -20,7 +20,6 @@
+ 
+ #include 
+ 
+-#include 
+ #include 
+ #include 
+ #include 
diff -Nru cclive-0.7.16/debian/patches/fix-rpath.diff cclive-0.9.3/debian/patches/fix-rpath.diff
--- cclive-0.7.16/debian/patches/fix-rpath.diff	2014-05-12 07:21:51.0 +1000
+++ cclive-0.9.3/debian/patches/fix-rpath.diff	2016-01-14 15:21:22.0 +1100
@@ -6,11 +6,13 @@
 Do not set rpath for Boost libraries.  While at it, also disable silent rules
 to make finding problems easier.
 
 a/configure.ac
-+++ b/configure.ac
-@@ -17,8 +17,8 @@
- AC_DEFINE_UNQUOTED([CANONICAL_TARGET], "$target", [...])
- AC_DEFINE_UNQUOTED([CANONICAL_HOST], "$host", [...])
+Index: cclive-0.9.3/configure.ac
+===
+--- cclive-0.9.3.orig/configure.ac
 cclive-0.9.3/configure.ac
+@@ -17,8 +17,8 @@ AC_USE_SYSTEM_EXTENSIONS
+ AC_DEFINE_UNQUOTED([CANONICAL_TARGET], "$target",
+   [Define to canonical target])
  
 -AM_INIT_AUTOMAKE([1.11.1 -Wall -Werror dist-xz no-dist-gzip tar-ustar])
 -AM_SILENT_RULES([yes])
@@ -19,9 +21,11 @@
  
  # GNU Automake 1.12 requires this macro. Earlier versions do not
  # recognize this macro. Work around this.
 a/m4/boost.m4
-+++ b/m4/boost.m4
-@@ -421,7 +421,7 @@
+Index: cclive-0.9.3/m4/boost.m4
+===
+--- cclive-0.9.3.orig/m4/boost.m4
 cclive-0.9.3/m4/boost.m4
+@@ -421,7 +421,7 @@ dnl generated only once above (before we
LDFLAGS=$boost_save_LDFLAGS
LIBS=$boost_save_LIBS
])
diff -Nru cclive-0.7.16/debian/patches/series cclive-0.9.3/debian/patches/series
--- cclive-0.7.16/debian/patches/series	2015-07-09 18:48:07.0 +1000
+++ cclive-0.9.3/debian/patches/series	2016-01-14 16:54:51.0 +1100
@@ -1,2 +1,3 @@
 fix-rpath.diff
 gcc5.diff
+fix-

Bug#810954: debian-installer: hurd hangs on startup, on loading ext2fs

[Adam Borowski]

Package: debian-installer
Version: 20160106
Severity: normal

All currently available images of hurd d-i (20151215-02:36 up to
20160113-01:54) hang on boot.  The last message given is:

start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec_

Machine is Virtualbox on amd64, with BIOS.

Bug#810952: totem-pl-parser: Prepare for libquvi-0.9 transition

[Tim Lunn]

Package: totem-pl-parser
Version: 3.10.6-1
Severity: normal

The attached patch includes the changes needed to build against libquvi-0.9.


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-5-generic (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru totem-pl-parser-3.10.6/debian/changelog totem-pl-parser-3.10.6/debian/changelog
--- totem-pl-parser-3.10.6/debian/changelog	2015-12-16 10:09:35.0 +1100
+++ totem-pl-parser-3.10.6/debian/changelog	2016-01-14 17:55:21.0 +1100
@@ -1,3 +1,11 @@
+totem-pl-parser (3.10.6-2) UNRELEASED; urgency=medium
+
+  * Prepare for libquvi-0.9 transition
+- d/p/totem-pl-parser-use-old-quvi.patch: Dropped
+- d/control.in: Build depend on libquvi-0.9-dev
+
+ -- Tim Lunn   Thu, 14 Jan 2016 15:03:11 +1100
+
 totem-pl-parser (3.10.6-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru totem-pl-parser-3.10.6/debian/control totem-pl-parser-3.10.6/debian/control
--- totem-pl-parser-3.10.6/debian/control	2015-12-16 10:19:42.0 +1100
+++ totem-pl-parser-3.10.6/debian/control	2016-01-14 17:55:24.0 +1100
@@ -21,7 +21,7 @@
libglib2.0-dev (>= 2.31.0),
libglib2.0-doc,
libgmime-2.6-dev,
-   libquvi-dev (>= 0.4.1-2.1~),
+   libquvi-0.9-dev,
libsoup-gnome2.4-dev (>= 2.43.0),
libxml-parser-perl,
libxml2-dev
@@ -38,7 +38,7 @@
  libarchive-dev,
  libglib2.0-dev,
  libgmime-2.6-dev,
- libquvi-dev,
+ libquvi-0.9-dev,
  libxml2-dev,
  ${misc:Depends}
 Description: Totem Playlist Parser library - development files
diff -Nru totem-pl-parser-3.10.6/debian/control.in totem-pl-parser-3.10.6/debian/control.in
--- totem-pl-parser-3.10.6/debian/control.in	2015-10-10 11:48:51.0 +1100
+++ totem-pl-parser-3.10.6/debian/control.in	2016-01-14 15:23:16.0 +1100
@@ -17,7 +17,7 @@
libglib2.0-dev (>= 2.31.0),
libglib2.0-doc,
libgmime-2.6-dev,
-   libquvi-dev (>= 0.4.1-2.1~),
+   libquvi-0.9-dev,
libsoup-gnome2.4-dev (>= 2.43.0),
libxml-parser-perl,
libxml2-dev
@@ -34,7 +34,7 @@
  libarchive-dev,
  libglib2.0-dev,
  libgmime-2.6-dev,
- libquvi-dev,
+ libquvi-0.9-dev,
  libxml2-dev,
  ${misc:Depends}
 Description: Totem Playlist Parser library - development files
diff -Nru totem-pl-parser-3.10.6/debian/patches/series totem-pl-parser-3.10.6/debian/patches/series
--- totem-pl-parser-3.10.6/debian/patches/series	2014-09-03 08:48:44.0 +1000
+++ totem-pl-parser-3.10.6/debian/patches/series	2016-01-14 15:04:34.0 +1100
@@ -1 +0,0 @@
-totem-pl-parser-use-old-quvi.patch
diff -Nru totem-pl-parser-3.10.6/debian/patches/totem-pl-parser-use-old-quvi.patch totem-pl-parser-3.10.6/debian/patches/totem-pl-parser-use-old-quvi.patch
--- totem-pl-parser-3.10.6/debian/patches/totem-pl-parser-use-old-quvi.patch	2015-12-16 10:05:37.0 +1100
+++ totem-pl-parser-3.10.6/debian/patches/totem-pl-parser-use-old-quvi.patch	1970-01-01 10:00:00.0 +1000
@@ -1,645 +0,0 @@
-From 659826f0f415664e49b79d9d98cdafa1240f49aa Mon Sep 17 00:00:00 2001
-From: Michael Biebl 
-Date: Wed, 16 Dec 2015 00:01:11 +0100
-Subject: [PATCH] Revert "plparse: Port to libquvi 0.9"
-
-This reverts the following commits
-24970018abfcedcaa4965e1f0f987aaf63323f31
-5c2190133328ee39764813ddee88a038dbf1d363
-e0a27de154259c8e11dd8eff1b606c9e6d162502
-b524675634af60ae4b9f08b54ea47f308ae4c563
-1147853ac9012c085ebb1d6306451c6d197542cf
-1be3144e9a6bf183a61c9596165d52bbe405b5cc

- Makefile.am   |   2 +-
- configure.ac  |  22 +---
- plparse/Makefile.am   |  10 --
- plparse/totem-pl-parser-videosite.c   | 224 +-
- plparse/videosite-parser.c| 191 -
- totem-plparser-mini-uninstalled.pc.in |   2 +-
- totem-plparser-mini.pc.in |   2 +-
- totem-plparser-uninstalled.pc.in  |   2 +-
- totem-plparser.pc.in  |   2 +-
- 9 files changed, 97 insertions(+), 360 deletions(-)
- delete mode 100644 plparse/videosite-parser.c
-
-diff --git a/Makefile.am b/Makefile.am
-index a9cda79..18bd1f5 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -44,7 +44,7 @@ MAINTAINERCLEANFILES = \
- pkgconfigdir = $(libdir)/pkgconfig
- pkgconfig_DATA = totem-plparser.pc totem-plparser-mini.pc
- 
--DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper --enable-gtk-doc --enable-introspection --enable-uninstalled-tests
-+DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper --enable-gtk-doc --enable-introspection
- 
- # Build ChangeLog

Bug#810945: New dependency set

[Michael Hanke]

Forgot one thing. Here is the new set of dependency for the experimental
upload of ODIN 2.0

libdcmtk-dev | libdcmtk2-dev | libdcmtk1-dev,
libdcmtk2v5,
dcmtk

I was able to get a successful build with it. Any advice on how to
optimze that (apart from ignoring the past) is appreciated.

Thanks,

Michael

Bug#775972: NMU in DELAYED/7

[Adam Borowski]

Hi!
As promised, I've went ahead with the NMU, it's in DELAYED/7.  Debdiff
attached.  Please say a word if you have anything against!

-- 
A tit a day keeps the vet away.
diff -Nru libgnomeui-2.24.5/debian/changelog libgnomeui-2.24.5/debian/changelog
--- libgnomeui-2.24.5/debian/changelog  2013-12-27 14:57:18.0 +0100
+++ libgnomeui-2.24.5/debian/changelog  2016-01-14 07:19:42.0 +0100
@@ -1,3 +1,10 @@
+libgnomeui (2.24.5-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTFBS on x32. Closes: #775972.
+
+ -- Adam Borowski   Thu, 14 Jan 2016 07:19:13 +0100
+
 libgnomeui (2.24.5-3) unstable; urgency=low
 
   * Switch to multiarch. Closes: #642417.
diff -Nru libgnomeui-2.24.5/debian/control libgnomeui-2.24.5/debian/control
--- libgnomeui-2.24.5/debian/control2013-12-27 14:58:26.0 +0100
+++ libgnomeui-2.24.5/debian/control2016-01-14 07:21:34.0 +0100
@@ -2,7 +2,6 @@
 # 
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
-
 Source: libgnomeui
 Section: oldlibs
 Priority: optional
diff -Nru libgnomeui-2.24.5/debian/patches/02_time_t_printfs.patch 
libgnomeui-2.24.5/debian/patches/02_time_t_printfs.patch
--- libgnomeui-2.24.5/debian/patches/02_time_t_printfs.patch1970-01-01 
01:00:00.0 +0100
+++ libgnomeui-2.24.5/debian/patches/02_time_t_printfs.patch2016-01-14 
07:21:23.0 +0100
@@ -0,0 +1,27 @@
+Description: cast time_t printfs
+ Upstream code uses printf("%ld") with a time_t argument.  This causes a
+ warning if time_t is a different type than long, which causes a FTBFS
+ under -Werror.
+Author: Adam Borowski 
+Bug-Debian: https://bugs.debian.org/775972
+
+--- libgnomeui-2.24.5.orig/libgnomeui/gnome-thumbnail.c
 libgnomeui-2.24.5/libgnomeui/gnome-thumbnail.c
+@@ -863,7 +863,7 @@ gnome_thumbnail_factory_save_thumbnail (
+ }
+   close (tmp_fd);
+   
+-  g_snprintf (mtime_str, 21, "%ld",  original_mtime);
++  g_snprintf (mtime_str, 21, "%ld",  (long)original_mtime);
+   width = gdk_pixbuf_get_option (thumbnail, "tEXt::Thumb::Image::Width");
+   height = gdk_pixbuf_get_option (thumbnail, "tEXt::Thumb::Image::Height");
+ 
+@@ -970,7 +970,7 @@ gnome_thumbnail_factory_create_failed_th
+ }
+   close (tmp_fd);
+   
+-  g_snprintf (mtime_str, 21, "%ld",  mtime);
++  g_snprintf (mtime_str, 21, "%ld",  (long)mtime);
+   pixbuf = gdk_pixbuf_new (GDK_COLORSPACE_RGB, TRUE, 8, 1, 1);
+   saved_ok  = gdk_pixbuf_save (pixbuf,
+  tmp_path,
diff -Nru libgnomeui-2.24.5/debian/patches/series 
libgnomeui-2.24.5/debian/patches/series
--- libgnomeui-2.24.5/debian/patches/series 2013-12-27 14:56:43.0 
+0100
+++ libgnomeui-2.24.5/debian/patches/series 2016-01-14 07:20:34.0 
+0100
@@ -1 +1,2 @@
 01_link_libm.patch
+02_time_t_printfs.patch

Bug#810945: Useless dependencies

[Michael Hanke]

This dependency setting is motivated by the need for 'dicom.dic' which
has moved a lot in the past. Currently

% apt-file search dicom.dic
libdcmtk2: /usr/share/libdcmtk2/dicom.dic
libdcmtk2v5: /usr/share/libdcmtk2/dicom.dic
libdcmtk4v5: /usr/share/libdcmtk4/dicom.dic
libdcmtk5: /usr/share/libdcmtk5/dicom.dic

This is required for the tests to run. This package is often backported
and it would be a hassle to have to modify it for each an every target.

If you have a suggestion on how to do this better, I'd be happy to
implement it. At the moment I don't see how this bug is severity
important.

Thanks,

Michael

Bug#810863: RM: python-dmidecode [kfreebsd-amd64 kfreebsd-i386 hurd-i386] -- RoQA; old binaries depends on removed packages

[Sandro Tosi]

> --- python-dmidecode-3.12.2/unit-tests/unit.orig2015-06-08 
> 16:19:45.0 +0100
> +++ python-dmidecode-3.12.2/unit-tests/unit 2016-01-14 02:01:48.597318900 
> +
> @@ -11,6 +11,7 @@
>  (sysname, nodename, release, version, machine) = os.uname()
>  pyver = sys.version[:3]
>  sys.path.insert(0,'../build/lib.%s-%s-%s' % (sysname.lower(), machine, 
> pyver))
> +sys.path.insert(1,'../build/lib.%s-%s-%s-%s' % 
> (sysname.lower().translate(None, '/'), release, machine, pyver))

the right way to retrieve the build dir is:

python -c "from distutils.command.build import build ; from
distutils.core import Distribution ; b = build(Distribution()) ;
b.finalize_options() ; print b.build_platlib"

(thanks jwilk!) which I'm using in several packages, we should do the same here.

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

Bug#355474: more complete patch

[Adam Borowski]

Hi!
Sebastian's patch touches only anonymous-ftp-master, but there are other FTP
hosts with the same problem.  These days, with the depletion of IPv4
addresses, this affects pretty much everyone who uploads from their home
connection.  Thus, here's my version of the patch.

Also, as you haven't done an upload of dupload for almost 5 years, would you
have something against a NMU with this bug (and probably others)?

-- 
A tit a day keeps the vet away.
--- dupload.conf~	2011-02-24 00:41:58.0 +0100
+++ dupload.conf	2016-01-14 07:08:23.975176394 +0100
@@ -74,6 +74,7 @@
 	incoming => "/pub/UploadQueue/",
 	# The dinstall on ftp-master sends emails itself
 	dinstall_runs => 1,
+	passive => 1,
 };
 
 # see http://backports.debian.org/Contribute/ for more information
@@ -81,6 +82,7 @@
 fqdn => "backports-master.debian.org",
 incoming => "/pub/UploadQueue/",
 dinstall_runs => 1,
+passive => 1,
 };
 
 # see http://www.debian.org/devel/debian-volatile/ for more information
@@ -100,6 +102,7 @@
 	incoming => "/pub/UploadQueue/DELAYED/$delay-day/",
 	# The dinstall on ftp-master sends emails itself
 	dinstall_runs => 1,
+	passive => 1,
 };
 
 # Mentors upload queue, see
@@ -132,6 +135,7 @@
 #	# files pass on to dinstall on security which sends emails itself
 #	dinstall_runs => 1,
 #	nonus => 1,
+#	passive => 1,
 #};
 
 

Bug#810924: apt-cacher: GDBM_File tie failed: Permission denied at apt-cacher-cleanup.pl line 620.

[Mark Hindley]

On Wed, 13 Jan 2016, 19:51:46 GMT, Christian Bachmaier  
wrote:

> Package: apt-cacher
> Version: 1.7.11
> Severity: normal
> 
> Dear Maintainer,
> 
> executing /usr/share/apt-cacher/apt-cacher-cleanup-pl causes the error
> 
> GDBM_File tie failed: Permission denied at ./apt-cacher-cleanup.pl line
> 620.

Thanks. I can't reproduce this so far. Are you running apt-cacher-cleanup.pl 
manually or from cron?

> This happen since a couple of days on an up to date Stretch, maybe
> introduced due to updates of other packages. Say 3 weeks ago I think it
> was working. I made no config change.

What other package updates?

What are your /tmp permissions? Disk partition or tmpfs?

Best wishes

Mark

Bug#798769: NMU in DELAYED/7

[Adam Borowski]

Hi!
Now that I can do it myself, I've prepared a NMU and scheduled it for 7 days
from now.  If you're unhappy with this, please say so.

Debdiff attached, and so are two commits against
ssh://git.debian.org/git/pkg-utopia/policykit.git

-- 
A tit a day keeps the vet away.
diff -Nru policykit-1-0.105/debian/changelog policykit-1-0.105/debian/changelog
--- policykit-1-0.105/debian/changelog  2015-11-23 11:38:06.0 +0100
+++ policykit-1-0.105/debian/changelog  2016-01-14 06:29:13.0 +0100
@@ -1,3 +1,10 @@
+policykit-1 (0.105-14.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on non-linux/non-systemd. (Closes: #798769)
+
+ -- Adam Borowski   Thu, 14 Jan 2016 06:28:38 +0100
+
 policykit-1 (0.105-14) unstable; urgency=medium
 
   * debian/policykit-1.preinst: Use systemctl unmask instead of direct symlink
diff -Nru 
policykit-1-0.105/debian/patches/0.113/Don-t-discard-error-data-returned-by-polkit_system_b.patch
 
policykit-1-0.105/debian/patches/0.113/Don-t-discard-error-data-returned-by-polkit_system_b.patch
--- 
policykit-1-0.105/debian/patches/0.113/Don-t-discard-error-data-returned-by-polkit_system_b.patch
   1970-01-01 01:00:00.0 +0100
+++ 
policykit-1-0.105/debian/patches/0.113/Don-t-discard-error-data-returned-by-polkit_system_b.patch
   2016-01-14 06:25:07.0 +0100
@@ -0,0 +1,29 @@
+From: Miloslav Trmač 
+Date: Mon, 11 Nov 2013 23:51:23 +0100
+Subject: [PATCH] Don't discard error data returned by
+ polkit_system_bus_name_get_user_sync
+
+https://bugs.freedesktop.org/show_bug.cgi?id=71458
+
+Origin: upstream, 0.113, commit: 145d43b9c891f248ad68ebe597cb151a865bdb3a
+Bug-Debian: https://bugs.debian.org/798769
+---
+ src/polkitbackend/polkitbackendsessionmonitor.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/polkitbackend/polkitbackendsessionmonitor.c 
b/src/polkitbackend/polkitbackendsessionmonitor.c
+index 05f51c5..e1a9ab3 100644
+--- a/src/polkitbackend/polkitbackendsessionmonitor.c
 b/src/polkitbackend/polkitbackendsessionmonitor.c
+@@ -306,7 +306,7 @@ polkit_backend_session_monitor_get_user_for_subject 
(PolkitBackendSessionMonitor
+ }
+   else if (POLKIT_IS_SYSTEM_BUS_NAME (subject))
+ {
+-  ret = (PolkitIdentity*)polkit_system_bus_name_get_user_sync 
(POLKIT_SYSTEM_BUS_NAME (subject), NULL, NULL);
++  ret = (PolkitIdentity*)polkit_system_bus_name_get_user_sync 
(POLKIT_SYSTEM_BUS_NAME (subject), NULL, error);
+ }
+   else if (POLKIT_IS_UNIX_SESSION (subject))
+ {
+-- 
+2.1.4
+
diff -Nru 
policykit-1-0.105/debian/patches/0.113/Fixed-compilation-problem-in-the-backend.patch
 
policykit-1-0.105/debian/patches/0.113/Fixed-compilation-problem-in-the-backend.patch
--- 
policykit-1-0.105/debian/patches/0.113/Fixed-compilation-problem-in-the-backend.patch
   1970-01-01 01:00:00.0 +0100
+++ 
policykit-1-0.105/debian/patches/0.113/Fixed-compilation-problem-in-the-backend.patch
   2016-01-14 06:02:23.0 +0100
@@ -0,0 +1,26 @@
+From: Xabier Rodriguez Calvar 
+Date: Sun, 10 Nov 2013 19:16:41 +0100
+Subject: [PATCH] Fixed compilation problem in the backend
+
+Origin: upstream, 0.113, commit: dbbb7dc60abdd970af0a8fae404484181fa909c9
+Bug-Debian: https://bugs.debian.org/798769
+---
+ src/polkitbackend/polkitbackendsessionmonitor.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/polkitbackend/polkitbackendsessionmonitor.c 
b/src/polkitbackend/polkitbackendsessionmonitor.c
+index 4075d3f..05f51c5 100644
+--- a/src/polkitbackend/polkitbackendsessionmonitor.c
 b/src/polkitbackend/polkitbackendsessionmonitor.c
+@@ -306,7 +306,7 @@ polkit_backend_session_monitor_get_user_for_subject 
(PolkitBackendSessionMonitor
+ }
+   else if (POLKIT_IS_SYSTEM_BUS_NAME (subject))
+ {
+-  ret = (PolkitIdentity*)polkit_system_bus_name_get_user_sync 
(POLKIT_SYSTEM_BUS_NAME (subject));
++  ret = (PolkitIdentity*)polkit_system_bus_name_get_user_sync 
(POLKIT_SYSTEM_BUS_NAME (subject), NULL, NULL);
+ }
+   else if (POLKIT_IS_UNIX_SESSION (subject))
+ {
+-- 
+2.1.4
+
diff -Nru policykit-1-0.105/debian/patches/series 
policykit-1-0.105/debian/patches/series
--- policykit-1-0.105/debian/patches/series 2015-11-23 11:38:06.0 
+0100
+++ policykit-1-0.105/debian/patches/series 2016-01-14 06:02:23.0 
+0100
@@ -9,6 +9,8 @@
 0.113/03_PolkitAgentSession-fix-race-between-child-and-io-wat.patch
 0.113/polkitd-Fix-problem-with-removing-non-existent-sourc.patch
 0.113/PolkitSystemBusName-Add-public-API-to-retrieve-Unix-.patch
+0.113/Fixed-compilation-problem-in-the-backend.patch
+0.113/Don-t-discard-error-data-returned-by-polkit_system_b.patch
 0.113/sessionmonitor-systemd-Deduplicate-code-paths.patch
 0.113/sessionmonitor-systemd-prepare-for-D-Bus-user-bus-mo.patch
 0.113/Refuse-duplicate-user-arguments-to-pkexec.patch
>From 5abd436741827a3b3920a1df4c95682bbefb8648 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Thu, 14 Jan 2016 06:34:08 +01

Bug#810951: tidy: new upstream version (5.0.0)

[Paul Wise]

Package: tidy
Severity: wishlist

There is a new upstream release at the new upstream website:

http://www.html-tidy.org/

You can see here that this is the new location for tidy:

http://tidy.sourceforge.net/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#810950: RFS: ecere-sdk/0.44.14-1 -- Please sponsor this bug fix release to the Ecere SDK

[Jérôme St-Louis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for this new release to my package "ecere-sdk".
This addresses build reproducibility issues, a bug causing the M68K 
build to fail, and improved dependencies that should allow building on 
additional platforms.


* Package name: ecere-sdk
   Version : 0.44.14-1
   Upstream Author : Ecere Corporation 
* URL : http://ecere.org
* License : BSD-3 clauses
  Section : Development

It builds those binary packages:

ecere-dev - Ecere SDK Development Tools
ecere-extras - Extras for the Ecere SDK
ecere-samples - Project samples for the Ecere SDK
ecere-sdk - Ecere cross-platform SDK
libecc0 - eC Compiler Library
libecere0 - Ecere Runtime Library
libecereaudio0 - Ecere Audio
libecerecom0 - eC Core Runtime Library
libeda0 - Ecere Data Access
libedasqlite0 - EDA SQLite Driver

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

  http://mentors.debian.net/package/ecere-sdk


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

  dget -x 
http://mentors.debian.net/debian/pool/main/e/ecere-sdk/ecere-sdk_0.44.14-1.dsc


  More information about the Ecere SDK can be obtained from 
http://ecere.org


  Changes since the last upload:


ecere-sdk (0.44.14-1) unstable; urgency=low

   * Packaged Ecere SDK 0.44.14
   * Fixed control file to build if upx-ucl is not available
   * Made dependency on linux-libc6-dev specific to Linux
   * Changes:
  - Addresses build reproducibility issues
  - Fixed compiler bug causing build to fail on M68K
  - Documentor: Minor fixes
  - Spelling fixes
  - GUI/ListBox: Fixed clearing cell data

 -- Jerome St-Louis   Wed, 13 Jan 2016 22:00:00 -0500


  Regards,

 Jerome St-Louis

Bug#810947: Bug#804060: Please dont' fill up the BTS with many bugs for the same issue, more info needed.

[Arthur Marsh]

Lisandro Damián Nicanor Pérez Meyer wrote on 14/01/16 15:11:

Arthur: you have filed at least 3 bugs for this very same issue. Please
refrain from doing so in the future. Just file one and let the maintainers
decide.


Hi, thanks for your help in narrowing this down. I've been working 
through this problem for over 2 months and you were the first maintainer 
to respond to me.


Previously I'd only been able to verify that the problem did not occur 
under xfce, which left the whole plasma/kinit/kwin_x11 and support 
libraries as possible contributing factors. The problem would come and 
go inconsistently with different library and kernel upgrades.


If I'd had any further advice earlier about how to better isolate the 
problem I would have used it and hopefully been less likely to report a 
bug against the wrong package.




As I already asked before when you filed the same bug for Qt: have you tried
creating a new user and checking if you can reproduce the bug there?

iceweasel maintainers: so far I was unable to reproduce this bug.

Regards, Lisandro.



Regards,

Arthur.

Bug#780558: adopting it

[Adam Borowski]

Control: retitle -1 ITA: mathematica-fonts -- installer for Mathematica fonts
Control: owner -1 !

A new version that includes me adopting the package on behalf of the fonts
team is in NEW.

In case something goes bad: my changes are in
https://gitlab.com/kilobyte/mathematica-fonts.git

-- 
A tit a day keeps the vet away.

Bug#810949: ITP: ncbi-entrez-direct -- NCBI Entrez utilities on the command line

[Aaron M. Ucko]

Package: wnpp
Severity: wishlist
Owner: "Aaron M. Ucko" 

* Package name: ncbi-entrez-direct
  Version : 3.60
  Upstream Author : Jonathan Kans 
* URL : http://www.ncbi.nlm.nih.gov/books/NBK179288
* License : Public Domain
  Programming Lang: Perl, Go, Bourne shell
  Description : NCBI Entrez utilities on the command line

  Entrez Direct (EDirect) is an advanced method for accessing NCBI's set
  of interconnected databases (publication, sequence, structure, gene,
  variation, expression, etc.) from a terminal window or script.
  Functions take search terms from command-line arguments.  Individual
  operations are combined to build multi-step queries.  Record retrieval
  and formatting normally complete the process.

  EDirect also provides an argument-driven function that simplifies the
  extraction of data from document summaries or other results that are
  returned in structured XML format.  This can eliminate the need for
  writing custom software to answer ad hoc questions.  Queries can move
  seamlessly between EDirect commands and UNIX utilities or scripts to
  perform actions that cannot be accomplished entirely within Entrez.

With all due respect to the Go packaging team, I feel that maintaining
EDirect within Debian Med or perhaps Debian Science would be more
appropriate, as it falls outside the mainstream Go ecosystem.  Yes,
one individual tool happens to be written in Go, but EDirect otherwise
consists of a mixture of Perl and shell scripts, and the Go tool has
no dependencies beyond the standard library.

Also, I am inclined to build the tool in question with gccgo rather
than golang-go, which is available for fewer architectures and
provides no obvious way to obtain dynamic linkage against system
libraries, for which Policy 10.1 calls.  I'm debating whether to go
fully dynamic (yielding, on amd64, a 228K executable depending on a
34M library with hardly any other reverse dependencies) or to link
libgo statically (yielding a 3.2M executable with no exotic
dependencies).  I suppose the fully dynamic approach is better
practice, but would appreciate feedback on this point.

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#804060: Please dont' fill up the BTS with many bugs for the same issue, more info needed.

[Lisandro Damián Nicanor Pérez Meyer]

Arthur: you have filed at least 3 bugs for this very same issue. Please 
refrain from doing so in the future. Just file one and let the maintainers 
decide.

As I already asked before when you filed the same bug for Qt: have you tried 
creating a new user and checking if you can reproduce the bug there?

iceweasel maintainers: so far I was unable to reproduce this bug.

Regards, Lisandro.

-- 
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.
  Linus Benedict Torvalds.

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


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

Bug#810948: dh_strip: Use dbgsym notation instead of ddeb

[Jens Reyer]

Package: debhelper
Version: 9.20151225
Severity: wishlist

Hi,

dh_strip implements the new automatic debug packages using the word
"ddeb" (e.g. --ddeb-migration, --ddebs, --no-ddebs). However ddeb was
only used in earlier implementations, at least the packages are now
called foo-dbgsym*.deb, not foo*.ddeb.

I'd suggest to use "dbgsym" instead, to avoid any confusion in the long
run. I think now is still the right time to change this. Maybe keep the
option-names available for compatibility and print a deprecation
warning, but simply do a replace in the documentation.

Greets and thanks
jre



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

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

Versions of packages debhelper depends on:
ii  binutils 2.25.90.20160101-1
ii  dh-strip-nondeterminism  0.014-1
ii  dpkg 1.18.4
ii  dpkg-dev 1.18.4
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-3
ii  po-debconf   1.0.18

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  1.20150601

-- no debconf information

Bug#810947: kwin-x11: iceweasel locks up when multiple windows restored

[Arthur Marsh]

Package: kwin-x11
Version: 4:5.4.3-1.1
Followup-For: Bug #810947

Dear Maintainer,

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

I found that I could start iceweasel from krunner (alt F2 from plasma
desktop) without issue while kwin-x11 was running.

The problem seems to be a difference between launching iceweasel from
kdeinit5 (plasma start menu) and krunner (alt F2 from plasma desktop).

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


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

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kwin-x11 depends on:
ii  kwin-common  4:5.4.3-1.1
ii  libc62.21-6
ii  libkf5i18n5  5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libqt5core5a 5.5.1+dfsg-12
ii  libqt5gui5   5.5.1+dfsg-12
ii  libqt5widgets5   5.5.1+dfsg-12
ii  libqt5x11extras5 5.5.1-3
ii  libstdc++6   5.3.1-5
ii  libxcb1  1.11.1-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- debconf-show failed

Bug#806213: kinit: starting up iceweasel with multiple windows/tabs sometimes causes lock-up

[Arthur Marsh]

Package: kinit
Version: 5.16.0-1
Followup-For: Bug #806213

Dear Maintainer,

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

I tried starting iceweasel avoiding kinit using krunner (alt F2 from 
plasma desktop) and had no problems, therefore the issues appears to lie
with package kinit.

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


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

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kinit depends on:
ii  libc62.21-6
ii  libcap2  1:2.24-12
ii  libkf5configcore55.16.0-1
ii  libkf5coreaddons55.16.0-1
ii  libkf5crash5 5.16.0-1
ii  libkf5i18n5  5.16.0-1
ii  libkf5kiocore5   5.16.0-1
ii  libkf5kiowidgets55.16.0-1
ii  libkf5service-bin5.16.0-1
ii  libkf5service5   5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libqt5core5a 5.5.1+dfsg-12
ii  libqt5dbus5  5.5.1+dfsg-12
ii  libqt5gui5   5.5.1+dfsg-12
ii  libstdc++6   5.3.1-5
ii  libx11-6 2:1.6.3-1

kinit recommends no packages.

kinit suggests no packages.

-- debconf-show failed

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

[Arthur Marsh]

Package: libqt5core5a
Version: 5.5.1+dfsg-12
Followup-For: Bug #810243

Dear Maintainer,

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

I was able to successfully start iceweasel using krunner (alt-F2 from
plasma desktop).

I had also been able to successfully start iceweasel by killing kwin_x11,
starting iceweasel and letting all its windows open then restarting kwin_x11.

Please close this bug - the problem appears to be with packages
kinit or kwin-x11.

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


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

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libqt5core5a depends on:
ii  libc6 2.21-6
ii  libgcc1   1:6-20160103-1
ii  libglib2.0-0  2.46.2-3
ii  libicu55  55.1-7
ii  libpcre16-3   2:8.38-1
ii  libstdc++65.3.1-5
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages libqt5core5a recommends:
ii  qttranslations5-l10n  5.5.1-2

Versions of packages libqt5core5a suggests:
ii  libthai0  0.1.24-1

-- debconf-show failed

-- debsums errors found:
debsums: changed file /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1 (from 
libqt5core5a:amd64 package)

Bug#810871: [buildd-tools-devel] Bug#810871: [sbuild] Please provide a way to set an environment variable to the build directory

[Katsuhiko Nishimra]

On Thu, 14 Jan 2016 00:37:19 +0100 Johannes Schauer  wrote:
> 
> Is this documentation not working for you:
> 
> https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild

Yes, I've followed the instructions above and encountered cache misses.
> 
> If you just need a stable build path, is the --build-path option not working
> for you?

Ah, it's one way.
I haven't noticed that stable build paths are not a problem even in the
case where parallel builds are invoked.

But, if we can specify something like 
 $build_environment = { 'CCACHE_BASEDIR' => '%BUILD_DIR%'};
is it more versatile?

Anyway, thanks for your suggestion, and feel free to close this bug if
you wish.

Bug#810947: kwin-x11: iceweasel locks up when multiple windows restored

[Arthur Marsh]

Package: kwin-x11
Version: 4:5.4.3-1.1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Please see bug report #806213 - iceweasel would lock up when restoring 
multiple windows.

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

killing kwin_x11 process after starting plasma desktop, then letting 
iceweasel start up fully, then running kwin_x11 after.

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

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


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

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kwin-x11 depends on:
ii  kwin-common  4:5.4.3-1.1
ii  libc62.21-6
ii  libkf5i18n5  5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libqt5core5a 5.5.1+dfsg-12
ii  libqt5gui5   5.5.1+dfsg-12
ii  libqt5widgets5   5.5.1+dfsg-12
ii  libqt5x11extras5 5.5.1-3
ii  libstdc++6   5.3.1-5
ii  libxcb1  1.11.1-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- debconf-show failed

Bug#806213: kinit: starting up iceweasel with multiple windows/tabs sometimes causes lock-up

[Arthur Marsh]

Package: kinit
Version: 5.16.0-1
Followup-For: Bug #806213

Dear Maintainer,

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

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

This problem re-appeared after some upgrades and what I did to work around it
was to kill kwin_x11, start iceweasel and let it open all its windows, then
restart kwin_x11.

Perhaps the problem is with kwin_x11?

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

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


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

Kernel: Linux 4.4.0+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kinit depends on:
ii  libc62.21-6
ii  libcap2  1:2.24-12
ii  libkf5configcore55.16.0-1
ii  libkf5coreaddons55.16.0-1
ii  libkf5crash5 5.16.0-1
ii  libkf5i18n5  5.16.0-1
ii  libkf5kiocore5   5.16.0-1
ii  libkf5kiowidgets55.16.0-1
ii  libkf5service-bin5.16.0-1
ii  libkf5service5   5.16.0-1
ii  libkf5windowsystem5  5.16.0-1
ii  libqt5core5a 5.5.1+dfsg-12
ii  libqt5dbus5  5.5.1+dfsg-12
ii  libqt5gui5   5.5.1+dfsg-12
ii  libstdc++6   5.3.1-5
ii  libx11-6 2:1.6.3-1

kinit recommends no packages.

kinit suggests no packages.

-- debconf-show failed

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

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 10 January 2016 01:08:35 Arthur Marsh wrote:
> Lisandro Damián Nicanor Pérez Meyer wrote on 09/01/16 11:04:
> >> Is it possible start applications within the KDE plasma desktop without
> >> them having kdeinit5 as a parent/grandparent process?
> > 
> > I tried opening iceweasel from krunner and from the K menu it works
> > perfectly.
> How does one open iceweasel from krunner on a KDE plasma desktop?

Alt+F2, type iceweasel
 
> > Have you ried creating a new user from scratch and testing what happens
> > there?
> I should try that soon.
> 
> The problem appears to be related to how kdeinit5 or its dependent
> libraries behave, which can result in the lock-ups I've experienced when
> when some upgrades have taken place.

But there is nothing yet really pointing to Qt issues. As I said before the 
changes between the two versions you mentioned should not be related at all.

Please try again with a new user.

-- 
"Los pibes no piden que levantemos un muro para que tengan un límite,
sino que los ayudemos a crecer en libertad."
  Padre Bergoglio - http://www.lanacion.com.ar/1153060

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


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

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[Andy Smith]

Hi,

I'm also seeing this.

With:

GRUB_CMDLINE_XEN="dom0_mem=1024M,max:1024M …"

I see a flurry of "xen:balloon: Cannot add additional memory (-17)"
messages every time a domU is shut down.

In this configuration I note that I also see with "free -m" that
dom0 has 929M, though "xl list" shows 1024M.

I can run "xl mem-set 0 1024" without visible error but it does not
prevent the error messages being logged.

With:

GRUB_CMDLINE_XEN="dom0_mem=1024M …"

I do not see any of the balloon error messages.

In this configuration "free -m" shows 768M RAM for dom0, though "xl
list" still shows 1024M.

xen-hypervisor-4.4-amd644.4.1-9+deb8u3
linux-image-3.16.0-4-amd64  3.16.7-ckt20-1+deb8u2

I'm guessing that the reason I end up with 768M RAM in dom0 is
because I have not specified the *maximum* RAM for dom0, so the
kernel scales structures for the possible case of dom0 getting the
entire 128G of RAM at some point.

I added "mem=1G" to the Linux kernel command line and then dom0
boots with "free -m" showing 930M.

So, at the moment I am running with "dom0_mem=1024M" on the Xen
command line, "mem=1G" on the Linux kernel command line, and
"autoballoon=off" in /etc/xen/xl.conf.

This seems to avoid the xen:balloon error messages and provide
something more like thr expected amount of dom0 memory. Is there a
downside of not specifying the ",max:1024M" part?

Cheers,
Andy

Bug#799539: Removing shinken from Debian in about a month

[Mathieu Parent]

Hello,

I don't want to keep a non-maintained packages in sid, and nobody has
adopted them.

I plan to ask removal of all shinken* packages in a month or so.

More info in #799539

Regards
-- 
Mathieu Parent

Bug#810858: [pkg-horde] Bug#810858: Bug#810858: webmail-install and horde try to create db schema multiple times + wrong schema version

[Mathieu Parent]

2016-01-13 12:09 GMT+01:00 Ivan Sergio Borgonovo :
> Hi,

Hello,

> On 01/13/2016 10:49 AM, Mathieu Parent wrote:
[...]
>
> horde=# select * from kronolith_schema_info ;
>  version
> -
>   17
> (1 row)

This should be 26 instead.
Ref: https://github.com/horde/horde/tree/master/kronolith/migration

Does the 'kronolith_sharesng' table have a 'share_parents' column
(added in step 17)?
Does the 'kronolith_events' table have the 'event_category' column
(removed in step 18)?

Can you run "horde-db-migrate --debug kronolith up"?

>
> horde=# select * from imp_schema_info ;
>  version
> -
>3

This looks ok.
Ref: https://github.com/horde/horde/tree/master/imp/migration

Regards

-- 
Mathieu Parent

Bug#810863: RM: python-dmidecode [kfreebsd-amd64 kfreebsd-i386 hurd-i386] -- RoQA; old binaries depends on removed packages

[Steven Chamberlain]

Hi,

Sandro Tosi wrote:
> yeah I will fix that bug, having known the urgency I might have
> changed the scheduling of my Debian works though

Here's a quick fix for building on kfreebsd, maybe hurd is the same?
For some reason the build/ subdirectory has the kernel version in it,
e.g.:

../build/lib.linux-3.2.0-4-amd64-x86_64-2.7
../build/lib.gnukfreebsd-10.1-0-amd64-x86_64-2.7


--- python-dmidecode-3.12.2/unit-tests/unit.orig2015-06-08 
16:19:45.0 +0100
+++ python-dmidecode-3.12.2/unit-tests/unit 2016-01-14 02:01:48.597318900 
+
@@ -11,6 +11,7 @@
 (sysname, nodename, release, version, machine) = os.uname()
 pyver = sys.version[:3]
 sys.path.insert(0,'../build/lib.%s-%s-%s' % (sysname.lower(), machine, pyver))
+sys.path.insert(1,'../build/lib.%s-%s-%s-%s' % 
(sysname.lower().translate(None, '/'), release, machine, pyver))
 
 root_user = (os.getuid() == 0 and True or False)
 


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


signature.asc
Description: Digital signature

Bug#809923: New package proposal: nordlicht

[Peter Spiess-Knafl]

Dear pkg-multimedia-maintainers!

I am currently packaging a software called nordlicht.

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

Upstream is very collaborative on fixing things or applying patches.
Here is the ongoing discussion:

https://github.com/nordlicht/nordlicht/issues/38

I got hinted that it might be relevant to the pkg-multimedia team, so I
am proposing it here.

The package is currently developed at collab-maint:
http://anonscm.debian.org/cgit/collab-maint/nordlicht.git/

I also uploaded the current version to mentors:
http://mentors.debian.net/package/nordlicht


It would be great if somebody could review it and maybe consider
sponsoring it. I would like it very much to have it team-maintained.

Greetings
Peter

Bug#810856: [pkg-dhcp-devel] Bug#810856: (no subject)

[Michael Gilbert]

control: tag -1 moreinfo
control: severity -1 minor

> Subject: isc-dhcp-server: search domain still 'home' with ddns-update-style 
> interim

Your description is quite hard to follow, so I'm not sure what problem
it is you're having.  Please try to clarify.

>* What outcome did you expect instead?
>
> A good search domain for the dhcp client Oel 5.8

For your clients are you using isc-dhcp-client or isc-dhcp-client-ddns?

Best wishes,
Mike

Bug#809815: [feature request] linux-image-4.3.0-1-sparc64-smp: tpm random module for linux LDOMs

[Ben Hutchings]

On Thu, 2016-01-14 at 03:00 +0300, Anatoly Pugachev wrote:
> On Mon, Jan 11, 2016 at 3:08 AM, Ben Hutchings  wrote:
> > On Thu, 2016-01-07 at 20:30 +0300, Anatoly Pugachev wrote:
> > > Can you please suggest, what to do next? Close this bugreport as
> > > invalid, and fill new one against n2_rng module in debian, or report
> > > first to lkml? Thanks.
> > [...]
> > 
> > You should send this patch upstream (linux-cry...@vger.kernel.org and
> > sparcli...@vger.kernel.org mailing lists).
> 
> Ben,
> submitted to both mentioned mailing lists, it got to DaveM processing
> queue, see 
> http://patchwork.ozlabs.org/project/sparclinux/list/?submitter=68078
> As I told earlier, I'm not a kernel developer in any form, not even
> C/C++ programmer. I'm not sure I would be able to answer to any
> objections on this patch.
> But thanks anyway, probably someone else (oracle guys, with their
> linux for sparc [L4S] project) would be able to make this patch to
> kernel.

I think those will be fine except the two of them should have different
subjects.  DaveM will tell you what if anything he wants you to change.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

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

Bug#806897: libembperl-perl: FTBFS with perl 5.22: 'PL_sv_objcount' undeclared

[Axel Beckert]

Hi,

Dominic Hargreaves wrote:
> This package FTBFS with perl 5.22, in experimental:
> 
> epnames.h:329:21: error: 'PL_sv_objcount' undeclared (first use in this 
> function)
>  #define sv_objcount PL_sv_objcount

This happens because PL_sv_objcount has been removed from Perl 5.22
(deprecated since 5.20). See e.g.
http://www.gossamer-threads.com/lists/perl/porters/311420 or
https://rt.perl.org/Public/Bug/Display.html?id=121876

Removing all occurrences of PL_sv_objcount and sv_objcount as well as
the according "-OBJs: %d" format strings from Embperl's source
suffices to make it build against 5.22. Unfortunately the test suite
fails afterwards.

Anyways, here's the patch to make the upstream code build again:

Index: libembperl-perl/epmain.c
===
--- libembperl-perl.orig/epmain.c   2014-10-13 23:44:08.653839074 +0200
+++ libembperl-perl/epmain.c2016-01-14 02:02:20.330219409 +0100
@@ -1506,8 +1506,8 @@
 #ifdef DMALLOC
/* unsigned long mark, int not_freed_b, int 
freed_b, int details_b */
 dmalloc_log_changed (nMemCheckpoint, 1, 0, 1) ;
-dmalloc_message ( "[%d]Request freed. Exit-SVs: %d -OBJs: %d\n", getpid(),
-   sv_count, sv_objcount) ;
+dmalloc_message ( "[%d]Request freed. Exit-SVs: %d\n", getpid(),
+   sv_count) ;
 if (nMemCheckpoint2)
 {
 dmalloc_message ( "***TO PREVIOUS REQUEST***\n") ;
Index: libembperl-perl/epnames.h
===
--- libembperl-perl.orig/epnames.h  2014-10-13 23:44:08.653839074 +0200
+++ libembperl-perl/epnames.h   2016-01-14 02:01:27.702358491 +0100
@@ -325,9 +325,6 @@
 #ifndef sv_count
 #define sv_count PL_sv_count
 #endif
-#ifndef sv_objcount
-#define sv_objcount PL_sv_objcount
-#endif
 #ifndef op_mask
 #define op_mask PL_op_mask
 #endif
Index: libembperl-perl/Old.xs
===
--- libembperl-perl.orig/Old.xs 2014-10-13 23:44:08.641839222 +0200
+++ libembperl-perl/Old.xs  2016-01-14 02:03:06.254101118 +0100
@@ -252,7 +252,7 @@
 tReq * r
 char * sText
 CODE:
-lprintf (r->pApp,"[%d]MEM:  %s: SVs: %d OBJs: %d\n", r->pThread->nPid, 
sText, sv_count, sv_objcount) ;
+lprintf (r->pApp,"[%d]MEM:  %s: SVs: %d\n", r->pThread->nPid, sText, 
sv_count) ;
 
 SV *
 embperl_Escape(r, str, mode)

And here's the currently resultung test suite failure:

→ perl -Iblib/lib -Iblib/arch test.pl

loading...ok

Testing offline mode...

#0 ascii...   ok
#1 pure.htm...ok
#2 nooutput.htm...ok
#3 nooutput.htm...ok
#4 plain.htm...   
Error in Line 23
Is: >HASH%a=num=<
Should: >HASH%a=num=0<
Input:  test/html/plain.htm
Output: test/tmp/out.htm
Compared to:test/cmp/plain.htm
Log:test/tmp/test.log
Testparameter:
  repeat = 3

 ERRORS detected! NOT all tests have been passed successfully

cat: test/tmp/httpd.pid: No such file or directory

Not marking as pending or as with patch for now, as the solution is
still incomplete.

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

Bug#805170: ginkgocadx: Can't satisify build depends

[Mattia Rizzolo]

On Sun, Nov 15, 2015 at 11:23:36PM +0100, Kurt Roeckx wrote:
> On Mon, Nov 16, 2015 at 08:32:52AM +1100, Dmitry Smirnov wrote:
> > On Sunday 15 November 2015 14:17:40 Kurt Roeckx wrote:
> > > Source: ginkgocadx
> > > 
> > > The build dependencies for your package can't build satisfied.
> > 
> > Can you elaborate please?
> > I can't identify anything that I could fix in the package. 
> > "libinsighttoolkit4-dev" is a legitimate dependency but it is affected by 
> > #804575...
> 
> I didn't know about #804575 yet.  I've now set your package to
> dep-wait on the buildds.  I'm not sure if anything else needs to
> happen or that you can just close this bug.

well, the build-deps can now be satisfied, but only on amd64 and i386,
and nowhere else, because insighttoolkit4 is built only there (since
2013).

This package won't migrate to testing before all the other builds are
removed (so you need to file a request for partial removal to the ftp
masters) or you make it build otherwise without insighttoolkit4.

Also please note that the old binaries depends on old binaries not built
anymore, so it's holding cruft (not so important, but just a point).

But it also depends on vtk5 so...
Anyway, removing old binaries seems nice to me even if it won't migrate
anyway.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#367648: aptitude: Can't "Hold" a Package Being Removed Automatically

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix
Control: severity -1 wishlist


Hi Brian,

2006-05-17 13:14 Brian White:

Package: aptitude
Version: 0.2.15.9-2
Severity: minor

If a package is about to be removed because it was automatically 
installed but is no longer needed, it is not possible to press ":" to 
tell aptitude to not do this on this run.


This is important when the package being removed is the running kernel 
(because kernel-image-2.6-686 now depends on a newer version).  I'd 
like to press ":" to delay the removal of the 2.6.8-2 kernel until the 
next run, after the 2.6.8-3 kernel has been installed on this run.


My only alternative seems to be to press "+" to install the current 
version and the remember to find and remove it during a later run.


... and a decade later, finally we get to reply to your report, sorry
for the delay.


In principle, if first you unmark the package as automatically installed
("m"), then "keep" (":") should have worked and done the job.

But it is true that you cannot have it both ways, marked as
automatically installed but kept for the time being.

Basically, aptitude is designed to be eager to remove the automatically
installed packages ASAP, and some people even got angry that packages
were scheduled to be removed only the next time, not in the very same
run when they were not needed (I closed over 20 bug reports complaining
about this in one recent release of the 0.7 series).

What one can do is to schedule the action by selecting the action on the
package but quitting (in curses), or using the --schedule option in the
command line to defer this until the next time.  But this is a bit
unsafe, because the kernel can be removed unadvertently before the
system is restarted, when modules of the kernel might be needed (or
similar problems for other packages not as critical as the kernel).


One can also use user-tags for this within aptitude, e.g. marking
packages with tags "to-be-removed" and then have cron jobs (perhaps
@reboot time) reminding you to do it, or remembering to check them every
now and then.


In any case, as I explained, the current behaviour is quite ingrained
within aptitude, and has been so for a long time, and people complain
loudly when the removals of packages don't happen immediately enough, so
in principle I am marking this as +wontfix.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#810946: ginkgocadx: FTBFS

[Mattia Rizzolo]

Source: ginkgocadx
Version: 3.7.1.1573.41+dfsg-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)


Dear maintainer, your package failed to build on the buildds during a
rebuild for a transition:
https://buildd.debian.org/status/fetch.php?pkg=ginkgocadx&arch=amd64&ver=3.7.1.1573.41%2Bdfsg-4%2Bb1&stamp=1450294550

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#810943: gnuplot5-qt: incorrect font size (regression in gnuplot5 5.0.2+dfsg1-1)

[Vincent Lefevre]

Control: retitle -1 font size no longer taken into account in wxt terminals

On 2016-01-14 01:06:18 +0100, Vincent Lefevre wrote:
> After the upgrade to gnuplot5 5.0.2+dfsg1-1, the font size is now
> incorrect (much too large).

Actually it is no longer taken into account. The wxt terminal is
affected, but not the qt terminal. Testcase:


#!/bin/sh

term=${1:-wxt}

for fontsize in 5 10 15
do
  gnuplot -persist < - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#706770: keep/hold packages uninstalled

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Harald,

2013-05-05 00:47 Daniel Hartwig:

Control: block -1 by 137771
Control: tags -1 + confirmed

On 4 May 2013 23:35, Harald Dunkel  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: aptitude
Version: 0.6.8.2-1
Severity: wishlist

It would be very nice if "hold" and "keep" could be extended
to work on uninstalled packages, too.



For the moment you can use either apt-mark hold or apt_preferences(5).


Did you try the solutions above?  Using them with aptitude should work,
if not, please let me know.


If a package really Depends on another one, none of these solutions
would work (including setting them within aptitude).  The package that
depends on the one not to be installed cannot be installed without them.
It would only be valid for recommends.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#810945: odin: please drop build-dependency on removed libdcmtk2

[Mattia Rizzolo]

Source: odin
Version: 1.8.8-2
Severity: important


Actually, I see some other anomalities.
In the build-depends I see

 libdcmtk-dev | libdcmtk2-dev | libdcmtk1-dev,
 libdcmtk2,
 dcmtk,

a build-dep on dcmtk is probably wrong, I can't think why you would need
it.
Then, an explicit build-dep on libdcmtk2 is probably an error too.
Usually one relies on the -dev to depend on the current version of the
lib.
Also, the whole alternatives up there looks weird.


I haven't really tested, but all thsoe build-dep most probably could be
replaced by libdcmtk-dev only.


This weird thing is actually uselesslly holding cruft in the archive,
btw, since this is the only package that build-dep on libdcmtk2 (and 3
more binaries with old dep on it).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#644544: aptitude does not fully update suggest/recommend dependency changes on conflict resolution

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo unreproducible


Hi Yann,

2011-10-06 21:19 Yann Dirson:

Package: aptitude
Version: 0.6.4-1
Severity: normal

After pulseaudio migrated to testing with an upgrade from "suggests:
rtkit" to a "recommends", higging "U" selects rtkit for install, with
flag "auto-installed". So far, OK.

There are a couple of conflicts, and I select a resolution that
"keeps" pulseaudio - to the version that has the "suggests", that is.
But rtkit is kept, listed as "piA", but with the "reason" panel
listing no recommends or depends, but just the suggests.


I think that the problem of the case above lies in ambiguity of
interpreting what the user wants.

In this situation, if you Undo (Control-U), it would Undo previous
actions, including reverting the selection to install rtkit
automatically.

If you simply fiddle with packages back and forth, aptitude doesn't
exactly know which ones you installed willingly and which you didn't.
One interpretation is that maybe you liked the decision to install
rtkit, and just decided to not install the dependency after all.  It
might also happen that other packages that you had installed recommended
rtkit, so once selected to install, it will not be removed
automatically.

It would be nice to know what happened if/when you pressed 'g' for the
preview, I guess that it would have deselected rtkit.


Trying to reproduce this with a random set of packages
(lib4store0-dbgsym and lib4store0), if I press "+" on the former the
latter gets "piA", same as in your case.  If then I press "-" on
lib4store0-dbgsym to keep it uninstalled, lib4store0 gets immediately
deselected (== kept uninstalled).

So I think that this got somehow fixed in the interim.

Can you still reproduce it?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#599790: Adding entries to /etc/apt/preferences "unholds" packages

[Manuel A. Fernandez Montecelo]

Control: tags -1 + unreproducible
Control: close -1


Hi,

2010-10-11 20:38 David Kalnischkies:

reassign 599790 aptitude 0.4.11.11-1~lenny1
thanks

On Mon, Oct 11, 2010 at 10:16, Keith Edmunds  wrote:

Package: apt
Version: 0.7.20.2+lenny2
Severity: normal


Can't reproduce it here with unstable APT and as you have
used aptitude in all but the policy command it feels more
like an aptitude problem - which is not reproducible for me here
in unstable either, so its maybe already fixed…
(but unfortunately i have not enough time to check this deeper)


I'm going to trust David here and consider this fixed.

Please reopen if you still experience this behaviour with more recent
versions.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep

[Mattia Rizzolo]

On Wed, Jan 13, 2016 at 07:12:38PM +, Jose M Calhariz wrote:
>  * Package name: rep-gtk

ok, let the party begin! :)

* you removed a old transition package.
  + \o/ yay less cruft in the archive!
  + FYI, I confirmed by `dak rm -Rbn rep-gtk-gnome` that it is a leaf
package.
  + also please remove debian/rep-gtk-gnome.NEWS
* debian/control:
  + a version costriction in a Suggest is really useless.  As in, you
have no assurances *at all* that it'll be followed.
But then, you build-dep on librep >= $version, so you'll get a
depends on that version, so not all might be lost :)
tl;dr: you don't need to do anything here, but be aware that
versioned Suggests are meaningless.
  + the build-dep on autotools-dev is useless, please remove it.
  + I still get vcs-field-not-canonical by lintian.  indeed Vcs-Git is
wrong (there is a /git/ too much in the middle).  otherwise, you
might want to use https:// for Vcs-Git too instead of the dumb
git://.  As you prefer.
  + I have a extended-description-is-probably-too-short, please fix.
* debian/changelog:
  + 2 trailing whitespaces at line 4.
  + "remove upstream debian directory" ???  what's this?
  + "New localization of files for package rep-gtk." and this?
  + "Replace sed command by dh_listpackages." this is not there anymore
  + "Merge the packaging work of Christopher Roy Bratusek." be more
verbose in this.  short dh, compat 9, dep5, blablabla
  + s/read ability/readability/ maybe?
  + mention the removal of rep-gtk-gnome.
  + you need to target experimental, unstable won't be able to satisfy
the dependency on librep until the transition start (where you'll
need to re-upload the packages on unstable.  actually it would be
enough to have them ready, bug given that there are a lot of
changes, and you are a sponsored person where there are reviews
going on, better have them in experimental, and re-upload them in
unstable later).
* debian/rules:
  + override_dh_configure is unneed.  as I said with librep, those flags
are already exported in compat 9.
- also , there is trailing whitespace here, but if you remove the
  whole line...
  + override_dh_install just to call dh_install ? ;)
  + override_dh_installexamples => be aware you can also write the
directory name in debian/examples (up to you if you prefer small
files in debian/ or lines in d/rules)
  + don't DH_VERBOSE need to be exported to work?
* you're building static libraries.  Do you really need them?  In Debian
  we don't like static libraries.  Given that this is a standard autofoo
  package, --disable-static to configure should do the trick.
  + this will also get rid of unstripped-static-library and
non-empty-dependency_libs-in-la-file lintian tags.
* something to say about https://bugs.debian.org/680449 ?


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#810926: [Debian-med-packaging] Bug#810926: dcmtk-www: missing file name extension of /etc/apache2/conf-available/dcmtk

[Gert Wollny]

tags 810926 wontfix 
thanks

Thanks, for reporting this issue. However, getting this fixed in
Debian/stable is probably not going to happen, because there is a
simple workaround (like you posted), and Debian policy is to only
upload fixes for important or serious bugs like security problems or
things that make the package unusable (See Policy 5.5.1). 

On the other hand, DCMTK upstream dropped the www component from their
latest version, which means that this package will actually vanish with
the next release - the latest version of DCMTK in unstable already
comes without this dcmtk-www package.

For this reason I tagged the bug as wontfix. 

If this functionality is vital to you, please talk to upstream. I've
seen that you had already contact with one of their developers on the
debian-med mailing list. 

Best, 
Gert

[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#u
pload-stable

Bug#810944: querybts: Mutt looks garbled after SIGWINCH

[Daniel Shahaf]

Package: reportbug
Version: 6.6.6
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?

I ran 'querybts' in an xterm and resized the xterm while querybts was running.

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

1. Resize the terminal to 80x25.
2. Run 'querybts 808808'.
3. Maximize the terminal window.  [This can be done during or after the
   next step, too, but must be done after typing  at the end of
   the previous step.]
4. Type  to close 'less' and open 'mutt'.

   * What was the outcome of this action?

Mutt only used the top-left 80x25 cells of the terminal.

   * What outcome did you expect instead?

Mutt using the full size of the maximized terminal.

   *

The root of the problem is that the $LINES and $COLUMNS environment variables
have outdated values after the resize.  Having a SIGWINCH handler that either
unsets those two variables or updates their values fixes the issue.  Patches
to do both are attached.

(The patches are mutually exclusive.)

Cheers,

Daniel

P.S. Full disclosure: The code in the putenv() patch is based on Apache
Licensed code from [1].  I assume that is okay.
[1] 
https://svn.apache.org/viewvc/subversion/trunk/build/run_tests.py?revision=1717356&view=markup#l81


-- Package-specific info:
** Environment settings:
DEBEMAIL="Daniel Shahaf "
DEBFULLNAME="Daniel Shahaf"
INTERFACE="text"

** /home/daniel/.reportbugrc:
reportbug_version "6.6.3"
mode standard
ui text
realname "Daniel Shahaf"
email "danie...@apache.org"
no-cc
header "X-Debbugs-CC: danie...@apache.org"
smtphost reportbug.debian.org
mbox_reader_cmd "mutt -f %s"

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

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

Versions of packages reportbug depends on:
ii  apt   1.1.10
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.86-7
ii  exim4-daemon-light [mail-transport-agent]  4.86-7+b1
ii  file   1:5.25-2
ii  gnupg  1.4.20-1
pn  python-gtk2
pn  python-gtkspellcheck   
pn  python-urwid   
pn  python-vte 
pn  xdg-utils  

Versions of packages python-reportbug depends on:
ii  apt   1.1.10
ii  file  1:5.25-2
ii  python-debian 0.1.27
ii  python-debianbts  2.6.0
pn  python:any

python-reportbug suggests no packages.

-- no debconf information
diff --git a/bin/querybts b/bin/querybts
index 17d5328..b3cb9dc 100755
--- a/bin/querybts
+++ b/bin/querybts
@@ -21,6 +21,7 @@
 #  ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
 #  SOFTWARE.
 
+import signal
 import sys
 import os
 import optparse
@@ -46,6 +47,24 @@ VERSION = "querybts %s" % VERSION_NUMBER
 
 
 def main():
+# Set up signal handlers
+import fcntl, termios, struct
+def handler(signum, frame):
+if signum == signal.SIGWINCH:
+# The terminal has been resized.  Update $LINES and $COLUMNS,
+# since some programs (including Mutt) use those in preference
+# to TIOCGWINSZ for determining their terminal size, and would
+# look garbled without this.
+fd = os.open(os.ctermid(), os.O_RDONLY)
+lines, columns = struct.unpack('hh',
+   fcntl.ioctl(fd, termios.TIOCGWINSZ,
+   struct.pack('hh', 0, 0)))
+os.close(fd)
+os.putenv('COLUMNS', str(columns))
+os.putenv('LINES', str(lines))
+pass
+signal.signal(signal.SIGWINCH, handler)
+
 # default values for cli options
 defaults = dict(system='debian', archived=False,
 http_proxy='', interface='text',
diff --git a/bin/querybts b/bin/querybts
index 17d5328..154bc5d 100755
--- a/bin/querybts
+++ b/bin/querybts
@@ -21,6 +21,7 @@
 #  ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
 #  SOFTWARE.
 
+import signal
 import sys
 import os
 import optparse
@@ -46,6 +47,20 @@ VERSION = "querybts %s" % VERSION_NUMBER
 
 
 def main():
+# Set up signal handlers
+def handler(signum, frame):
+if signum == signal.SIGWINCH:
+# The terminal has been resized.
+#

Bug#810655: [b...@rcdrun.com: Re: Bug#810655: libembperl-perl: post-installation script returned error]

[Axel Beckert]

Control: tag -1 + pending

Hi,

Dominic Hargreaves wrote:
> > > and it's definitely a bug that the postinst script unconditionally
> > > tries to configure mod_perl even when libfcgi-perl is recommended as
> > > an alternative.
> > 
> > That's the actual bug.
> > 
> > I'll have a look at it. But I likely can't really fix it in Sid before
> > the FTBFS with Perl 5.22 (#806897) is fixed.
> 
> *nod*.

So for now I've committed and pushed an _untested_ fix:
https://anonscm.debian.org/cgit/pkg-perl/packages/libembperl-perl.git/commit/?id=bfc7efa2

> It's probably a candidate for a stable point release, but given the easy
> workaround, I don't think it's urgent.

Indeed. I'll see if I can test the fix somewhere on stable.

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

Bug#734086: lockdev -- ROM; Obsolete and replaced by flock

[Craig McQueen]

This change from UUCP style lockfiles to flock() is still lacking 
follow-through of communication with the broader Linux community. Many Linux 
programs would still be using the older UUCP style locking of serial ports I 
think.

I've sent a message to the Serial HOWTO author David Lawyer regarding this 
issue.

Note that this change seems to have been pioneered by Roger Leigh, who 
according to my searching on the Internet, seems to have left Debian Linux for 
FreeBSD in the last year or so. See his comments on the following article:
http://changelog.complete.org/archives/9299-has-modern-linux-lost-its-way-some-thoughts-on-jessie
So now this change is lacking its original pioneer and advocate.

Bug#810943: gnuplot5-qt: incorrect font size (regression in gnuplot5 5.0.2+dfsg1-1)

[Vincent Lefevre]

Package: gnuplot5-qt
Version: 5.0.2+dfsg1-1
Severity: important

After the upgrade to gnuplot5 5.0.2+dfsg1-1, the font size is now
incorrect (much too large).

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 gnuplot5-qt depends on:
ii  gnuplot5-data5.0.2+dfsg1-1
ii  libc62.21-6
ii  libcairo21.14.6-1
ii  libedit2 3.1-20150325-1+b1
ii  libgcc1  1:5.3.1-5
ii  libgd3   2.1.1-4+b1
ii  libglib2.0-0 2.46.2-3
ii  liblua5.1-0  5.1.5-8
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libqt5core5a 5.5.1+dfsg-12
ii  libqt5gui5   5.5.1+dfsg-12
ii  libqt5network5   5.5.1+dfsg-12
ii  libqt5printsupport5  5.5.1+dfsg-12
ii  libqt5svg5   5.5.1-2
ii  libqt5widgets5   5.5.1+dfsg-12
ii  libstdc++6   5.3.1-5
ii  libwxbase3.0-0v5 3.0.2+dfsg-1.2
ii  libwxgtk3.0-0v5  3.0.2+dfsg-1.2
ii  libx11-6 2:1.6.3-1

gnuplot5-qt recommends no packages.

Versions of packages gnuplot5-qt suggests:
ii  gnuplot5-doc  5.0.2+dfsg1-1

-- no debconf information

Bug#809815: [feature request] linux-image-4.3.0-1-sparc64-smp: tpm random module for linux LDOMs

[Anatoly Pugachev]

On Mon, Jan 11, 2016 at 3:08 AM, Ben Hutchings  wrote:
> On Thu, 2016-01-07 at 20:30 +0300, Anatoly Pugachev wrote:
>> Can you please suggest, what to do next? Close this bugreport as
>> invalid, and fill new one against n2_rng module in debian, or report
>> first to lkml? Thanks.
> [...]
>
> You should send this patch upstream (linux-cry...@vger.kernel.org and
> sparcli...@vger.kernel.org mailing lists).

Ben,
submitted to both mentioned mailing lists, it got to DaveM processing
queue, see http://patchwork.ozlabs.org/project/sparclinux/list/?submitter=68078
As I told earlier, I'm not a kernel developer in any form, not even
C/C++ programmer. I'm not sure I would be able to answer to any
objections on this patch.
But thanks anyway, probably someone else (oracle guys, with their
linux for sparc [L4S] project) would be able to make this patch to
kernel.

Bug#810942: ITP: premailer - Turns CSS blocks into style attributes

[Geoffrey Thomas]

Package: wnpp
Severity: wishlist
Owner: Geoffrey Thomas 

* Package name: premailer
  Version : 2.9.7
  Upstream Author : Peter Bengtsson 
* URL : http://github.com/peterbe/premailer
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Turns CSS blocks into style attributes

 When you send HTML emails you can't use style tags but instead you have
 to put inline style attributes on every element. premailer parses an
 HTML page, looks up style blocks and parses the CSS. It then uses the
 lxml.html parser to modify the DOM tree of the page accordingly.

I intend to team-maintain this package in DPMT.

-- 
Geoffrey Thomas
geo...@hudson-trading.com

Bug#810894: src:linux: GPIO probe failure on Linkstation LS-WXL/WSXL

[Ben Hutchings]

On Thu, 2016-01-14 at 08:22 +0900, Roger Shimizu wrote:
> Thanks for your feedback, Uwe!
> 
> On Thu, Jan 14, 2016 at 4:19 AM, Uwe Kleine-König
>  wrote:
[...]
> > Looking at the device tree I'd say it's correct that the gpio cannot be
> > controlled from user space because it's used to enable usb.
> 
> I don't understand why it's not able to control the gpio.
> Could you please explain in detail?
> 
> I'm the upstream contributor for this DTS.
> I know there may be something wrong with the gpio part, but I don't
> know how to know which part is not working.
[...]

I think the 'gpios' property needs to be named 'gpio'.

Ben.

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

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

Bug#786805: Adopting y-u-no-validate

[Sean Whitton]

Dear Jacob,

This is a useful extension.  Are you still looking for someone to take
it over?  I'm willing to.  I'm currently getting involved in packaging
Iceweasel extensions for Debian (I currently have an RFS for uBlock).

Sean


signature.asc
Description: PGP signature

Bug#810871: [buildd-tools-devel] Bug#810871: [sbuild] Please provide a way to set an environment variable to the build directory

[Johannes Schauer]

Hi,

Quoting Katsuhiko Nishimra (2016-01-13 04:33:59)
> I'm using ccache with cmake-using projects and have encountered a lot of
> cache misses.  I figured out the problem is that cmake passes full paths to a
> compiler, and that CCACHE_BASEDIR provides a workaround.  However, sbuild
> creates unpredictably named build directories and I cannot find a way to set
> CCACHE_BASEDIR properly.  Could you consider to provide a way to set an
> environment variable to the current build directory?

Is this documentation not working for you:

https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild

If you just need a stable build path, is the --build-path option not working
for you?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#736380: Still looking to adopt?

[Sean Whitton]

Dear Matt,

Are you still interested in adopting paredit?  Otherwise, I'd be willing to.

Thanks.

Sean


signature.asc
Description: PGP signature

Bug#810939: The bug is known, actually

[Patrice Pillot]

Hi,

As I tried to investigate the temporary file permission I noticed the 
/tmp/mozilla_mozillaUser0 directory which led me to :

- https://bbs.archlinux.org/viewtopic.php?id=206506 then to
- https://bugzilla.mozilla.org/show_bug.cgi?id=1233434

This explains everything and the workarounds are pretty easy to implement.

Sorry I could not find this earlier since I focused on Debian BTS. At the 
same time, this report is now here for the record...


I hope this shall be fixed in the version presently in experimental since 
the Mozilla bug reports indicates this is fixed in upstream 44.0 b4.


Bye,

phep

Bug#810894: src:linux: GPIO probe failure on Linkstation LS-WXL/WSXL

[Roger Shimizu]

Thanks for your feedback, Uwe!

On Thu, Jan 14, 2016 at 4:19 AM, Uwe Kleine-König
 wrote:
> Hello Roger,
>
> On 01/13/2016 02:11 PM, Roger Shimizu wrote:
>> Package: src:linux
>> Version: 3.16.7-ckt20-1+deb8u1
>> Severity: normal
>> Control: notfound -1 3.16.7-ckt4-3
>> Control: found -1 3.16.7-ckt7-1
>> Control: found -1 3.16.7-ckt20-1+deb8u1
>> Control: notfound -1 4.2.6-3~bpo8+2
>> Control: notfound -1 4.3.3-5~bpo8+1
>> Control: notfound -1 4.4~rc8-1~exp1
>>
>> I need to run the following command to enable USB port on Linkstation
>> LS-WXL/WSXL (armel/kirkwood with DTS [0] ):
>>   echo 37 >/sys/class/gpio/export
>>   echo out > /sys/class/gpio/gpio37/direction
>>   echo 1 > /sys/class/gpio/gpio37/value
>
> Side note: you can shorten that to:
>
> echo 37 > /sys/class/gpio/export
> echo high > /sys/class/gpio/gpio37/direction

Learned new tips. Thank you!

>> The 3-line script runs well on Jessie rootfs + kernel listed below:
>> - 3.16.7-ckt4-3
>> - 4.2.6-3~bpo8+2
>> - 4.4~rc8-1~exp1
>> But fails from 3.16.7-ckt7-1 to 3.16.7-ckt20-1+deb8u1 (latest jessie kernel).
>>
>> The error message is like this:
>> # echo 37 >/sys/class/gpio/export
>> -bash: echo: write error: Device or resource busy
>
> Looking at the device tree I'd say it's correct that the gpio cannot be
> controlled from user space because it's used to enable usb.

I don't understand why it's not able to control the gpio.
Could you please explain in detail?

I'm the upstream contributor for this DTS.
I know there may be something wrong with the gpio part, but I don't
know how to know which part is not working.

> A quick look at the provided dmesg for 3.16.7-ckt7-1 makes me expect
> that usb works there without the gpio commands above? If so there is no
> bug, right?

Yes, dmesg shows USB is recognized. But actually it's not working
until user land's gpio export and setting.
If gpio export fails, the USB won't work at all.
I guess the gpio pin is to set whether to give USB power.

Cheers,
Roger

Bug#810941: "systemctl stop gdm3" leaves session for Debian-gdm user (user-113.slice) running

[Josh Triplett]

Package: gdm3
Version: 3.18.2-1
Severity: normal

Recently (not sure when this changed), running "systemctl stop gdm3" no
longer stops all gdm3-related processes; it leaves portions of the
greeter session running under "user-113.slice", running as the
Debian-gdm user.

This breaks "systemctl restart gdm3" and similar mechanisms.  Currently,
to fully restart gdm3, I have to stop gdm3, stop user-113.slice, and
then start gdm3 again.

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.40-3
ii  adduser   3.113+nmu3
ii  dconf-cli 0.24.0-2
ii  dconf-gsettings-backend   0.24.0-2
ii  debconf [debconf-2.0] 1.5.58
ii  gir1.2-gdm-1.03.18.2-1
ii  gnome-session [x-session-manager] 3.18.1.2-1
ii  gnome-session-bin 3.18.1.2-1
ii  gnome-settings-daemon 3.18.2-1
ii  gnome-shell   3.18.3-2
ii  gnome-terminal [x-terminal-emulator]  3.18.2-1
ii  gsettings-desktop-schemas 3.18.1-1
ii  libaccountsservice0   0.6.40-3
ii  libaudit1 1:2.4.5-1
ii  libc6 2.21-6
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra0  0.30-2.1
ii  libgdk-pixbuf2.0-02.32.3-1
ii  libgdm1   3.18.2-1
ii  libglib2.0-0  2.46.2-3
ii  libglib2.0-bin2.46.2-3
ii  libgtk-3-03.18.6-1
ii  libpam-modules1.1.8-3.2
ii  libpam-runtime1.1.8-3.2
ii  libpam-systemd228-4
ii  libpam0g  1.1.8-3.2
ii  librsvg2-common   2.40.13-1
ii  libselinux1   2.4-3
ii  libsystemd0   228-4
ii  libwrap0  7.6.q-25
ii  libx11-6  2:1.6.3-1
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-1
ii  lsb-base  9.20160110
ii  metacity [x-window-manager]   1:3.18.1-1
ii  mutter [x-window-manager] 3.18.2-1
ii  policykit-1   0.105-14
ii  ucf   3.0031
ii  x11-common1:7.7+12
ii  x11-xserver-utils 7.7+5

Versions of packages gdm3 recommends:
ii  at-spi2-core2.18.3-3
ii  desktop-base8.0.2
ii  x11-xkb-utils   7.7+2
pn  xserver-xephyr  
ii  xserver-xorg1:7.7+12
ii  zenity  3.18.1.1-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.18.2-1
ii  libpam-gnome-keyring  3.18.3-1

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
AutomaticLoginEnable = true
AutomaticLogin = josh
[security]
[xdmcp]
[greeter]
[chooser]
[debug]


-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#810940: xserver-xorg-video-intel: intermittent segmentation fault when manipulating inkscape, marble, or vlc

[Daniel Kahn Gillmor]

Package: xserver-xorg-video-intel
Version: 2:2.99.917-2
Severity: normal

I'm using a thinkpad X220.  I launch X11 from vt1 (after logging in to
a text-mode console) with:

 exec startx &>~/.xsession-errors

I get intermittent X.org crashes (segmentation faults) which usually
happen when i do things like:

 * dragging an object within inkscape
 * adjusting sizing, volume, or position of a vlc window
 * zooming or panning inside a marble window

Here's one of the .xsession-errors outputs from a recent crash:

--
X.Org X Server 1.17.3
Release Date: 2015-10-26
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
Current Operating System: Linux alice 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5 
(2016-01-04) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.3.0-1-amd64 
root=/dev/mapper/vg_alice0-root ro quiet
Build Date: 27 October 2015  11:41:02PM
xorg-server 2:1.17.3-2 (http://www.debian.org/support) 
Current version of pixman: 0.33.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/dkg/.local/share/xorg/Xorg.0.log", Time: Tue Jan 12 
22:21:11 2016
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
The value for the SHELL variable was not found the /etc/shells file

This incident has been reported.
(WW) dropping event due to full queue!
(WW) dropping event due to full queue!
(EE) 
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e) [0x565092d896fe]
(EE) 1: /usr/lib/xorg/Xorg (0x565092bd4000+0x1b9949) [0x565092d8d949]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f27bc569000+0x336e0) 
[0x7f27bc59c6e0]
(EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f27b7ee2000+0x22b0d) 
[0x7f27b7f04b0d]
(EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f27b7ee2000+0x23cb7) 
[0x7f27b7f05cb7]
(EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f27b7ee2000+0x2f393) 
[0x7f27b7f11393]
(EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f27b7ee2000+0x549e5) 
[0x7f27b7f369e5]
(EE) 7: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f27b7ee2000+0x54c59) 
[0x7f27b7f36c59]
(EE) 8: /usr/lib/xorg/Xorg (0x565092bd4000+0x1413b3) [0x565092d153b3]
(EE) 9: /usr/lib/xorg/Xorg (0x565092bd4000+0xf62d8) [0x565092cca2d8]
(EE) 10: /usr/lib/xorg/Xorg (0x565092bd4000+0xf7715) [0x565092ccb715]
(EE) 11: /usr/lib/xorg/Xorg (0x565092bd4000+0x58a1f) [0x565092c2ca1f]
(EE) 12: /usr/lib/xorg/Xorg (0x565092bd4000+0x5cb4b) [0x565092c30b4b]
(EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf0) 
[0x7f27bc589870]
(EE) 14: /usr/lib/xorg/Xorg (0x565092bd4000+0x46f5e) [0x565092c1af5e]
(EE) 
(EE) Segmentation fault at address 0x0
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/home/dkg/.local/share/xorg/Xorg.0.log" 
for additional information.
(EE) 
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
xinit: connection to X server lost

waiting for X server to shut down 
s not provided by any .service files

(nm-applet:13520): nm-applet-WARNING **: Failed to show notification: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files

(nm-applet:13520): GLib-CRITICAL **: Source ID 307 was not found when 
attempting to remove it

(nm-applet:13520): nm-applet-WARNING **: Failed to show notification: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files
xscreensaver-command: activating and locking.

xscreensaver-command: activating and locking.


(nm-applet:13520): nm-applet-WARNING **: Failed to show notification: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files
** Message: Remote error from secret service: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was 
not provided by any .service files
xscreensaver-command: activating and locking.

urxvt: X connection to ':0' broken, unable to recover, exiting.
urxvt: X connection to ':0' broken, unable to recover, exiting.
Connection lost to X server `:0'
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
urxvt: X connection to ':0' broken, unable to recover, exiting.
Connection lost to X server `:0'
When compile

Bug#810748: systemd does not mount /usr in initramfs, breaking split /usr

[Nis Martensen]

> If I read the code correctly, than this patch is the culprit:
> http://sources.debian.net/src/systemd/215-17%2Bdeb8u2/debian/patches/Skip-filesystem-check-if-already-done-by-the-initram.patch/?hl=29#L29
> 
> When systemd is run in the initramfs (which it is with dracut), there
> is no /run/initramfs/fsck-usr.

The correct workaround is to mark the /usr entry in /etc/fstab with
x-initrd.mount. The fact that this solves the problem confirms the analysis.

Perhaps interesting side note: When dracut does not use systemd, its
usrmount module will use the flag file /run/initramfs/usr-fsck to
indicate that fsck has been performed [1]. Might be worth agreeing on a
common file name for this?

[1]
https://sources.debian.net/src/dracut/044%2B3-2/modules.d/98usrmount/mount-usr.sh/#L95

When systemd is used in the initramfs, it is itself responsible for
mounting /usr (and running fsck or not). The "culprit" patch breaks
that. We need a solution that works both inside and outside of the
initramfs.

Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1

[Holger Levsen]

Hi Adam,

On Mittwoch, 13. Januar 2016, Adam D. Barratt wrote:
> Whichever approach you decide to take to fixing this, please bear in
> mind that there are only a few days until the 8.3 window closes.

thanks for the heads up - I've planned to fix this properly until Friday…


cheers,
Holger


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

Bug#810939: iceweasel: Iceweasel fails to download files

[toto]

Package: iceweasel
Version: 43.0.2-1+b1
Severity: important

Dear Maintainer,

I upgraded my testing box last Friday (2016-01-08) and this upgraded Iceweasel
to 43.0.2. Since next Monday Iceweasel stopped downloading files despite there
were no significant changes on the machine in the 2 days span.

Presently, out of the 2 usual users of this machine, only one of them is able
to download files using Iceweasel. The bug does not (yet :-/) shows on my
laptop also (running testing too).

For those reasons, I suspected a profile problem and created a brand new user
on the machine (the one from which I report this bug) to investigate this
problem.  I ran Iceweasel, pointed it to some PDF, LibreOffice of even .dsc 
file (on
the Debian site) URLs.

PDF files are first previewed in Iceweasel, which is expected (and reveals that
this is not a network related problem), but when I try to download them (in
order to save them locally) with the button at the top right of the previewer,
the toolbar big blue pointing down arrow sort of animates itself but nothing is
downloaded and displaying the download list exhibits "Échec" for the files
(which means /failure/ in French).

When I click on links pointing to LibreOffice or .dsc files the big blue
arrow /animates/ too and the word 'Échec' shows in the download list again.

I checked and changed the configured download directory without any success. I
try changing Iceweasel preferences for PDF file handling to "Always ask" with
no success: the dialog does not even show, only the big blue arrow animates and
still the word "Échec"... which seems to eliminate a directory permission
problem, except maybe on some cache folder (where?). I *can* write to /tmp, by
the way.

Please note that on my regular account where I have the DownThemAll extension,
I work around this bug using this extension. Maybe this shall be useful for you.

What puzzles me more is that the other regular account on the computer does not
(yet) have this problem.

Just to make it clear:
- I checked that the mime type was correctly set (e.g.
  application/pdf)
- I checked (using an apache instance the logs of which I can check)
  the file is really transmitted. If the Content-Disposition is "inline", then
  the PDF is previewed, if Content-Disposition is "attachment" the download 
fails
- for those file type for which there is no preview in Iceweasel, the download
  fails.
- I just made a new try with a second brand new user account created on the box.

Thanks in advance,

phep


-- Package-specific info:

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

Name: Français Language Pack locale
Location: 
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-fr
Status: enabled

-- Plugins information
Name: DjView-4.10.4
Location: /usr/lib/mozilla/plugins/nsdejavu.so
Package: djview-plugin
Status: enabled

Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: Shockwave Flash (11.2.202.559)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled


-- Addons package information
ii  djview-plugin  4.10.4-1 amd64Browser plugin for the DjVu image
ii  gnome-shell3.18.1-1 amd64graphical shell for the GNOME des
ii  iceweasel  43.0.2-1+b1  amd64Web browser based on Firefox
ii  iceweasel-l10n 1:43.0.2-1   all  French language package for Icewe

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.21-6
ii  libcairo2 1.14.4-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-5
ii  libgdk-pixbuf2.0-02.32.3-1
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.9.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.1-5
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1

Bug#696475: news?

[VA]

Hi Pierre,

Any news on this issue? I experience the same bug and it makes the 
software much less useful.

Bug#810938: exim4-daemon-light: Cannot assign requested address: daemon abandoned at each startup

[Manuel Bilderbeek]

Package: exim4-daemon-light
Version: 4.86-7+b1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Package upgrades in testing:

===

Aptitude 0.7.5: log report
ma, jan 11 2016 19:12:03 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 27 packages, and remove 0 packages.
2061 kB of disk space will be used

[HOLD, DEPENDENCIES] libxine2-plugins:amd64 1.2.6-1
[HOLD] ifupdown:amd64 0.7.54
[UPGRADE] gir1.2-soup-2.4:amd64 2.52.1-1 -> 2.52.2-1
[UPGRADE] kbd:amd64 2.0.3-1 -> 2.0.3-2
[UPGRADE] klibc-utils:amd64 2.0.4-4 -> 2.0.4-6
[UPGRADE] libgraphite2-3:amd64 1.3.3-1 -> 1.3.4-2
[UPGRADE] libklibc:amd64 2.0.4-4 -> 2.0.4-6
[UPGRADE] libopusfile0:amd64 0.6-1+b1 -> 0.7-1
[UPGRADE] liborcus-0.10-0v5:amd64 0.9.2-3 -> 0.9.2-4
[UPGRADE] libpcre16-3:amd64 2:8.35-8 -> 2:8.38-1
[UPGRADE] libpcre3:amd64 2:8.35-8 -> 2:8.38-1
[UPGRADE] libpcre3:i386 2:8.35-8 -> 2:8.38-1
[UPGRADE] libpcre3-dev:amd64 2:8.35-8 -> 2:8.38-1
[UPGRADE] libpcre32-3:amd64 2:8.35-8 -> 2:8.38-1
[UPGRADE] libpcrecpp0v5:amd64 2:8.35-8 -> 2:8.38-1
[UPGRADE] libpython3.4:amd64 3.4.4-1 -> 3.4.4-2
[UPGRADE] libpython3.4-minimal:amd64 3.4.4-1 -> 3.4.4-2
[UPGRADE] libpython3.4-stdlib:amd64 3.4.4-1 -> 3.4.4-2
[UPGRADE] libsoup-gnome2.4-1:amd64 2.52.1-1 -> 2.52.2-1
[UPGRADE] libsoup2.4-1:amd64 2.52.1-1 -> 2.52.2-1
[UPGRADE] manpages:amd64 3.74-1 -> 4.04-0.1
[UPGRADE] manpages-dev:amd64 3.74-1 -> 4.04-0.1
[UPGRADE] nano:amd64 2.4.2-1+b1 -> 2.4.3-1
[UPGRADE] openssh-client:amd64 1:7.1p1-5 -> 1:7.1p1-6
[UPGRADE] openssh-server:amd64 1:7.1p1-5 -> 1:7.1p1-6
[UPGRADE] openssh-sftp-server:amd64 1:7.1p1-5 -> 1:7.1p1-6
[UPGRADE] publicsuffix:amd64 20151205-1 -> 20160104-1
[UPGRADE] python3.4:amd64 3.4.4-1 -> 3.4.4-2
[UPGRADE] python3.4-minimal:amd64 3.4.4-1 -> 3.4.4-2


Log complete.

===

Aptitude 0.7.5: log report
ma, jan 11 2016 19:13:19 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 0 packages, and remove 1 packages.
173 kB of disk space will be freed

[HOLD, DEPENDENCIES] libxine2-plugins:amd64 1.2.6-1
[REMOVE, DEPENDENCIES] ifupdown:amd64 0.7.54

Log complete.

===

Aptitude 0.7.5: log report
ma, jan 11 2016 20:13:54 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 3 packages, and remove 0 packages.
849 kB of disk space will be used

[HOLD, DEPENDENCIES] libxine2-plugins:amd64 1.2.6-1
[INSTALL, DEPENDENCIES] python-argcomplete:amd64 0.8.1-1
[INSTALL, DEPENDENCIES] python-ipaddr:amd64 2.1.11-2
[INSTALL] ifupdown2:amd64 1.0~git20151029-1


Log complete.

===


Ever since I did that upgrade, I get a mail from root when I boot my system
that contains:

exim paniclog /var/log/exim4/paniclog on sonata has non-zero size, mail system 
might be broken. The last 10 lines are quoted below.

2016-01-12 18:52:17 socket bind() to port 25 for address ::1 failed: Cannot 
assign requested address: daemon abandoned
2016-01-13 08:17:34 socket bind() to port 25 for address ::1 failed: Cannot 
assign requested address: daemon abandoned

(I booted the system twice since that upgrade, so the above 2 entries are from
these 2 boots.)

OTOH, the fact that I get the mail seems to indicate that exim is working
fine... So why do I get these mails?

-- Package-specific info:
Exim version 4.86 #3 built 28-Nov-2015 17:45:31
Copyright (c) University of Cambridge, 1995 - 2015
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2015
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC PRDR 
OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local 

Bug#810788: ITP: openshot-qt -- high quality video editing and animation solutions

[gregor herrmann]

On Tue, 12 Jan 2016 12:42:25 +, Ghislain Vaillant wrote:

> > Is this about packaging the new 2.x series separately?
> Yes indeed. The rationales for it is that Jonathan (the upstream developer),
> already provides different source packages in respective PPAs for 1.x [1]
> and 2.x [2].
[..]
> > Please strongly consider coordinate with openshot maintainer, e.g. to
> > maybe ship an openshot-common package with reusable parts.
> Already done. Jonathan also happens to be the Debian maintainer of the
> current
> openshot package. He is happy to have someone managing this over on the
> Debian
> side.

This sounds all good, thanks for the clarifications!
 

Cheers,
gregor

-- 
 .''`.  Homepage https://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: Cranberries: Linger


signature.asc
Description: Digital Signature

Bug#810937: creepy: Migrate code and dependencies to python 3

[Petter Reinholdtsen]

Package: creepy
Version: 1.4.1-4
Severity: wishlist
Forwarded: https://github.com/jkakavas/creepy/issues/32

At the moment creepy is a python 2 application.  It will require some
editing before it work with python 3 (at least print calls and exception
handling, based on my testing), and some of the dependencies need to be
available for python 3 too.

I've asked upstream about his plans for python 3 support in
https://github.com/jkakavas/creepy/issues/32 >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#809166: networking.service does not prevent ifdown with network file systems

[Martin Pitt]

Martin Pitt [2016-01-13 23:30 +0100]:
> I filed https://bugs.debian.org/XX, thanks Michael for pointing
> out conf.d/.

"Let's type this mail while I wait for the bug number" syndrome,
sorry. It's .

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


signature.asc
Description: Digital signature

Bug#809166: networking.service does not prevent ifdown with network file systems

[Martin Pitt]

Hey Guus,

Guus Sliepen [2016-01-13 16:57 +0100]:
> Great. Who shall do the honors of writing a patch/bug report?

I filed https://bugs.debian.org/XX, thanks Michael for pointing
out conf.d/.

> > But independently of that: Do you actually think it is right that
> > "ifdown" on a manual interface without any "down" command downs it?
> > That isn't documented and hasn't happened until 0.8.4, and IMHO that's
> > overzealous and might break other setups too.
> 
> Uh, didn't we discuss that in #809169? Wasn't it already the default in
> Ubuntu?

It was, but as I said the check_network_file_systems() function
short-circuited this until recently, so interfaces were never really
downed on shutdown as soon as there was any remote file system. So
this (mis)design issue in ltsp and friends didn't really pop up until
now.

> Anyway, I'm not for or against it, but I was slightly convinced by the
> use case of lots of bonding slave interfaces, that it would make sense
> to have empty inet manual interfaces that did bring interfaces up or
> down. And that still is more convincing than the use case of LTSP doing
> the wrong thing.

From a clean slate POV I agree. I'm just a bit concerned about
breaking existing systems with that. I don't have a really strong
opinion, I just noticed that this change already caused regressions
with at least one package in Debian (ltsp) and two in Ubuntu (that and
open-isci).

That downing of interfaces is really only relevant for manual
operations, right? I can't think of anything bad that would happen if
a real interface is not downed during shutdown -- in fact, doing that
has no real benefit that I can see.

> But do we need backwards compatibility? If we get LTSP and open-iscsi
> fixed in unstable, is there still a problem somewhere?

There are more use cases/packages which set up a remote root fs;
initramfs-tools itself supports root-on-NFS, tcos, custom setups with
PXE boot, etc. I haven't searched for them or analyzed them all.

Thanks,

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


signature.asc
Description: Digital signature

Bug#809623: RFS: telegram-purple/1.2.3-1

[Gianfranco Costamagna]

Hi,

>
>Seems like it, true, but sadly is necessary. The package is in version 
>control, and unless we provide pre-bundled origtars somewhere (which 
>won't happen), this has to build the origtar by invoking "make dist" in 
>the source tree.


why you cant provide pre-bundled origtars? I know some project that does 
exactly the same.

they have submodules and when they tag a new release, they also upload the 
version together
with the "minimal" one

e.g.
https://github.com/vslavik/poedit/releases

>Now this is getting absurd: the whole point of dh get-orig-source is to 
>>support people for who "git pull" is too complicated. But suddenly I can 
>assume that git is installed, although git is not pulled by build-essential?


I'm not talking about buildd machines. uscan usually is called by *developers*
who want to try to build the package.

e.g. a normal user does apt-get source telegram-purple (because it is outdated
and he want the new and shiny version)

he do the apt-get source, he do the uscan --debug, and at the end he can build
everything (maybe an uupdate).
(let us assume the new release doesn't need packaging changes of course)

>Well, either that, or roughly 8 packages that are absolutely and utterly 
>useless building libtgl. (I'm not overestimating! 3 packages for 
>tl-parser and tgl each, plus 2 packages for "generate")
>
>I agree with you that this should be avoided at *most* costs, but not at 
>*all* costs.


I fully agree there, if it can be avoided fine, but if not... we should deal
with a common sense and a trade-off.

Now I come with a question.
You want to maintain the package only in Debian? or in all linux distro around 
the globe?

you are doing the repack work as Debian work, this means that other linux 
derivatives
won't ever gain from the work, and they will need to do it again.

Pushing the tarball (complete and reduced) upstream, will save a lot of work 
for everybody



and simplify a lot the Debian packaging
(just a simple watch file, with no repack at all).

Do you agree on this point?
(I'm not saying my POV is the correct one, but sometimes Upstream and Debian 
have to fight a little
bit and find a common way :) )

cheers!

Gianfranco

Bug#803869: vtk6: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 13.01.2016 14:54, Andreas Tille wrote:
> I pinged ftpmaster yesterday to consider accepting VTK.  Hope this
> helps ...

Thanks. Unfortunately it got rejected meanwhile...

Best regards,
Andreas

Bug#697821: ITP: ppsspp -- ppsspp: A portable PSP emulator.

[Sérgio Benjamim]

Hi,

Since libpng16 is still in experimental, maybe it should be better just 
comment out the ppsspp-sdl in control and rules, and build just Qt, 
which uses this version of libpng only in the build time for the atlas 
and zimtool (and they build the atlas fonts). I think it's better than 
waiting forever for this update. PPSSPP is almost releasing its version 
1.2.0...



Sergio Benjamim


On 07/01/2016 21:10, Mattia Rizzolo wrote:

On Thu, Jan 07, 2016 at 09:10:32PM +0100, John Paul Adrian Glaubitz wrote:

Well, I've been receiving multiple bug reports through various lists in the 
past days from the libpng maintainers which asked people to fix their B-D 
regarding libpng-dev to prepare for libpng1.6 and setting these bugs as 
blockers for the transition bug.

note that most (all?) of those bugs are not filed by the maintainer, but
by another developer that seems to care more than him (or just have more
time to take care of this).
furthermore, there are more than one hundred bugs filed to date, and
ISTR not all are filed yet.  Most of those bugs involves code changes
(e.g. FTBFS with libpng1.6), not just swapping build-deps.
Those kind stuff takes several weeks, if not months.
Anyway, NMUs already started, hopefully we will be able to outline the
blockers soon enough.


And since Stretch is to be frozen on December, 5th, I'm pretty sure transition 
is going to start in the near future unless you have any more definitive 
insider information I don't have.


everybody hopes so, me too.
we deleyed this for so many years :(

Bug#810610: If package would be maintained in pkg-games git I'd do a team upload

[Sérgio Benjamim]

Hi Andreas,

Thanks for the package update.

Sergio Benjamim


On Sun, 10 Jan 2016 17:44:10 +0100 Andreas Tille  wrote:
> Hi Sérgio,
>
> I'd volunteer to do a team upload of the package fixing the bug by
> applying the patch provided by Bas if the package would be in pkg-games
> Git. Please tell me if you want me to inject the packaging into
> git.debian.org.
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>
>

Bug#810936: mesa: Add osmesa debug package

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA224

Package: mesa
Version: 11.0.8-1
Severity: normal
Tags: +patch

The mesa package currently relies on an autogenerated debug symbol package
for osmesa.  The attached patch switches this to a control file-defined
debug symbol package.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iFYEARELAAYFAlaWzzYACgkQLaxZSoRZrGHWIADdHPGjnQ7ZtgFDdvpNABa0+VO0
zi0kVwY205UfiwDeJReg2n57YcSuVpvLnRFARNmhTvNkDcE57TEFYg==
=ghYh
-END PGP SIGNATURE-

mesa-add-osmesa-debug-package.diff
Description: Binary data


mesa-add-osmesa-debug-package.diff.sig.asc
Description: PGP signature

Bug#810815: gramps: gramps crashes systematically when trying to select an event type

[Ross Gammon]

Control: tags -1 confirmed

Hi Janusz,

On 01/12/2016 03:21 PM, Janusz S. Bień wrote:
> Package: gramps
> Version: 4.2.1~dfsg-2
> Severity: normal
> 
> When I try to add the death event to a person for which the birth event
> has not been created, gramps crashes with messages:

I can confirm this happens for me as well.

I was about to package Gramps 4.2.2 which was recently released.
Hopefully, it has aleady been fixed in this new version. I will check.

Thanks for the report.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#772171: Shouldn't this have a higher severity?

[Jean-Francois Dockes]

John Eikenberry writes:
 > 
 > Doesn't this bug make it impossible to index any new data? Shouldn't it have 
 > a
 > higher severity than normal? It completely breaks recoll for my use, so I'd
 > give it grave unless there are other use cases where it still works.
 > 
 > Error output I get when I run 'recollindex'...
 > 
 > :2:../index/indexer.cpp:298:ConfIndexer::createAspellDict: aspell init 
 > failed: Could not open shared library [/usr/lib/libaspell.so] 
 > [/usr/lib/libaspell.so.15] [/usr/lib/libaspell.so.16] 
 > [/usr/lib64/libaspell.so] [/usr/lib64/libaspell.so.15] 
 > [/usr/lib64/libaspell.so.16]  : /usr/lib64/libaspell.so.16: cannot open 
 > shared object file: No such file or directory

Hi,

This will not be fixed in recoll 1.17 (too old), and it is already fixed in
recoll 1.21, which is currently in sid.

For now:

 - To fix the .so load issue (message above), on a Wheezy or Jessie system,
   upgrade to recoll 1.21 through the recoll repository, see instructions
   on the page which follows, look for the packages section:
 
 http://www.lesbonscomptes.com/recoll/download.html


 - You may hit another dictionary creation issue, which is described near
   the top of the following page (search for aspell), along with a simple
   workaround.

   http://www.lesbonscomptes.com/recoll/BUGS.html
   
Cheers,

jf

Bug#798584: jessie-pu: package chrony/1.30-2+deb8u1

[Vincent Blut]

On Wed, Jan 13, 2016 at 07:13:42PM +, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Wed, 2016-01-13 at 17:35 +0100, Vincent Blut wrote:

AFAIR, new uploads will stop being processed on Sunday;


This weekend, yes.


Ok, thanks for confirming!


consequently,
can I request some of your time to tell me if the above change is
acceptable for 8.3?


Please go ahead; apologies for not getting back to you sooner.


Great. Hopefully my sponsor will be able to upload before the 8.3 window 
closes. Paul, let me know if you want me to upload the stuff to 
mentors.d.n; otherwise you can checkout the *jessie* branch from the git 
repo.


Cheers,
Vincent


Regards,

Adam



signature.asc
Description: PGP signature

Bug#803815: fuse-emulator-utils: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 13.01.2016 01:02, Alberto Garcia wrote:
> On Tue, Jan 12, 2016 at 11:48:28PM +0100, Andreas Cadhalpun wrote:
> 
>>> The patch to build against the new FFmpeg is waiting in my repository,
>>> when as the new packages are out I can upload fuse-utils immediately.
>>
>> Unless you think the new upstream version is going to be released
>> this month, you could just upload as well now...
> 
> Oh, somehow I got the idea that the patched fuse would only build with
> the new FFmpeg and not with the old one!

It still works with FFmpeg 2.8 (and it should also work with any other
version from the past two years).

> I guess I can just upload fuse now, then.

Yes, thanks. :)

Best regards,
Andreas

Bug#810935: ding is using an old out-of-date copy of the TU Chemnitz dictionary

[Tim Edwards]

Package: ding
Version: 1.8-3
Severity: normal

Dear Maintainer,

ding currently uses a quite old version of the TU Chemnitz Dictionary Project's 
dictionary. The latest dictionary file can be found at 
ftp://ftp.tu-chemnitz.de/pub/Local/urz/ding/de-en-devel/

I've also been in contact with Frank Richter, who runs the project at TU 
Chemnitz, and he's updated the dictionary file at the above link to have the 
latest from the project (as of 11 Jan 2016). I'll also try submitting an 
updated package to resolve this bug.

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

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

Versions of packages ding depends on:
ii  tk  8.6.0+6ubuntu3

Versions of packages ding recommends:
ii  trans-de-en [translation-dictionary]  1.8-1

Versions of packages ding suggests:
pn  agrep 
ii  dict  1.12.1+dfsg-3
pn  ibritish  
pn  ingerman  
pn  ispell

-- no debconf information

Bug#810934: Please hide initramfs eth card from NetworkManager more robustly

[Martin Pitt]

Package: ltsp
Version: 5.5.5-1

Hello,

ifupdown recently went through some changes (details in
I https://bugs.debian.org/809166, to a lesser degree in
https://bugs.debian.org/809169) which currently "ifconfig IFACE down"
an interface which is "manual".

LTSP currently creates such a "manual" interface stanza in
https://sources.debian.net/src/ltsp/5.5.5-1/client/share/ltsp/init-ltsp.d/50-interfaces/:

  auto $DEVICE
  iface $DEVICE inet ${NET_DEVICE_METHOD:-"manual"}

whose purpose is to hide the devide from NetworkManager. This
will now break with ifupdown 0.8 as (1) "manual" interfaces are now
downed with "ifdown", and (2) networking.service lost the
check_network_file_systems() safety check from /etc/init.d/networking
which prevented calling ifdown during shutdown if the root fs is
remote.

It's still being discussed whether ifupdown should go back to the old
behaviour (in https://bugs.debian.org/809166), but there are good
reasons for the current one as this makes use cases with e. g. bond
interfaces easier.

To avoid relying on the fine semantics of this, it would be great if
ltsp could more directly express what it really wants to do by
creating a /etc/NetworkManager/conf.d/ltsp.conf snippet instead with

  [keyfile]
  unmanaged-devices=interface-name=$DEVICE

This should be a straightforward change in init-ltsp.d/50-interfaces.

Thanks for considering,

Martin

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

Bug#810933: Please support connecting to SMTP via a SOCKS proxy

[Josh Triplett]

Package: reportbug
Version: 6.6.6
Severity: wishlist

reportbug supports an HTTP proxy if set in the environment; however,
when it subsequently tries to submit the report, it tries to connect
directly to the specified SMTP server, and does not seem to support
using a proxy for that connection.

Please consider adding support for using a SOCKS proxy to connect to
reportbug.debian.org, and obtaining that proxy from the environment (via
the all_proxy environment variable, and respecting no_proxy).

-- Package-specific info:
** Environment settings:
EDITOR="/home/josh/.local/bin/vim-wrapper"
DEBEMAIL="j...@joshtriplett.org"
EMAIL="j...@joshtriplett.org"
DEBFULLNAME="Josh Triplett"
NAME="Josh Triplett"
INTERFACE="text"

** /home/josh/.reportbugrc:
reportbug_version "3.21.2"
mode expert
ui text
no-cc
header "X-Debbugs-CC: j...@joshtriplett.org"
smtphost reportbug.debian.org:587
header "X-Debbugs-No-Ack: ack!"

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

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

Versions of packages reportbug depends on:
ii  apt   1.1.10
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
ii  debsums 2.1.2
pn  dlocate 
ii  emacs24-bin-common  24.5+1-5+b1
ii  file1:5.25-2
ii  gnupg   1.4.20-1
pn  postfix | exim4 | mail-transport-agent  
ii  python-gtk2 2.24.0-4
pn  python-gtkspellcheck
pn  python-urwid
pn  python-vte  
ii  xdg-utils   1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.1.10
ii  file  1:5.25-2
ii  python-debian 0.1.27
ii  python-debianbts  2.6.0
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#692075: closed by Martín Ferrari (Already fixed in upstream)

[Martín Ferrari]

Thanks Olly for following-up!

I have applied your patch and I can confirm that it fixes the issue.
This is the diff between the two versions:

$ diff -u 1.csv 2.csv
--- 1.csv   2016-01-13 19:05:07.497126268 -0300
+++ 2.csv   2016-01-13 19:06:01.069125169 -0300
@@ -3,20 +3,20 @@
 ,,,
 ,,,
 ,"Dates 1","Integer Formatting","Float Formatting","Percent
Formatting","Currency Formatting","Mixed Formatting",
-,"39479","19","11136","0.51305175781","15.1136","0.13076293945",
+,"39479","19","11136","0.51","15.1136","0.13",
 ,"39814","19","11992.1062271062","0.0023","15.6330005770485","12150",
 ,"40360","20","12150.666","0.00033","15.7355479452055","12150",
 ,"40634","20","-12092","0.0042","15.7297479452055","12150",
-,"40909","20","11540","0.12076293945","15.6745479452055","341.5603125",
-,"41275","20","10741.9178082192","0.88610351563","15.5947397260274","150",
+,"40909","20","11540","0.12","15.6745479452055","341.56",
+,"41275","20","10741.9178082192","0.88","15.5947397260274","150",
 ,,,
 ,"CASE 2",,"Hyperlink 1",,"HORIZONTALLY MERGED CELLS",
 ,,
 ,"Dates 2","Background Patterns 1","Background Patterns 2","Borders
1","Borders 2","Borders 3"
-,"39479","23.20001953125","7.5","13125","19","15480"
+,"39479","23.2","7.5","13125","19","15480"
 ,"39814","24.6575342465753","7.5","13125","19","15480"
 ,"40360","24.6575342465753","7.5","5062.5","18.3324350238071","15480"
-,"40634","24.6575342465753","12","5062.5","15.450009765625","11610"
+,"40634","24.6575342465753","12","5062.5","15.45","11610"
 ,"40909","24.6575342465753","12","5062.5","14.070609303653","11610"
 ,"41275","24.6575342465753","12.5","5062.5","14.0241509703196","11610"
 ,,,


On 04/01/16 20:56, Olly Betts wrote:
> Control: reopen -1
> Control: found -1 1:0.94.3~git20151007.fd634c2+dfsg-3
> 
> On Wed, Dec 23, 2015 at 11:15:04PM +, Debian Bug Tracking System wrote:
>> It seems that this fix was already added upstream at some point before
>> the migration to git (so I can't verify when did it happen).
>>
>> Since I have just discarded the Debian fork of catdoc, this issue should
>> be fixed now, please verify.
> 
> I can reproduce this, but my patch is actually reversed (which is why it
> looks like it was applied upstream) - sorry about that, and the resulting
> confusion.
> 
>> I could not duplicate your bug anyway, maybe it was specific to Debian's
>> 0.94.3, and that's not available in the archive any more.
> 
> It seems the XL format has multiple ways to represent floating point
> numbers, so just creating a document with the value 12.34 with
> libreoffice isn't enough to make a reproducer.
> 
> I've attached an existing file which shows the problem.  It's a sample
> from wxPython, so should be under a DFSG licence.
> 
> For example, E8 should be 0.51, but xls2csv gives 0.51305175781; E12
> should be 0.12, but xls2csv gives 0.12076293945.  With my patch
> reverse-applied, I get the expected values.
> 
> Cheers,
> Olly
> 


-- 
Martín Ferrari (Tincho)

Bug#802910: Bug#806219: Build mupen64plus-ui-console everywhere

[Sérgio Benjamim]

Hi,

Sorry for the absence. I have no time to maintain the ARMhf packages.

It would be nice if someone appears and maintain it for this architecture.


Sergio Benjamim

Bug#687019: Any response from upstream?

[Steve McIntyre]

Hi Pantelis,

Did you get any response to your submission please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#810878: creepy: Section should not be "python"

[Petter Reinholdtsen]

[Ben Finney]
> By the section descriptions, this package belongs in a section like
> the "net" or perhaps "misc" section.

I suspect "misc" is the most fitting section.

I had a look at the package history, to try to figure out why the python
section was used, and this section has been with us from the start in 2011.

I'll commit a change to 'misc'.

-- 
Happy hacking
Petter Reinholdtsen

Bug#810932: EFI boot entry non-functional on NVMe system

[Josh Triplett]

Package: grub-efi-amd64
Version: 2.02~beta2-33
Severity: important

[Reporting as "important" because it breaks booting on this system
without manual configuration, but not RC because it may not apply to all
EFI systems, or even all EFI systems with NVMe.]

On a laptop with an NVMe disk (accessible as /dev/nvme0n1), GRUB
installs a non-functional boot entry into the EFI firmware.  GRUB
installs the following entry (read via "efibootmgr -v"):

Boot0001* debian 
HD(1,0,,0x0,0x0)/File(\EFI\debian\grubx64.efi)

By contrast, if I use the firmware's option to browse for an EFI binary
to boot, and select \EFI\debian\grubx64.efi, that successfully boots;
after booting, the boot entries contain the following:

Boot0005* \EFI\debian\grubx64.efi 
PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,37ea4958-49da-48da-bc44-39d3f5ea6b7d,0x800,0x10)/File(\EFI\debian\grubx64.efi)

This differs both in providing a specific NVMe device, and in using
"GPT" and a UUID for the HD rather than all zeroes.

Also, any subsequent run of "update-grub" will *remove* that entry,
making the system unbootable without again manually selecting the
bootloader by path.

- Josh Triplett

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p2 / ext4 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-d3294916-5507-427d-bdcc-38f7f0cf8794' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
d3294916-5507-427d-bdcc-38f7f0cf8794
else
  search --no-floppy --fs-uuid --set=root 
d3294916-5507-427d-bdcc-38f7f0cf8794
fi
echo'Loading Linux 4.4.0-rc8+ ...'
linux   /boot/vmlinuz-4.4.0-rc8+ 
root=UUID=d3294916-5507-427d-bdcc-38f7f0cf8794 ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-4.4.0-rc8+
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-d3294916-5507-427d-bdcc-38f7f0cf8794' {
menuentry 'Debian GNU/Linux, with Linux 4.4.0-rc8+' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.4.0-rc8+-advanced-d3294916-5507-427d-bdcc-38f7f0cf8794' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
d3294916-5507-427d-bdcc-38f7f0cf8794
else
  search --no-floppy --fs-uuid --set=root 
d3294916-5507-427d-bdcc-38f7f0cf8794
fi
echo'Loading Linux

Bug#810931: icedove: Adding custom header breaks the other headers (sender, subject, date become blank)

[Laura Arjona Reina]

Package: icedove
Version: 38.5.0-1~deb8u1
Severity: normal

Dear Maintainer,
Thanks for working in Icedove.

   * What led up to the situation?

I try to send mail with a custom header, and the mail gets sent, but the
headers in that mail get broken (blank sender, blank subject, blank date).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
1.- Edit > Preferences > Advanced > Config editor
2.- Write mail.compose.other header to find the setting and double click
3.- Add a custom header, for example, "Review" (without quotes)
4.- Accept everything.
5.- Write a mail, recipient can be any mail address, even yours. Drop down
"To:" again, to select the custom header (should appear as "Review:") and write
an email there, for example em...@example.com. Fill in subject and body, and
send the email.

   * What was the outcome of this action?

What is received (and appears in the Sender's "Sent" folder) is a mail with
blank date and sender and subject, and no custom header, or the message "BAD
HEADERS" when all the headers are examined. The body of the email is OK.

   * What outcome did you expect instead?

The recipient should get an email with proper date, sender, subject, and if all
the headers examined, the header "Review: em...@example.com.

I've tested this in two Debian stable box, and could reproduce the problem.
I've asked some friends to reproduce the problem with these results:

* Ubuntu + Thunderbird 31.3.0 -> could not reproduce
* Windows 7 + Thunderbird 38.5.1 -> could not reproduce
* Debian sid + Icedove 38.5.0-1+b1 -> could reproduce the problem
* Debian sid + Icedove from experimental 42.0~b2-1 -> could reproduce the
problem

I hope it's something easy to fix!

Best regards



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

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u1
ii  libcairo2 1.14.0-2.1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u4
ii  libglib2.0-0  2.42.1-1
ii  libgtk2.0-0   2.24.25-3
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  38.5.0-1~deb8u1
ii  myspell-es [myspell-dictionary]   1.11-9

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u1

-- no debconf information

Bug#772171: Shouldn't this have a higher severity?

[John Eikenberry]

Doesn't this bug make it impossible to index any new data? Shouldn't it have a
higher severity than normal? It completely breaks recoll for my use, so I'd
give it grave unless there are other use cases where it still works.

Error output I get when I run 'recollindex'...

:2:../index/indexer.cpp:298:ConfIndexer::createAspellDict: aspell init failed: 
Could not open shared library [/usr/lib/libaspell.so] 
[/usr/lib/libaspell.so.15] [/usr/lib/libaspell.so.16] [/usr/lib64/libaspell.so] 
[/usr/lib64/libaspell.so.15] [/usr/lib64/libaspell.so.16]  : 
/usr/lib64/libaspell.so.16: cannot open shared object file: No such file or 
directory


-- 

John Eikenberry
[ j...@zhar.net - http://zhar.net ]
[ PGP public key @ http://zhar.net/jae_at_zhar_net.gpg ]

"Perfection is attained, not when no more can be added, but when no more
 can be removed." -- Antoine de Saint-Exupery


signature.asc
Description: Digital signature

Bug#810930: sshuttle: Crashes if using the --seed-hosts option

[Shai Ayal]

Package: sshuttle
Version: 0.75-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

When using the --seed-hosts command line option, sshuttle crashes on
connect. This is due to difference in handling of bytes in between python 2 & 3.
I submitted pull request #63 to upstream.

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

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

Versions of packages sshuttle depends on:
ii  iptables 1.4.21-2+b1
ii  openssh-client [ssh-client]  1:7.1p1-6
ii  python3-pkg-resources18.8-1
pn  python3:any  

Versions of packages sshuttle recommends:
ii  sudo  1.8.15-1.1

Versions of packages sshuttle suggests:
pn  autossh  

-- no debconf information

Bug#810929: Renders Vim unusable

[martin f krafft]

Package: vim-ultisnips
Version: 3.1-2
Severity: grave

Following my install of vim-ultisnips, I cannot use Vim anymore.
I did not even use vim-addons to enable the addon.

For any document I open, once I enter insert mode and type as much
as a single character, I get a traceback from Ultisnips (see below).

Installing vim-snippets seems to prevent this from happening, so
either vim-ultisnips needs a dependency on vim-snippets, or
(better) a better default handling.

Here is the traceback:

An error occured. This is either a bug in UltiSnips or a bug in a
snippet definition. If you think this is a bug, please report it to
https://github.com/SirVer/ultisnips/issues/new.

Following is the full stack trace:
Traceback (most recent call last):
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet_manager.py", line 61, in 
wrapper
return func(self, *args, **kwds)
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet_manager.py", line 810, in 
_track_change
self._try_expand(autotrigger_only=True)
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet_manager.py", line 709, in 
_try_expand
snippets = self._snips(before, False, autotrigger_only)
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet_manager.py", line 584, in 
_snips
source.ensure(filetypes, cached=autotrigger_only)
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet/source/file/_base.py", 
line 47, in ensure
self._load_snippets_for(ft)
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet/source/file/_base.py", 
line 80, in _load_snippets_for
self._parse_snippets(ft, fn)
  File "/var/lib/vim/addons/pythonx/UltiSnips/snippet/source/file/_base.py", 
line 93, in _parse_snippets
file_data = compatibility.open_ascii_file(filename, 'r').read()
  File "/var/lib/vim/addons/pythonx/UltiSnips/compatibility.py", line 76, in 
open_ascii_file
return open(filename, mode)
IOError: [Errno 2] No such file or directory: 
u'/home/madduck/.vim/snippets/_.snippets'

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

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

Versions of packages vim-ultisnips depends on:
ii  python2.7.11-1
ii  vim-addon-manager 0.5.4
ii  vim-nox [vim-python]  2:7.4.963-1+b1

Versions of packages vim-ultisnips recommends:
pn  vim-snippets  

vim-ultisnips suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#761965: viking: Starter lands in "misc" not "science" in the xfce application menu

[Guilhem Bonnefille]

Hi,

I'm a bit surprised as the viking package strictly follows the
recommandations:
https://www.debian.org/doc/packaging-manuals/menu-policy/ch2.html#s2.1

Is it still open?
Is it a bug related to XFCE?

-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

Bug#810642: Segmentation fault

[Zlatan Todoric]

On 01/13/2016 10:11 PM, Markus Koschany wrote:
>> Hi Markus,
>>
>> and now I again get the same thing.
>>
>> I attached strace log for the entire command.
>>
>> Hope it helps!
>>
>> Cheers,
>>
>> zlatan
> 
> Hi,
> 
> unfortunately, not really. I don't know how to interpret the output before
> 
> -- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
> 
> If it is a renpy error, I need to know in which line of code the game
> crashes. It could also be a bug in pygame or it is a driver issue, which
> might explain why you are affected and I can't reproduce it. There are
> lines like
> 
> DRM_IOCTL_I915
> 
> so it could also be related to your Intel video card driver. Sorry but I
> don't know what to make of this. Perhaps someone else can.
> 

Ah, could be. This is an old macbook with those old intel cards (glxinfo
says it support OpenGL 2.1 but even games who say they can run on 2.1
crash or don't even start). So yes, it does make sense (but what
confuses me why it did start once today :-/ - I think that was before
latest pygame upgrade I made so maybe I could try later downgrading to
previous version of it).

> Regards,
> 
> Markus
> 
> 
> 

Cheers,

zlatan

Bug#809203: linux-image-586 4.3+70 installs a 4.3.3 kernel for 686 only, which doesn't boot on 586

[Ben Hutchings]

On Wed, 2016-01-13 at 21:43 +0100, hikaru.deb...@web.de wrote:
> Dear Ben,
> 
> > You'll need to stick with jessie as it is not planned to support such
> > old processors in stretch.
> 
> Could you elaborate on that please?
> I found the anouncement for the Stretch Alpha 5 Installer [1], but apart from
> that there seems to be no (semi)official statement addressing the drop of i586
> support for Stretch (yet).
<
> Being the author of #783082 and #783293 I fully understand why Debian would
> want to get rid of i586, but some more detailed reference, that shows how this
> decision was made, would be nice.
> Is there a discussion on a Debian mailing list you could link to or something 
> similar?

It is linked from the announcement.

Ben.

> Thanks in advance!
> 
> 
> fyi: Due to your quote above I opened a thread in the unofficial German
> Debianforum at [2].
> 
> 
> [1] https://lists.debian.org/debian-devel-announce/2016/01/msg1.html
> [2] https://debianforum.de/forum/viewtopic.php?f=33&t=159100
-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

Bug#810928: muttprint: Wide character in print at /usr/bin/muttprint line 1931

[Rosario Maddox]

Package: muttprint
Version: 0.73-5.1
Severity: important

Dear Maintainer,

When printing UTF-8 message, with chars as ž I get this error:
Wide character in print at /usr/bin/muttprint line 1931,  line
150.

however, the print looks fine.


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

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

Versions of packages muttprint depends on:
ii  libtext-iconv-perl 1.7-5+b2
ii  perl   5.20.2-3+deb8u1
ii  texlive-fonts-recommended  2014.20141024-2
ii  texlive-latex-extra2014.20141024-1
ii  texlive-latex-recommended  2014.20141024-2

Versions of packages muttprint recommends:
ii  bsd-mailx [mail-reader]  8.1.2-0.20141216cvs-2
ii  emacs24-lucid [mail-reader]  24.4+1-5
ii  icedove [mail-reader]38.4.0-1~deb8u1
ii  kmail [mail-reader]  4:4.14.1-1
ii  libtimedate-perl 2.3000-2
ii  mutt [mail-reader]   1.5.23-3

Versions of packages muttprint suggests:
pn  compface 
pn  dialog   
ii  emacs24-lucid [news-reader]  24.4+1-5
ii  imagemagick  8:6.8.9.9-5
ii  lynx-cur [news-reader]   2.8.9dev1-2+deb8u1
pn  muttprint-manual 
pn  ospics   
ii  psutils  1.17.dfsg-2
pn  texlive-fonts-extra  

-- no debconf information

Bug#801441: jessie-pu: package bcfg2/1.3.5-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2015-10-31 at 14:47 +0200, Arto Jantunen wrote:
> A new debdiff (with the migrations installed, and a proper changelog
> generated) is attached.

After a fair amount of patch wrangling (and some wondering why it took
until a few months after the Jessie release for this to get raised), I
think this looks reasonable enough. Please go ahead; apologies for the
delays.

Regards,

Adam

Bug#810642: Segmentation fault

[Markus Koschany]

> Hi Markus,
> 
> and now I again get the same thing.
> 
> I attached strace log for the entire command.
> 
> Hope it helps!
> 
> Cheers,
> 
> zlatan

Hi,

unfortunately, not really. I don't know how to interpret the output before

-- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---

If it is a renpy error, I need to know in which line of code the game
crashes. It could also be a bug in pygame or it is a driver issue, which
might explain why you are affected and I can't reproduce it. There are
lines like

DRM_IOCTL_I915

so it could also be related to your Intel video card driver. Sorry but I
don't know what to make of this. Perhaps someone else can.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature