Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)

[Cyril Brulebois]

Hideki Yamane  (2018-03-21):
> Package: debootstrap-udeb
> Severity: minor
> 
> Hi,
> 
>  It contains meaningless scripts as below.
> 
> 
> drwxr-xr-x root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/
> -rw-r--r-- root/root  6016 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/aequorea
> -rw-r--r-- root/root  6296 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/etch
> -rw-r--r-- root/root  7461 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/gutsy
> -rw-r--r-- root/root  6233 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/artful -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/bartholomea -> aequorea
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/bionic -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/bullseye -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/buster -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/chromodoris -> aequorea
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/dasyatis -> aequorea
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/etch-m68k -> etch
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/hardy -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/intrepid -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/jaunty -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/jessie -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/jessie-kfreebsd -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/karmic -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/lenny -> etch
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/lucid -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/maverick -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/natty -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/oldoldstable -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/oldstable -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/oneiric -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/precise -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/quantal -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/raring -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/saucy -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/squeeze -> etch
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/stretch -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/trusty -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/utopic -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/vivid -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/wheezy -> sid
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/wily -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/xenial -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/yakkety -> gutsy
> lrwxrwxrwx root/root 0 2018-03-17 23:46 
> ./usr/share/debootstrap/scripts/zesty -> gutsy
> 
>  Not harm but messy.

What's the problem here?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#893771: djview: Clearing highlights no longer works

[Janusz S. Bień]

Package: djview
Version: 3.5.27.1-7
Severity: normal

Dear Maintainer,

The feature added some time ago on my request

--8<---cut here---start->8---

commit c2036490129cd8481bc5527301572a90b26c79b6
Author: Leon Bottou 
Date:   Sat Mar 30 11:32:59 2013 -0400

added key H to clear highlights

--8<---cut here---end--->8---

no longer works.

I tried to use (for the first time in my life) git bisec on
https://github.com/barak/djview4.git to locate the responsible
commit. I've checked that the bug occurs already after the commit
b87081f0199e61b06b3d86dfc93eef3d28a63a8c (Sun Feb 1 13:07:26 2015
-0500). Unfortunately I was unable to compile the next commit selected
by bisec, and because of my only rudimentary knowledge of git I was
unable to proceed with the search of the commit to blame. I can continue
the search if you explain to me how to do it.

Best regards

Janusz

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

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

Versions of packages djview depends on:
ii  djview4  4.10.6-1

djview recommends no packages.

djview suggests no packages.

-- no debconf information

-- 
   ,   
Prof. dr hab. Janusz S. Bien -  Uniwersytet Warszawski (Katedra Lingwistyki 
Formalnej)
Prof. Janusz S. Bien - University of Warsaw (Formal Linguistics Department)
jsb...@uw.edu.pl, jsb...@mimuw.edu.pl, http://fleksem.klf.uw.edu.pl/~jsbien/

Bug#893770: amide: Don't depend on libgnomecanvas

[Jeremy Bicha]

Source: amide
Version: 1.0.5-10
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: libgnomecanvas oldlibs

As announced [1], we do not intend to release Debian 10 "Buster" with
libgnomecanvas, one of
the old unmaintained libgnome libraries. Your package Build-Depends
and Depends on this library.

I apologize for not filing this bug earlier, alongside
https://bugs.debian.org/868383

amide has one more old dependency: scrollkeeper. I can submit a patch
for this later if you like.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#874664: Update ledgersmb package to 1.5.x series

[Robert J. Clay]

Robert J. Clay wrote on 17 Nov 2017:
> And the most recent version of the 1.5.x series  is currently version
> 1.5.13, which is what is currently being used as the basis for
> updating the package.

   The most recent version of the 1.5.x series is now 1.5.18 and I
have been using that as the basis for updating the package.   I have
also found a way to resolve all of the remaining Lintian Errors and
Warnings, and so plan to next work on finishing the update of the
package in preparation for an upload of the new version..




-- 
Robert J. Clay
rjc...@gmail.com
j...@rocasa.us

Bug#885782: monotone-viz: Raising severity of libgnomecanvas dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885778: swami: Raising severity of libgnomecanvas dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885781: petri-foo: Raising severity of libgnomecanvas dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885796: etherape: Raising severity of libgnomecanvas dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885677: liblablgtksourceview2-ocaml: Raising severity of libgnome related dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

liblablgtksourceview2-ocaml is one of the last packages preventing us
from removing libgnomecanvas from Debian (and gtksourceview2).

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#893769: RM: cairo-clock -- RoQA; unmaintained for years

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: cairo-cl...@packages.debian.org

Please remove cairo-clock from Debian.

It was orphaned 4 years ago [1]. Its last upstream release was about a
decade ago.

My interest in this package is that the Debian GNOME team would
eventually like to remove libglade2 from Debian.

[1] https://bugs.debian.org/702599

Thanks,
Jeremy Bicha

Bug#893768: eclipse-rcp: Please don't depend on libswt-webkit-gtk-3-jni

[Jeremy Bicha]

Package: eclipse-rcp
Version: 3.8.1-11
Severity: serious
Tags: buster sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: oldlibs libwebkitgtk-1.0-0 webkit1


eclipse-rcp depends on libswt-webkit-gtk-3-jni which is the last
package keeping the unmaintained webkitgtk in Debian Testing. Please
investigate whether it's possible to drop this dependency.

I'm guessing it's still possible for apps to use the Eclipse platform
without that library: it's just that web browser powered widgets won't
work?

On behalf of the Debian Webkit Maintainers,
Jeremy Bicha

Bug#893767: qemu: Enable support for riscv64 targets

[Vagrant Cascadian]

Source: qemu
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

Version 2.12.0-rc0 has support for the riscv64 target, and enabling it
would help improve the progress of the riscv64 port for Debian!  Even
just having this in experimental would be a great help.

Attached is a patch that enables the riscv64 targets for
qemu-system-misc and qemu-user-static/qemu-user/qemu-binfmt.

There are also currently two additional patches not present in
2.12.0-rc0 to fix significant bugs, which I've also included. It would
be great if you would consider applying those too.

Thanks for considering it!


live well,
  vagrant

diff --git a/debian/binfmt-update-in b/debian/binfmt-update-in
index 4bd4cc1643..09810d76a6 100644
--- a/debian/binfmt-update-in
+++ b/debian/binfmt-update-in
@@ -5,7 +5,7 @@ grep -zqs ^container= /proc/1/environ && exit 0
 # == binfmt registration/deregistration ==
 if command -v update-binfmts > /dev/null ; then
 
-fmts="aarch64 alpha arm armeb cris i386 m68k microblaze mips mipsel mipsn32 
mipsn32el mips64 mips64el ppc ppc64 ppc64abi32 ppc64le s390x sh4 sh4eb sparc 
sparc32plus sparc64 x86_64"
+fmts="aarch64 alpha arm armeb cris i386 m68k microblaze mips mipsel mipsn32 
mipsn32el mips64 mips64el ppc ppc64 ppc64abi32 ppc64le s390x sh4 sh4eb sparc 
sparc32plus sparc64 x86_64 riscv64"
 
 # linux ELF_OSABI(byte7) can be 0 (traditional,SYSV) or 3 (GNU/LINUX 
extensions)
 # binfmt registration does not allow a enum, only value  So we use 
broader mask
@@ -60,6 +60,8 @@ 
sparc32plus_magic='\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\
   
x86_64_mask='\xff\xff\xff\xff\xff\xfe\xfe\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
 
ppc64le_magic='\x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00'
  
ppc64le_mask='\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00'
+ 
riscv64_magic='\x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xf3\x00'
+ 
riscv64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
 
 # find which fmts needs to be filtered out, which is arch-dependent.
 # Drop support for emulating amd64 on i386, http://bugs.debian.org/604712
diff --git a/debian/rules b/debian/rules
index 8a5d8e158a..d6f5bac278 100755
--- a/debian/rules
+++ b/debian/rules
@@ -57,7 +57,7 @@ ifeq (${enable_system},enable)
 system_targets = \
  i386 x86_64 alpha aarch64 arm cris lm32 m68k microblaze microblazeel \
  mips mipsel mips64 mips64el moxie nios2 or1k ppc ppcemb ppc64 sh4 sh4eb \
- sparc sparc64 s390x tricore xtensa xtensaeb unicore32
+ sparc sparc64 s390x tricore xtensa xtensaeb unicore32 riscv64
 
 # qemu-system subpackages, from d/control
 sys_systems = arm mips ppc sparc x86
@@ -82,7 +82,7 @@ user_targets = \
  i386 x86_64 alpha aarch64 arm armeb cris hppa m68k microblaze microblazeel \
  mips mipsel mips64 mips64el mipsn32 mipsn32el nios2 or1k \
  ppc ppc64 ppc64abi32 ppc64le sh4 sh4eb sparc sparc64 sparc32plus \
- s390x tilegx
+ s390x tilegx riscv64
 
 endif  # enable_linux_user


This one is a speed improvement for system mode:
https://temp.aurel32.net/riscv64/0001-RISC-V-Add-support-for-per-page-TLB-flush.patch

From 9f959967beeac09f45662fd2a303142365f278ec Mon Sep 17 00:00:00 2001
From: Aurelien Jarno 
Date: Thu, 8 Mar 2018 22:19:04 +0100
Subject: [PATCH] RISC-V: Add support for per page TLB flush

When rs1 != 0, the content of this register contains the address of the
page to be flushed. It is faster than flushing the whole TLB. We still
ignore the ASID.

Note: it might be wrong if superpages are in used.

Signed-off-by: Aurelien Jarno 
---
 target/riscv/helper.h| 1 +
 target/riscv/op_helper.c | 7 +++
 target/riscv/translate.c | 6 +-
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index debb22a480..3997ed1900 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -75,4 +75,5 @@ DEF_HELPER_2(sret, tl, env, tl)
 DEF_HELPER_2(mret, tl, env, tl)
 DEF_HELPER_1(wfi, void, env)
 DEF_HELPER_1(tlb_flush, void, env)
+DEF_HELPER_2(tlb_flush_page, void, env, tl)
 #endif
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index e34715df4e..11d3c70b43 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -666,4 +666,11 @@ void helper_tlb_flush(CPURISCVState *env)
 tlb_flush(cs);
 }
 
+void helper_tlb_flush_page(CPURISCVState *env, target_ulong vaddr)
+{
+RISCVCPU *cpu = riscv_env_get_cpu(env);
+CPUState *cs = CPU(cpu);
+tlb_flush_page(cs, vaddr);
+}
+
 #endif /* !CONFIG_USER_ONLY */
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 808eab7f50..2967d80b4b 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -1333,7 +1333,11 @@ static void gen_system(CPURISCVState *env, 

Bug#889176: bc: Exhausts process table during build

[Steve Langasek]

Control: severity -1 serious
Control: tags -1 + patch

This bug is constistently reproducible.  I'm not sure what has changed
between the time bc successfully built, and now, to regress the behavior
(there have been no changes to the make-dfsg package in this timeframe);
however, I also can't see how the existing package was ever expected to
build, when this definitely looks like a circular dependency that's being
hidden from make.  

The attached patch fixes the issue and I have uploaded it to Ubuntu to fix
the build failure there.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru bc-1.07.1/debian/patches/no-make-circular-dependencies.patch bc-1.07.1/debian/patches/no-make-circular-dependencies.patch
--- bc-1.07.1/debian/patches/no-make-circular-dependencies.patch	1969-12-31 16:00:00.0 -0800
+++ bc-1.07.1/debian/patches/no-make-circular-dependencies.patch	2018-03-21 19:47:50.0 -0700
@@ -0,0 +1,43 @@
+Description: fix circular dependency in makefile
+ The upstream makefile is unhelpfully relying on make to allow it to break
+ target dependency loops in a particular manner.  Instead, be explicit about
+ the relationship between the targets.
+Author: Steve Langasek 
+Last-Modified: 2018-03-21
+Bug-Debian: https://bugs.debian.org/889176
+
+Index: bc-1.07.1/bc/Makefile.am
+===
+--- bc-1.07.1.orig/bc/Makefile.am
 bc-1.07.1/bc/Makefile.am
+@@ -8,7 +8,7 @@
+  sbc.y
+ noinst_HEADERS = libmath.h
+ 
+-DISTCLEANFILES = sbc sbc.c sbc.h libmath.h
++DISTCLEANFILES = sbc sbc.c sbc.h libmath.h global_foo.c
+ 
+ MAINTAINERCLEANFILES = Makefile.in bc.c bc.h scan.c \
+ 	bc.y bcdefs.h const.h execute.c fix-libmath_h \
+@@ -28,16 +28,18 @@
+ 
+ scan.o: bc.h
+ global.o: libmath.h
++global_foo.c: global.c
++	cp -a global.c global_foo.c
+ 
+ fbcOBJ = main.o bc.o scan.o execute.o load.o storage.o util.o warranty.o
+ 
+ libmath.h: libmath.b $(fbcOBJ) $(LIBBC)
+ 	echo '{0}' > libmath.h
+-	$(MAKE) global.o
+-	$(LINK) -o fbc $(fbcOBJ) global.o $(LIBBC) $(LIBL) $(READLINELIB) $(LIBS)
++	$(MAKE) global_foo.o
++	$(LINK) -o fbc $(fbcOBJ) global_foo.o $(LIBBC) $(LIBL) $(READLINELIB) $(LIBS)
+ 	./fbc -c $(srcdir)/libmath.b libmath.h
+ 	$(srcdir)/fix-libmath_h
+-	rm -f ./fbc ./global.o
++	rm -f ./fbc ./global_foo.o
+ 
+ sbcOBJ = main.o sbc.o scan.o execute.o global.o load.o storage.o util.o \
+  warranty.o
diff -Nru bc-1.07.1/debian/patches/series bc-1.07.1/debian/patches/series
--- bc-1.07.1/debian/patches/series	2017-07-24 12:05:43.0 -0700
+++ bc-1.07.1/debian/patches/series	2018-03-21 19:44:36.0 -0700
@@ -4,3 +4,4 @@
 05_notice_read_write_errors.diff
 06_read_dcrc.diff
 07_bc_man.diff
+no-make-circular-dependencies.patch


signature.asc
Description: PGP signature

Bug#893766: ITP wig -- WebApp Information Gatherer

[Samuel Henrique]

Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist

​* Package name: prochunter
  Upstream Author : Jesper Kückelhahn
* URL : https://github.com/jekyc/wig

* License : BSD-2-clause
  Programming Lang: Python 3
  Description : web application information gathering tool, which can
identify numerous Content Management Systems and other administrative
applications.

The application fingerprinting is based on checksums and string matching of
known files for different versions of CMSes. This results in a score being
calculated for each detected CMS and its versions. Each detected CMS is
displayed along with the most probable version(s) of it. The score
calculation is based on weights and the amount of "hits" for a given
checksum.

wig also tries to guess the operating system on the server based on the
'server' and 'x-powered-by' headers. A database containing known header
values for different operating systems is included in wig, which allows wig
to guess Microsoft Windows versions and Linux distribution and version.

​I intend to maintain this package under the pkg-security team.​

This package is also intended to be part of my application to this years
GSOC project
https://wiki.debian.org/SummerOfCode2018/Projects#SummerOfCode2018.2FProjects.2FPortKaliPackages.Port_Kali_Packages_to_Debian

-- 
Samuel Henrique 

Bug#884095: flag to force file types

[Chris Lamb]

Hi Hans!

> > Have we really exhausted the detection route for this? :)
>
> I think the detection route has been exhausted.  It seems that no one
> wants to do what it takes to reliably detect APKs. 

I'm sorry you think so and, with the greatest of respect, I'm not
sure this is entirely accurate... at least from my point of view.

Could you perhaps attach or otherwise link to some testcases where
diffoscope gets the detection wrong? It sounds like a fun challenge,
if nothing else..


Best wishes,

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

Bug#893765: transition: ruby2.3

[Antonio Terceiro]

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

ruby2.5 has been made the default and the ruby2.5 transition has been
finished succesfully. there is a pending issue with graphviz on armel,
but that is beyond what we can do ATM.

So I would like to remove ruby2.3 now.

Ben file:

title = "ruby2.3-rm";
is_affected = (.depends ~ /ruby2.3 | .depends ~ /ruby2.5/) & !.source ~ 
/^(ruby2.3|ruby2.5|ruby-defaults)$/)
is_good = ! .depends ~ /ruby2.3/
is_bad = .depends ~ /ruby2.3/

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: PGP signature

Bug#893764: eom gets out of memory while checking out an svg image

[shirish शिरीष]

Package: eom
Version: 1.20.0-1
Severity: normal

Dear Maintainer,

Got the following output while trying out eom against a svg image -

$ eom gldt_v16.12.svg

(eom:851): EOM-WARNING **: Error loading Peas typelib: Typelib file
for namespace 'Peas', version '1.0' not found


(eom:851): EOM-WARNING **: Error loading PeasGtk typelib: Typelib file
for namespace 'PeasGtk', version '1.0' not found


(eom:851): EOM-WARNING **: Error loading Eom typelib: Typelib file for
namespace 'Eom', version '1.0' not found


(eom:851): libpeas-WARNING **: Type not found in introspection:
'PeasActivatable'

(eom:851): libpeas-WARNING **: Method 'PeasActivatable.activate' was not found
^C
shirish@debian:~$ eom gldt_v16.12.svg

(eom:881): EOM-WARNING **: Error loading Peas typelib: Typelib file
for namespace 'Peas', version '1.0' not found


(eom:881): EOM-WARNING **: Error loading PeasGtk typelib: Typelib file
for namespace 'PeasGtk', version '1.0' not found


(eom:881): EOM-WARNING **: Error loading Eom typelib: Typelib file for
namespace 'Eom', version '1.0' not found


(eom:881): libpeas-WARNING **: Type not found in introspection:
'PeasActivatable'

(eom:881): libpeas-WARNING **: Method 'PeasActivatable.activate' was not found

(eom:881): Gtk-WARNING **: drawing failure for widget
'GtkDrawingArea': invalid value (typically too big) for the size of
the input (surface, pattern, etc.)

(eom:881): Gtk-WARNING **: drawing failure for widget 'EomScrollView':
invalid value (typically too big) for the size of the input (surface,
pattern, etc.)

(eom:881): Gtk-WARNING **: drawing failure for widget 'GtkPaned':
invalid value (typically too big) for the size of the input (surface,
pattern, etc.)

(eom:881): Gtk-WARNING **: drawing failure for widget 'GtkBox':
invalid value (typically too big) for the size of the input (surface,
pattern, etc.)

(eom:881): Gtk-WARNING **: drawing failure for widget 'GtkBox':
invalid value (typically too big) for the size of the input (surface,
pattern, etc.)

(eom:881): Gtk-WARNING **: drawing failure for widget 'GtkBox':
invalid value (typically too big) for the size of the input (surface,
pattern, etc.)

(eom:881): Gtk-WARNING **: drawing failure for widget 'EomWindow':
invalid value (typically too big) for the size of the input (surface,
pattern, etc.)

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

might be related to https://github.com/mate-desktop/eom/issues/153

The wide image at my end can be found at
https://github.com/FabioLolix/LinuxTimeline/releases/download/v16.12/gldt_v16.12.svg


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  eom-common   1.20.0-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo-gobject21.15.10-1
ii  libcairo21.15.10-1
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libexempi3   2.4.5-1
ii  libexif120.6.21-4
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libgirepository-1.0-11.54.1-4
ii  libgl1-mesa-glx  17.3.6-1
ii  libglib2.0-0 2.54.3-2
ii  libgtk-3-0   3.22.29-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  libmate-desktop-2-17 1.20.0-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpeas-1.0-01.22.0-2
ii  librsvg2-2   2.40.20-2
ii  librsvg2-common  

Bug#893763: ripe-atlas-sagan v1.1.11 supports an obsolete version of the RIPE ATLAS API

[Nicolas Braud-Santoni]

Source: ripe-atlas-sagan
Version: 1.1.11-1
Severity: important

Hi,

It seems that the currently-packaged version of ripe-atlas-sagan, from 2016,
only supports an obsolete version of the RIPE API and measurement format.

I will have a stab at packaging an up-to-date version and NMU that.


Best,

  nicoo


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#893731: [Piuparts-devel] Bug#893731: [piuparts] Please add docker support

[Holger Levsen]

Hi TiN,

On Wed, Mar 21, 2018 at 05:32:32PM -0300, Agustin Henze wrote:
> I have written a patch for adding docker support on piuparts. A new option is
> introduced `--docker-image` e.g.
> 
> $ piuparts --docker-image debian:unstable package.deb

cool!

> Honestly I didn't do too much testing on this, I just have tried using the new
> feature of course and I have tried using schroot to check it's not breaking
> something. I am willing to help you if you need/want to do extra testing on 
> this.

nice!

> The patch attached is made against origin/master.

cool cool. Just one thing before I'm willing to merge this: please also
patch piuparts.1.txt to explain this new option.

& thanks a lot for this nice addition to piuparts!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#893762: samba: installation fails when only loopback interface present.

[unman]

Source: samba
Version: 2.4.5.12+dfsg-2+deb9u2
Severity: normal

Dear Maintainer,

Installing Samba on stretch with only loopback interface present results
in configuration error post install.

Installation errors:
dpkg: error processing package samba (--configure)

nmbd.service times out with status:
"nmbd: No local IPv4  non-loopback interfaces available, waiting for
interfaces."


workaround is to create dummy interface and configuration then
completes.

Bug#893761: java-propose-classpath still depends on gcj-jdk

[Matthias Klose]

Package: java-propose-classpath
Version: 0.62
Severity: serious
Tags: sid buster

GCJ is now removed in unstable. Please stop depending on gcj-jdk, and consider
using default-jdk as a dependency.

Bug#893760: RM: zekr -- RoQA: depends on unmaintained webkitgtk & libgnomeui

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: z...@packages.debian.org, aelmahmo...@ubuntu.com

Please remove zekr from Debian. It is blocking the removal of
libgnomeui (via libswt-gnome-gtk-3-jni ). It was removed from testing
at the end of July 2017 because it
depends on the unmaintained  security-sensitive webkitgtk package.

I made multiple attempts [1] to contact أحمد المحمودي (Ahmed
El-Mahmoudy) to warn him about the urgent need to fix zekr or it would
be removed from Debian but I did not receive a reply.

[1] https://bugs.debian.org/892650

Thanks,
Jeremy Bicha

Bug#893759: variety: launching variety gives quite a few python 2.7 warnings

[shirish शिरीष]

Package: variety
Version: 0.6.6-2
Severity: normal

Dear Maintainer,

I am getting various tracebacks the moment I start to run variety -

$ variety
WARNING: 2018-03-22 06:32:21,890: load_history() 'Could not load
history file, continuing without it, no worries'
ERROR: 2018-03-22 06:32:22,469: check_and_update_metadata() 'Could not
read metadata for /usr/share/images/desktop-base/desktop-background'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/variety/Util.py", line 331,
in check_and_update_metadata
m = VarietyMetadata(filename)
  File "/usr/lib/python2.7/dist-packages/variety/Util.py", line 190, in __init__
super(VarietyMetadata, self).__init__(path=path)
  File "/usr/lib/python2.7/dist-packages/gi/overrides/GExiv2.py", line
41, in __init__
self.open_path(path)
  File "/usr/lib/python2.7/dist-packages/gi/overrides/GExiv2.py", line
45, in open_path
super(Metadata, self).open_path(path)
Error: GExiv2: unsupported format (501)

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/variety/VarietyWindow.py",
line 1527, in image_ok
i = PILImage.open(img)
  File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 2572, in open
% (filename if filename else fp))
IOError: cannot identify image file
u'/home/shirish/.config/variety/Downloaded/flickr_user_www_flickr_com_photos_peter_levi__user_id_93647178_N00_/7527884976_7d72041417_o.jpg'
/home/shirish/.config/variety/scripts/set_wallpaper: line 121: [: ==:
unary operator expected

It goes on and on, please fix this so we don't see so much noise,
although it works.



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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages variety depends on:
ii  gir1.2-gdkpixbuf-2.0 2.36.11-1
ii  gir1.2-gexiv2-0.10   0.10.8-1
ii  gir1.2-glib-2.0  1.54.1-4
ii  gir1.2-gtk-3.0   3.22.29-1
ii  gir1.2-notify-0.70.7.7-3
ii  gir1.2-pango-1.0 1.40.14-1
ii  imagemagick  8:6.9.9.39+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.39+dfsg-1
ii  python   2.7.14-4
ii  python-bs4   4.6.0-1
ii  python-cairo 1.16.2-1
ii  python-configobj 5.0.6-2
ii  python-dbus  1.2.6-1
ii  python-gi-cairo  3.26.1-2
ii  python-pil   4.3.0-2
ii  python-pycurl7.43.0.1-0.2
ii  python-requests  2.18.4-2
ii  python2.72.7.14-7

Versions of packages variety recommends:
ii  gir1.2-appindicator3-0.1  0.4.92-5
ii  python-httplib2   0.9.2+dfsg-1

Versions of packages variety suggests:
pn  feh   
pn  gnome-shell-extension-top-icons-plus  
pn  nitrogen  

-- no debconf information

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

Bug#893758: RM: goocanvas -- RoM; RoQA; unmaintained, replaced by goocanvas-2.0

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: goocan...@packages.debian.org

goocanvas was removed from Testing 2 months ago. It is no longer
maintained and developers are urged to migrate to goocanvas-2.0.

I am filing this bug to help out maintainer Ross Gammon who expressed
intent to remove goocanvas from Debian as soon as nothing depended on
it any more. [1]

I have filed a blocking RM bug for the only reverse dependency.

[1] https://bugs.debian.org/858636

Thanks,
Jeremy Bicha

Bug#893757: RM: libgoo-canvas-perl -- RoM; RoQA; unmaintained, no rdeps

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: libgoo-canvas-p...@packages.debian.org, intrig...@debian.org

libgoo-canvas-perl is the last package keeping the old goocanvas
library in Debian. libgoo-canvas has no reverse dependencies and was
already removed from Testing 2 months ago.

I got approval from Debian Perl maintainer intrigeri before filing this bug.

Thanks,
Jeremy Bicha

Bug#893756: ignition-common: FTBFS on hurd-i386: PATH_MAX not declared

[Aaron M. Ucko]

Source: ignition-common
Version: 1.0.1-1
Severity: normal
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd

The build of ignition-common for hurd-i386 (admittedly not a release
architecture) failed:

  /<>/src/FilesystemBoost.cc: In function 'std::__cxx11::string 
ignition::common::cwd()':
  /<>/src/FilesystemBoost.cc:134:25: error: 'PATH_MAX' was not 
declared in this scope

The Hurd makes a point of not having a static PATH_MAX.  Best practice
is dynamically accommodating whatever you actually encounter, for
instance by taking advantage of realpath's policy of allocating the
buffer itself when supplied a NULL buffer.  (You'll of course need to
free it when done.)

Could you please take a look?

Thanks!

-- 
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#893751: fixed but had to remove earlier version

[shirish शिरीष]

fixed 893751 2.2.1
thanks

Dear all,

What had happened is that I had taken the binaries from Vincent's
personal repo. at  https://people.debian.org/~vlegout/qalc/ and due to
that was facing the issue.

When I removed/purged the binaries from Vincent's repo. and installed
the ones from experimental,  the issue disappeared.

$ sudo aptitude purge qalculate qalculate-gtk
[sudo] password for shirish:
Sorry, try again.
[sudo] password for shirish:
Package qalculate is not installed, so it will not be purged
Package qalculate is not installed, so it will not be purged
The following packages will be REMOVED:
  qalculate-gtk{p}
The following partially installed packages will be configured:
  libqalculate14{b}
0 packages upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 3,837 kB will be freed.
The following packages have unmet dependencies:
 libqalculate14 : Depends: libqalculate14-data but it is not going to
be installed
The following actions will resolve these dependencies:

 Install the following packages:
1) libqalculate14-data [2.2.1-1 (experimental)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Remove the following packages:
1) libqalculate14 [2.2.1-1 (experimental, now)]
2) qalc [2.2.1-1 (experimental, now)]



Accept this solution? [Y/n/q/?] y
The following packages will be REMOVED:
  libqalculate14{a} qalc{a} qalculate-gtk{p}
0 packages upgraded, 0 newly installed, 3 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 6,889 kB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 175218 files and directories currently installed.)
Removing qalculate-gtk (2.2.1-1) ...
Removing qalc (2.2.1-1) ...
Removing libqalculate14:amd64 (2.2.1-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.23-2) ...
Processing triggers for libc-bin (2.27-2) ...
Processing triggers for man-db (2.8.2-1) ...
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -

Current status: 0 (-1) broken.

I removed/purged all the libqalculate 'oldish' binaries from Vincent's
personal repo. and replaced them with the ones from experimental.

shirish@debian:~$ aptitude search libqalculate
p   libqalculate-dev - Powerful
and easy to use desktop calculator - development
i   libqalculate-doc - Powerful
and easy to use desktop calculator - documentation
i   libqalculate14   - Powerful
and easy to use desktop calculator - library
i A libqalculate14-data  - Powerful
and easy to use desktop calculator - data
p   libqalculate14-dbgsym- debug
symbols for libqalculate14


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

Bug#893751: fixed but had to remove earlier version

[shirish शिरीष]

fixed 893751 2.2.1

Dear all,

What had happened is that I had taken the binaries from Vincent's
personal repo. at  https://people.debian.org/~vlegout/qalc/ and due to
that was facing the issue.

When I removed/purged the binaries from Vincent's repo. and installed
the ones from experimental,  the issue disappeared.

$ sudo aptitude purge qalculate qalculate-gtk
[sudo] password for shirish:
Sorry, try again.
[sudo] password for shirish:
Package qalculate is not installed, so it will not be purged
Package qalculate is not installed, so it will not be purged
The following packages will be REMOVED:
  qalculate-gtk{p}
The following partially installed packages will be configured:
  libqalculate14{b}
0 packages upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 3,837 kB will be freed.
The following packages have unmet dependencies:
 libqalculate14 : Depends: libqalculate14-data but it is not going to
be installed
The following actions will resolve these dependencies:

 Install the following packages:
1) libqalculate14-data [2.2.1-1 (experimental)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Remove the following packages:
1) libqalculate14 [2.2.1-1 (experimental, now)]
2) qalc [2.2.1-1 (experimental, now)]



Accept this solution? [Y/n/q/?] y
The following packages will be REMOVED:
  libqalculate14{a} qalc{a} qalculate-gtk{p}
0 packages upgraded, 0 newly installed, 3 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 6,889 kB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 175218 files and directories currently installed.)
Removing qalculate-gtk (2.2.1-1) ...
Removing qalc (2.2.1-1) ...
Removing libqalculate14:amd64 (2.2.1-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.23-2) ...
Processing triggers for libc-bin (2.27-2) ...
Processing triggers for man-db (2.8.2-1) ...
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -

Current status: 0 (-1) broken.

I removed/purged all the libqalculate 'oldish' binaries from Vincent's
personal repo. and replaced them with the ones from experimental.

shirish@debian:~$ aptitude search libqalculate
p   libqalculate-dev - Powerful
and easy to use desktop calculator - development
i   libqalculate-doc - Powerful
and easy to use desktop calculator - documentation
i   libqalculate14   - Powerful
and easy to use desktop calculator - library
i A libqalculate14-data  - Powerful
and easy to use desktop calculator - data
p   libqalculate14-dbgsym- debug
symbols for libqalculate14


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

Bug#891382: libgc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2018-02-25 01:52 Manuel A. Fernandez Montecelo:

Source: libgc
Version: 1:7.4.2-8.1
Severity: normal
Tags: patch upstream fixed-upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
Forwarded: 
https://github.com/ivmai/bdwgc/commit/4f7f0eebd24dcde9f2b3ec2cb98913fc39bbdda3

Hello,

We need support in this package for RISC-V, to bootstrap the riscv64
architecture.

A patch has been submitted upstream a few days ago, so it would be great if you
could include it as a patch and release a new version for unstable.

If we can help by NMUing the package or anything else, please let me/us know.

Since the package maintenance doesn't seem to be very active lately and this
package is quite critical for the (any) port, I plan to NMU if no reply is
received in a few days/weeks.


Uploading NMU to delayed/2 (almost a month passed already without
reply).  Please let me know if you want me to cancel it.

I tested it in many porterboxes (mips*, arm*, ppc64el, s390x) and it
built fine in all except armel, where it FTBFS for weeks.

debdiff attached.  It needed to update to the symbols file, apart from
the patch that I pointed to originally.


Cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru libgc-7.4.2/debian/changelog libgc-7.4.2/debian/changelog
--- libgc-7.4.2/debian/changelog2018-01-12 14:11:35.0 +0100
+++ libgc-7.4.2/debian/changelog2018-03-17 00:06:37.0 +0100
@@ -1,3 +1,14 @@
+libgc (1:7.4.2-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for the riscv64 architecture (Closes: #891382)
+- debian/patches/riscv-support.patch
+  + commit 4f7f0eebd24dcde9f2b3ec2cb98913fc39bbdda3 from upstream's
+repository, refreshed to un-fuzz
+- Update symbols file
+
+ -- Manuel A. Fernandez Montecelo   Sat, 17 Mar 2018 00:06:37 
+0100
+
 libgc (1:7.4.2-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libgc-7.4.2/debian/libgc1c2.symbols 
libgc-7.4.2/debian/libgc1c2.symbols
--- libgc-7.4.2/debian/libgc1c2.symbols 2018-01-12 14:11:01.0 +0100
+++ libgc-7.4.2/debian/libgc1c2.symbols 2018-03-16 23:41:04.0 +0100
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 1:7.4.2 alpha amd64 arm64 armel armhf hppa 
hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc 
powerpcspe ppc64 ppc64el s390x x32
+# SymbolsHelper-Confirmed: 1:7.4.2 alpha amd64 arm64 armel armhf hppa 
hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc 
powerpcspe ppc64 ppc64el riscv64 s390x x32
 libgc.so.1 libgc1c2 #MINVER#
  (arch=armel)AO_compare_double_and_swap_double_emulation@Base 1:7.4.2
  (arch=armel)AO_fetch_compare_and_swap_emulation@Base 1:7.4.2
@@ -9,8 +9,8 @@
  GC_FirstDLOpenedLinkMap@Base 1:7.2d
  (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d
  (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d
- (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!sh3 !sh4)GC_acquire_mark_lock@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!sh3 !sh4)GC_active_count@Base 1:7.4.2
+ (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!riscv64 !sh3 !sh4)GC_acquire_mark_lock@Base 1:7.4.2
+ (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!riscv64 !sh3 !sh4)GC_active_count@Base 1:7.4.2
  GC_add_ext_descriptor@Base 1:7.2d
  GC_add_map_entry@Base 1:7.2d
  GC_add_roots@Base 1:7.2d
@@ -27,8 +27,8 @@
  GC_alloc_large@Base 1:7.2d
  GC_alloc_large_and_clear@Base 1:7.2d
  GC_alloc_reclaim_list@Base 1:7.2d
- (arch=arm64 nios2 hppa ppc64el sh4)GC_allocate_lock@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh3 !sh4)GC_allocate_ml@Base 1:7.4.2
+ (arch=arm64 nios2 hppa ppc64el riscv64 sh4)GC_allocate_lock@Base 1:7.4.2
+ (arch=!arm64 !nios2 !hppa !ppc64el !riscv64 !sh3 !sh4)GC_allocate_ml@Base 
1:7.4.2
  GC_allochblk@Base 1:7.2d
  GC_allochblk_nth@Base 1:7.2d
  GC_allocobj@Base 1:7.2d
@@ -59,7 +59,7 @@
  GC_build_fl@Base 1:7.2d
  GC_build_fl_clear2@Base 1:7.2d
  GC_build_fl_clear4@Base 1:7.2d
- (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!sh3 !sh4)GC_bytes_allocd_tmp@Base 1:7.4.2
+ (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el 
!riscv64 !sh3 !sh4)GC_bytes_allocd_tmp@Base 1:7.4.2
  GC_bytes_found@Base 1:7.2d
  GC_call_with_alloc_lock@Base 1:7.2d
  GC_call_with_gc_active@Base 1:7.2d
@@ -94,12 +94,12 @@
  GC_continue_reclaim@Base 1:7.2d
  GC_copy_bl@Base 1:7.2d
  GC_copyright@Base 1:7.2d
- (arch=!arm64 !nios2 !hppa !ppc64el !sh3 !sh4)GC_core_finalized_malloc@Base 
1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh3 !sh4)GC_core_gcj_malloc@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh3 !sh4)GC_core_malloc@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh3 !sh4)GC_core_malloc_atomic@Base 
1:7.4.2
+ (arch=!arm64 !nios2 !hppa !ppc64el 

Bug#893755: python3.6: Dropped python3-distutils dependency makes hundreds of packages FTBFS

[Jeremy Bicha]

Source: python3.6
Version: 3.6.5~rc1-2
Severity: serious

This version of python3.6 dropped the dependency on python3-distutils.
This causes hundreds of packages to fail to build from source.
Therefore, let's delay its migration to Testing to give time for more
packages to be fixed.

Thanks,
Jeremy Bicha

Bug#893754: autopkgtest 5.1 "autopkgtest-default-release" breaks tests that exercise apt

[Steve Langasek]

Package: autopkgtest
Version: 5.1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu

When autopkgtest 5.2 was recently rolled out to the Ubuntu infrastructure,
various package-manager-related test suites began to fail as a result of the
use of APT::Default-Release introduced in 5.1:

==
ERROR: test a sources.list file with unicode comments
--
Traceback (most recent call last):
  File "/tmp/autopkgtest.5IPzS9/build.fFW/src/tests/test_sources_list.py", line 
582, in test_unicode_comments
d.openCache(lock=False)
  File "/tmp/autopkgtest.5IPzS9/build.fFW/src/DistUpgrade/DistUpgradeController.
py", line 211, in openCache
return self._openCache(lock)
  File "/tmp/autopkgtest.5IPzS9/build.fFW/src/DistUpgrade/DistUpgradeController.
py", line 239, in _openCache
lock)
  File "/tmp/autopkgtest.5IPzS9/build.fFW/src/DistUpgrade/DistUpgradeCache.py", 
line 136, in __init__
apt.Cache.__init__(self, progress)
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 113, in __init__
self.open(progress)
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 164, in open
self._cache = apt_pkg.Cache(progress)
apt_pkg.Error: E:The value 'bionic' is invalid for APT::Default-Release as such 
a release is not available in the sources

  http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/bionic/armhf

So far we've seen test failures from update-manager,
ubuntu-release-upgrader, and snapcraft - none of which are present in
Debian.  It possibly affects all consumers of python-apt (so may affect
python-apt itself, which is present in Debian).  Since python-apt
autopkgtests appear to be passing in Debian according to
, this may be
an Ubuntu-specific problem, or perhaps 5.1 is not yet rolled out to
ci.debian.net?

To unbreak Ubuntu I have reverted the changes from the merge of the pin-v2
branch in our production deployment.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#893753: leatherman: FTBFS on x32: test segfaults

[Aaron M. Ucko]

Source: leatherman
Version: 1.4.0+dfsg-1
Severity: normal
Tags: upstream
User: debian-...@lists.debian.org
Usertags: x32

The build of leatherman for x32 (admittedly not a release
architecture) failed, as detailed below.

Could you please take a look?

Thanks!

--

/usr/bin/ctest --force-new-ctest-process -j2
Test project /<>/leatherman-1.4.0+dfsg/obj-x86_64-linux-gnux32
Start 1: leatherman tests
1/1 Test #1: leatherman tests .***Exception: SegFault  0.15 sec

~~~
leatherman_test is a Catch v1.10.0 host application.
Run with -? for options

---
Scenario: executing commands with execution::execute
 Given: a command that succeeds
  When: requested to write stdout to a file in an unknown directory
---
/<>/leatherman-1.4.0+dfsg/execution/tests/posix/execution.cc:299
...

/<>/leatherman-1.4.0+dfsg/execution/tests/posix/execution.cc:299: 
FAILED:
due to a fatal error condition:
  SIGSEGV - Segmentation violation signal

===
test cases:   81 |   80 passed | 1 failed
assertions: 1349 | 1348 passed | 1 failed

-- 
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#893752: leatherman: FTBFS on hurd-i386: test times out

[Aaron M. Ucko]

Source: leatherman
Version: 1.4.0+dfsg-1
Severity: normal
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd

The build of leatherman for hurd-i386 (admittedly not a release
architecture) failed:

  Running tests...
  /usr/bin/ctest --force-new-ctest-process -j1
  Test project /<>/leatherman-1.4.0+dfsg/obj-i686-gnu
  Start 1: leatherman tests
  E: Build killed with signal TERM after 180 minutes of inactivity
  E: Build killed with signal KILL after 360 minutes of inactivity

Could you please take a look?

Thanks!

-- 
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#893751: libqalculate14: dpkg error, cannot overwrite libqalculate.mo which are both in libqalculate14 and libqalculate14-data

[shirish शिरीष]

Package: libqalculate14
Version: 2.2.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I tried to install the new package from experimental, got the following -
~$ sudo aptitude install libqalculate14-data
The following NEW packages will be installed:
  libqalculate14-data
The following partially installed packages will be configured:
  libqalculate14
0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/133 kB of archives. After unpacking 786 kB will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 175218 files and directories currently installed.)
Preparing to unpack .../libqalculate14-data_2.2.1-1_all.deb ...
Unpacking libqalculate14-data (2.2.1-1) ...
dpkg: error processing archive
/var/cache/apt/archives/libqalculate14-data_2.2.1-1_all.deb
(--unpack):
 trying to overwrite
'/usr/share/locale/fr/LC_MESSAGES/libqalculate.mo', which is also in
package libqalculate-data 2.2.1-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libqalculate14-data_2.2.1-1_all.deb
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -
E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg: dependency problems prevent configuration of libqalculate14:amd64:
 libqalculate14:amd64 depends on libqalculate14-data; however:
  Package libqalculate14-data is not installed.

dpkg: error processing package libqalculate14:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libqalculate14:amd64

The main problem seems to be in -

dpkg: error processing archive
/var/cache/apt/archives/libqalculate14-data_2.2.1-1_all.deb
(--unpack):
 trying to overwrite
'/usr/share/locale/fr/LC_MESSAGES/libqalculate.mo', which is also in
package libqalculate-data 2.2.1-1

Please fix the same.

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libqalculate14 depends on:
ii  libc62.27-2
ii  libcurl3-gnutls  7.58.0-2
ii  libgcc1  1:8-20180312-2
ii  libgmp10 2:6.1.2+dfsg-3
ii  libicu57 57.1-9
ii  libmpfr6 4.0.1-1
pn  libqalculate14-data  
ii  libstdc++6   8-20180312-2
ii  libxml2  2.9.4+dfsg1-6.1

libqalculate14 recommends no packages.

libqalculate14 suggests no packages.

-- no debconf information



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

Bug#893750: universal-ctags: FTBFS on hurd-i386: timeouts, even on empty input

[Aaron M. Ucko]

Source: universal-ctags
Version: 0+git20180225-1
Severity: normal
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd

The build of universal-ctags for hurd-i386 (admittedly not a release
architecture) failed with timeouts across the board, even on empty
input, per the below excerpts from [1].

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=universal-ctags=hurd-i386=0%2Bgit20180225-1=1519749399=0

--

Category: ROOT

Testing conflib-recursive as Coffailed 
(TIMED OUT)
Shrinking ./Units/conflib-recursive.d/input.cof as Cof
[0292]...timeout(124)
[0  0]...timeout(124)
the target command line exits abnormally against the empty input
Testing conflib-simple as coffeefailed 
(TIMED OUT)
Shrinking ./Units/conflib-simple.d/input.coffee as coffee
[0292]...timeout(124)
[0  0]...timeout(124)
the target command line exits abnormally against the empty input
[...]
Testing truncation as C/xreffailed 
(TIMED OUT)
Shrinking ./Units/xformat-option.r/truncation.d/input.c as C
[0103]...timeout(124)
[0  0]...timeout(124)
the target command line exits abnormally against the empty input

Summary (see CMDLINE.tmp to reproduce without test harness)

  #passed:0
  #FIXED: 0
  #FAILED (broken args.ctags?):   0
  #FAILED (unexpected-exit-status):   0
  #FAILED (unexpected-output):0
  #TIMED-OUT (10s)865


-- 
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#893749: stretch-pu: package easytag/2.4.3-1+deb9u1

[James Cowgill]

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

Hi,

The purpose of this update to easytag is to fix #855251 where easytag
will sometimes corrupt ogg (and related) files it tags. The corruption
causes some of the music data to be overwritten near the start of the
file. This causes an audible click and various tools print errors about
trying to play a corrupt file. The upstream bug has now been open since
late 2016, is apparently very difficult to fix (lots of code to be
written) and there is no fix in progress which I can see. Due to this, I
have completely disabled ogg support in unstable and I think doing the
same in stable is the best cause of action to prevent people from
corrupting their music collection.

Debdiff attached. It also contains a related change to the control file.
I thought about adding a NEWS entry but I wasn't sure (I did not add one
for unstable).

Thanks,
James

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru easytag-2.4.3/debian/changelog easytag-2.4.3/debian/changelog
--- easytag-2.4.3/debian/changelog  2016-12-05 23:46:24.0 +
+++ easytag-2.4.3/debian/changelog  2018-03-08 22:20:29.0 +
@@ -1,3 +1,13 @@
+easytag (2.4.3-1+deb9u1) stretch; urgency=medium
+
+  [ James Cowgill ]
+  * Disable OGG, OPUS and Speex. (Closes: #855251)
+
+  [ Bruno Kleinert ]
+  * Do not mention OGG support in package description. (Closes: #886369)
+
+ -- James Cowgill   Thu, 08 Mar 2018 22:20:29 +
+
 easytag (2.4.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru easytag-2.4.3/debian/control easytag-2.4.3/debian/control
--- easytag-2.4.3/debian/control2016-12-05 20:47:35.0 +
+++ easytag-2.4.3/debian/control2018-03-08 22:18:48.0 +
@@ -50,9 +50,8 @@
  .
  Currently EasyTAG supports the following:
   - View, edit, write tags of MP3, MP2 files (ID3 tag), FLAC files (FLAC Vorbis
-tag), Ogg Opus, Ogg Speex and Ogg Vorbis files (Ogg Vorbis tag),
-MP4/M4A/AAC files (MPEG-4 Part 10 tag), and MusePack, Monkey's Audio files
-(APE tag);
+tag), MP4/M4A/AAC files (MPEG-4 Part 10 tag), and MusePack, Monkey's Audio
+files (APE tag);
   - Auto tagging: parse file and directory names using masks to automatically
 fill in tag fields;
   - Cover art support for all formats;
@@ -72,6 +71,10 @@
   - A playlist generator window;
   - A file searching window;
   - Simple and explicit interface.
+ .
+ OGG support is currently disabled in this package because of a data corruption
+ bug. To edit tags in OGG files you may consider one of these packages: 
exfalso,
+ puddletag, kid3-qt, entagged.
 
 Package: easytag-nautilus
 Architecture: any
diff -Nru easytag-2.4.3/debian/gbp.conf easytag-2.4.3/debian/gbp.conf
--- easytag-2.4.3/debian/gbp.conf   2016-12-05 20:47:35.0 +
+++ easytag-2.4.3/debian/gbp.conf   2018-03-08 22:17:33.0 +
@@ -1,3 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 compression = xz
+debian-branch = debian/stretch
diff -Nru easytag-2.4.3/debian/rules easytag-2.4.3/debian/rules
--- easytag-2.4.3/debian/rules  2016-12-05 20:47:35.0 +
+++ easytag-2.4.3/debian/rules  2018-03-08 22:18:29.0 +
@@ -10,7 +10,9 @@
dh_autoreconf --as-needed
 
 override_dh_auto_configure:
-   dh_auto_configure -- --disable-silent-rules --disable-Werror
+   # OGG, OPUS and Speex disabled due to #855251
+   dh_auto_configure -- --disable-silent-rules --disable-Werror \
+   --disable-ogg --disable-opus --disable-speex
 
 override_dh_installdocs:
dh_installdocs --link-doc=easytag


signature.asc
Description: OpenPGP digital signature

Bug#891060: Atheros AR9271 ath9k_htc USB WiFi connected but IP traffic stops

[Ben Caradoc-Davies]

Modified patch accepted upstream:

mac80211: add ieee80211_hw flag for QoS NDP support
https://patchwork.kernel.org/patch/10299025/

Also requires a new one-line patch from the module maintainer to turn on 
the new flag:


ath9k_htc: use non-QoS NDP for AP probing
https://patchwork.kernel.org/patch/10299031/

Patches attached. Note that the mac80211 patch for master will not apply 
to 4.15.x source which lacks TDLS_BUFFER_STA change; please use the 
backport version ("...-backport.patch) of the mac80211 patch, also 
attached, for 4.15.x, where it applies cleanly.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

>From patchwork Wed Mar 21 10:01:43 2018
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: ath9k_htc: use non-QoS NDP for AP probing
From: Johannes Berg 
X-Patchwork-Id: 10299031
Message-Id: <20180321100143.28080-1-johan...@sipsolutions.net>
To: linux-wirel...@vger.kernel.org
Cc: Johannes Berg 
Date: Wed, 21 Mar 2018 11:01:43 +0100

From: Johannes Berg 

When switching mac80211 to use QoS NDP, it turned out that
ath9k_htc is somehow broken by this, e.g. see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060.

Fix this by using the new mac80211 flag to go back to the
old, incorrect, behaviour for this driver.

Fixes: 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing")
Reported-by: Ben Caradoc-Davies 
Signed-off-by: Johannes Berg 
Acked-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index e89e5ef2c2a4..f246e9ed4a81 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -729,6 +729,7 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
 	ieee80211_hw_set(hw, SPECTRUM_MGMT);
 	ieee80211_hw_set(hw, SIGNAL_DBM);
 	ieee80211_hw_set(hw, AMPDU_AGGREGATION);
+	ieee80211_hw_set(hw, DOESNT_SUPPORT_QOS_NDP);
 
 	if (ath9k_ps_enable)
 		ieee80211_hw_set(hw, SUPPORTS_PS);
>From patchwork Wed Mar 21 09:54:06 2018
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: mac80211: add ieee80211_hw flag for QoS NDP support
From: Johannes Berg 
X-Patchwork-Id: 10299025
Message-Id: <20180321095406.23974-1-johan...@sipsolutions.net>
To: linux-wirel...@vger.kernel.org
Cc: Ben Caradoc-Davies 
Date: Wed, 21 Mar 2018 10:54:06 +0100

From: Ben Caradoc-Davies 

Commit 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing") added an
argument qos_ok to ieee80211_nullfunc_get to support QoS NDP. Despite
the claim in the commit log "Change all the drivers to *not* allow
QoS NDP for now, even though it looks like most of them should be OK
with that", this commit enables QoS NDP in response to beacons (see
change to mlme.c:ieee80211_send_nullfunc), causing ath9k_htc to lose
IP connectivity. See:
https://patchwork.kernel.org/patch/10241109/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060

Introduce a hardware flag to allow such buggy drivers to override the
correct default behaviour of mac80211 of sending QoS NDP packets.

Signed-off-by: Ben Caradoc-Davies 
Signed-off-by: Johannes Berg 
---
 include/net/mac80211.h | 4 
 net/mac80211/debugfs.c | 1 +
 net/mac80211/mlme.c| 3 ++-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index c96511fa9198..2b581bd93812 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2063,6 +2063,9 @@ struct ieee80211_txq {
  * @IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA: Hardware supports buffer STA on
  *	TDLS links.
  *
+ * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
+ *	support QoS NDP for AP probing - that's most likely a driver bug.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2106,6 +2109,7 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_REPORTS_LOW_ACK,
 	IEEE80211_HW_SUPPORTS_TX_FRAG,
 	IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA,
+	IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP,
 
 	/* keep last, obviously */
 	NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 1f466d12a6bc..94c7ee9df33b 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -212,6 +212,7 @@ static const char *hw_flag_names[] = {
 	FLAG(REPORTS_LOW_ACK),
 	FLAG(SUPPORTS_TX_FRAG),
 	FLAG(SUPPORTS_TDLS_BUFFER_STA),
+	FLAG(DOESNT_SUPPORT_QOS_NDP),
 #undef FLAG
 };
 
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 39b660b9a908..5f303abac5ad 100644

Bug#893658: [pkg-cinnamon] Bug#893658: cinnamon: recommend smart-notifier

[Christoph Anton Mitterer]

Hey.

On Wed, 2018-03-21 at 16:10 +0100, Fabio Fantoni wrote:
> smart-notifier has latest build of 6 years ago, if not maintained
> anymore there is more risk of issue or for example in the case will
> not
> migrate to python3 before timelimit and will be removed.
> In that case don't seems a good idea add it to recommends (if not
> really
> needed), or I'm wrong?

Mhh, I wasn't aware that it's unmaintained... :-(
OTOH, the code seems really pretty simple and there is a python3-dbus,
so I'd guess porting it would be not too difficult.

Given it's simplicity, I'd also say that any serious issues are rather
unlikely.


So right now I'd still say, recommend it (otherwise people may only
notice their smart errors if it's too late).
Even *if* it would be dropped from Debian, it would simply be
removed... so no real issue as well (apart from having no SMART error
notification anymore).


I've submitted:
https://github.com/linuxmint/Cinnamon/issues/7383
asking for some "integrated" SMART notification... but whether this
will be implemented (and when) is completely open, so I'd still say it
makes sense to recommend the existing solution until something better
is there.


Anyway,.. just an idea :-)


Cheers,
Chris-

Bug#893747: qgis: FTBFS on sh4: dynamic module does not define init function

[Aaron M. Ucko]

Source: qgis
Version: 2.18.17+dfsg-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-sup...@lists.debian.org
Usertags: sh4

Builds of qgis for sh4 (admittedly not a release architecture) have
been failing lately, per the below excerpt from [1]:

  cd 
/<>/qgis-2.18.17+dfsg/debian/build/python/plugins/GdalTools/tools && 
../../../../../../scripts/pyuic-wrapper.sh /usr/bin/pyuic4 
/<>/qgis-2.18.17+dfsg/debian/build/output/lib 
/<>/qgis-2.18.17+dfsg/debian/build/output/python /usr/bin/python2.7 
/<>/qgis-2.18.17+dfsg/python/plugins/GdalTools/tools/dialogAbout.ui 
-o 
/<>/qgis-2.18.17+dfsg/debian/build/python/plugins/GdalTools/tools/ui_dialogAbout.py
  Traceback (most recent call last):
File "../../../../../../scripts/pyuic-wrapper.py", line 26, in 
  import qgis.PyQt.uic.pyuic
File 
"/<>/qgis-2.18.17+dfsg/debian/build/output/python/qgis/__init__.py", 
line 27, in 
  from qgis.core import QgsFeature, QgsGeometry
File 
"/<>/qgis-2.18.17+dfsg/debian/build/output/python/qgis/core/__init__.py",
 line 30, in 
  from qgis._core import *
  ImportError: dynamic module does not define init function (init_core)

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=qgis=sh4=2.18.17%2Bdfsg-1=1519759328=0

-- 
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#893745: python-cffi: FTBFS on ia64: several test failures

[Aaron M. Ucko]

Source: python-cffi
Version: 1.11.5-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-i...@lists.debian.org
Usertags: ia64

Builds of python-cffi for ia64 (admittedly not a release architecture)
have been failing lately, per the below excerpts from [1].

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=python-cffi=ia64=1.11.5-1=1519768961=0

--

I: pybuild base:184: python2.7 -m pytest c/ testing/
= test session starts ==
[...]
=== FAILURES ===
__ test_struct_return_in_func __

def test_struct_return_in_func():
BChar = new_primitive_type("char")
BShort = new_primitive_type("short")
BFloat = new_primitive_type("float")
BDouble = new_primitive_type("double")
BInt = new_primitive_type("int")
BStruct = new_struct_type("struct foo_s")
complete_struct_or_union(BStruct, [('a1', BChar, -1),
   ('a2', BShort, -1)])
BFunc10 = new_function_type((BInt,), BStruct)
f = cast(BFunc10, _testfunc(10))
s = f(40)
assert repr(s) == ""
>   assert s.a1 == bytechr(40)
E   AssertionError: assert '\x00' == '('
E - \x00
E + (

c/test_c.py:2014: AssertionError
_ TestFFI.test_struct_by_value _

self = 

def test_struct_by_value(self):
if self.module is None:
py.test.skip("fix the auto-generation of the tiny test lib")
ffi = FFI(backend=self.Backend())
ffi.cdef("""
typedef struct {
long x;
long y;
} POINT;

typedef struct {
long left;
long top;
long right;
long bottom;
} RECT;

long left, top, right, bottom;

RECT ReturnRect(int i, RECT ar, RECT* br, POINT cp, RECT dr,
RECT *er, POINT fp, RECT gr);
""")
ownlib = ffi.dlopen(self.module)

rect = ffi.new('RECT[1]')
pt = ffi.new('POINT[1]')
pt[0].x = 15
pt[0].y = 25
rect[0].left = ownlib.left
rect[0].right = ownlib.right
rect[0].top = ownlib.top
rect[0].bottom = ownlib.bottom

for i in range(4):
ret = ownlib.ReturnRect(i, rect[0], rect, pt[0], rect[0],
rect, pt[0], rect[0])
>   assert ret.left == ownlib.left
E   AssertionError: assert 18014398513676288 == 10
E+  where 18014398513676288 = .left
E+  and   10 = .left

testing/cffi0/test_ownlib.py:296: AssertionError
___ TestOwnLib.test_struct_by_value 

self = 

def test_struct_by_value(self):
if self.module is None:
py.test.skip("fix the auto-generation of the tiny test lib")
ffi = FFI(backend=self.Backend())
ffi.cdef("""
typedef struct {
long x;
long y;
} POINT;

typedef struct {
long left;
long top;
long right;
long bottom;
} RECT;

long left, top, right, bottom;

RECT ReturnRect(int i, RECT ar, RECT* br, POINT cp, RECT dr,
RECT *er, POINT fp, RECT gr);
""")
ownlib = ffi.dlopen(self.module)

rect = ffi.new('RECT[1]')
pt = ffi.new('POINT[1]')
pt[0].x = 15
pt[0].y = 25
rect[0].left = ownlib.left
rect[0].right = ownlib.right
rect[0].top = ownlib.top
rect[0].bottom = ownlib.bottom

for i in range(4):
ret = ownlib.ReturnRect(i, rect[0], rect, pt[0], rect[0],
rect, pt[0], rect[0])
>   assert ret.left == ownlib.left
E   AssertionError: assert 18014398513676288 == 123457
E+  where 18014398513676288 = .left
E+  and   123457 = .left

testing/cffi0/test_ownlib.py:296: AssertionError
___ test_no_unknown_exported_symbols ___

def test_no_unknown_exported_symbols():
if not hasattr(_cffi_backend, '__file__'):
py.test.skip("_cffi_backend module is built-in")
if not sys.platform.startswith('linux'):
py.test.skip("linux-only")
g = os.popen("objdump -T '%s'" % _cffi_backend.__file__, 'r')
for line in g:

Bug#893746: dh-autoreconf: Consider adding support for Xfce packages (via xdt-autogen)

[Unit 193]

Package: dh-autoreconf
Version: 16
Severity: wishlist

Dear Maintainer,

Please consider adding support for packages which make use of XDT_* features, 
using xdt-autogen.

As it stands, any Xfce package using dh 10 or above must override dh_autoreconf 
with 'NOCONFIGURE=1 dh_autoreconf xdt-autogen' which is not known by all DDs 
and may lead to bugs such as #870420.

An functional example patch inline below.


--- a/dh_autoreconf 2017-03-31 12:13:10.0 -0400
+++ b/dh_autoreconf 2018-02-14 18:36:41.665562722 -0500
@@ -154,9 +154,17 @@
 eval {
 # Run autoreconf to recreate the needed files.
 my $pwd = getcwd();
+my $dir = '.';
 chdir $opt_sourcedir if (defined($opt_sourcedir) && !compat(9));
 
-@ARGV ? doit(@ARGV, @{$dh{U_PARAMS}}) : doit('autoreconf', '-f', '-i', 
@directories);
+if (@ARGV) {
+doit(@ARGV, @{$dh{U_PARAMS}});
+} elsif (complex_doit("grep -q '^XDT_' ${dir}/configure.ac 
${dir}/configure.in")) {
+$ENV{NOCONFIGURE}='1';
+doit('xdt-autogen', @directories);
+} else {
+doit('autoreconf', '-f', '-i', @directories);
+};
 
 chdir $pwd;
 1;



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

Kernel: Linux 4.14.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-autoreconf depends on:
ii  autoconf   2.69-11
ii  automake   1:1.15.1-3
ii  autopoint  0.19.8.1-4
ii  debhelper  11.1.5
ii  libtool2.4.6-2
ii  perl   5.26.1-5

dh-autoreconf recommends no packages.

dh-autoreconf suggests no packages.

-- no debconf information

Bug#893741: golang-golang-x-net-dev: misses support for some (non-release, gccgo) architectures

[Aaron M. Ucko]

Package: golang-golang-x-net-dev
Version: 1:0.0+git20170629.c81e7f2+dfsg-2
Severity: normal
Tags: upstream
Control: affects -1 src:irtt

golang-golang-x-net-dev lacks support for most or all gccgo
architectures (none of which are release architectures, granted),
leading to heavy errors when trying to build dependent packages such
as irtt on these architectures, as in [1]:

  # golang.org/x/net/internal/socket
  src/golang.org/x/net/internal/socket/cmsghdr.go:9:10: error: use of undefined 
type 'cmsghdr'
  [...]

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=irtt=alpha=0.9.0-2=1519744561=0

-- 
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#880771: Fwd: Re: Cross-compiling libdwarf

[David Anderson]

On 03/20/2018 11:45 AM, Helmut Grohne wrote:
> I admit that setting up a cross build environment is not trivial ...
> unless you use Debian. There it just an apt-get away. All you need to do
> is install the right cross compiler (e.g. gcc-arm-linux-gnueabihf) and
> configure for a cross build (e.g. --host=arm-linux-gnueabihf).

I'm running Xubuntu so that should work.
I had no idea it was that easy.

Finishing up some DWARF5 work in libdwarf now, but over the next few days I
hope to work on the cross issue.

The diff you attached is good.

Thanks.
David Anderson

-- 
Don't worry about people stealing your ideas.
If your ideas are any good, you'll have to 
ram them down people's throats. -- Howard Aiken

Bug#893740: scons: debian patch breaks python 3 compatibility

[Bernd Zeimetz]

Package: scons
Version: 3.0.1-1
Severity: important
Tags: patch

hi,

in debian/patches/0110-remove_stale_files.patch python3 compat
is being broken by

if os.environ.has_key('DH_INTERNAL_OPTIONS'):

the python2/3 compatible way would be

if 'DH_INTERNAL_OPTIONS' in os.environ:

Please fix this.

Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#893742: "a newer."?

[積丹尼 Dan Jacobson]

Package: i965-va-driver-shaders
Version: 2.1.0-1
Severity: minor

Description-en: VAAPI driver for Intel G45 & HD Graphics family
...
 This package contains also contains the non-free encode shaders for VP8, VP9,
 HEVC and AVC for generation 7.5 hardware a newer.
  ^^^
"a newer."?

Bug#893743: python-cffi: FTBFS on hurd-i386: test_thread AssertionError

[Aaron M. Ucko]

Source: python-cffi
Version: 1.11.5-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org
Usertags: hurd

The latest build of python-cffi for hurd-i386 (admittedly not a
release architecture) failed, per the below excerpts from [1]:

  I: pybuild base:184: python2.7-dbg -m pytest c/ testing/
  = test session starts 
==
  [...]
  === FAILURES 
===
  _ TestThread.test_init_different_modules_in_different_threads 
__
  
  self = 
  
  def test_init_different_modules_in_different_threads(self):
  add1_cffi = self.prepare_module('add1')
  add2_cffi = self.prepare_module('add2')
  self.compile('thread2-test', [add1_cffi, add2_cffi], threads=True)
  output = self.execute('thread2-test')
  output = self._take_out(output, "preparing")
  output = self._take_out(output, ".")
  output = self._take_out(output, ".")
  # at least the 3rd dot should be after everything from ADD2
  >   assert output == ("starting\n"
"prepADD2\n"
"adding 1000 and 200 and 30\n"
".\n"
"adding 40 and 2\n"
"done\n")
  E   AssertionError: assert 'starting\n.\...nd 30\ndone\n' == 
'starting\npre...and 2\ndone\n'
  E   starting
  E + prepADD2
  E + adding 1000 and 200 and 30
  E   .
  E   adding 40 and 2
  E - prepADD2
  E - adding 1000 and 200 and 30...
  E 
  E ...Full output truncated (2 lines hidden), use '-vv' to show
  
  testing/embedding/test_thread.py:29: AssertionError

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=python-cffi=hurd-i386=1.11.5-1=1519773174=0

-- 
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#893744: ITP: puppet-module-puppetlabs-translate -- Puppet module that provides the translate() function for internationalization

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: puppet-module-puppetlabs-translate
  Version : 1.1.0
  Upstream Author : Puppet Labs Inc 
* URL : https://forge.puppetlabs.com/puppetlabs/translate
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet module that provides the translate() function for
internationalization

 Puppet lets you centrally manage every important aspect of your system
 using a cross-platform specification language that manages all the
 separate elements normally aggregated in different files, like users,
 cron jobs, and hosts, along with obviously discrete elements like
 packages, services, and files.
 .
 Puppet module that provides the translate() function for internationalization.

This package will be maintained inside the Debian puppet-team, and it's a new
dependency
of puppet-module-puppetlabs-mysql package.

Bug#890845: HighContrast icon theme doesn't work with GTK3

[Jeremy Bicha]

Control: forwarded -1
https://gitlab.gnome.org/GNOME/gnome-themes-extra/issues/17
Control: tags -1 -moreinfo
Control: severity -1 serious

On Thu, Mar 15, 2018 at 7:34 AM, Yuri D'Elia  wrote:
> Can you reproduce the issue? If so, I would be glad if you could report
> it.

Forwarded.

Thanks,
Jeremy Bicha

Bug#893739: gettext: FTBFS with openjdk-9 as default-jdk

[Tiago Daitx]

Dear Maintainer,

Sorry for confusing initial report.
I'm copying the original message bellow and attaching the debdiff for
review again.


Currently gettext FTBFS when building with openjdk-9 due to:

cp: cannot stat 'debian/tmp/usr/share/gettext/libintl.jar': No such
file or directory

which in turn is caused by a configure failing to detect openjdk:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 9, please update gt_JAVACOMP macro
checking for Java compiler... no


For comparison, the above message, when compiling with OpenJDK 8 is:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 1.8, please update gt_JAVACOMP macro
checking for Java compiler... /usr/lib/jvm/default-java/bin/javac
-target 1.1 -source 1.3


The attached debdiff, copied from opensuse and modified to include
support for source/target 1.7 and 1.8, fixes this issue.

The configure message, with the patch applied, is:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 9, please update gt_JAVACOMP macro
checking for Java compiler... no


Please consider applying it to enable the work for transitioning
default-jdk from openjdk-8 to openjdk-9.

thanks
Tiago Daitx
diff -Nru gettext-0.19.8.1/debian/changelog gettext-0.19.8.1/debian/changelog
--- gettext-0.19.8.1/debian/changelog	2018-03-04 09:24:05.0 +0100
+++ gettext-0.19.8.1/debian/changelog	2018-03-20 19:47:19.0 +0100
@@ -1,3 +1,10 @@
+gettext (0.19.8.1-4ubuntu5~02) UNRELEASED; urgency=medium
+
+  * d/p/04-enable-jdk9-compatibility.patch: enable building with
+source and target flags set to 1.8; update gt_JAVACOMP macro.
+
+ -- Tiago Stürmer Daitx   Tue, 20 Mar 2018 18:47:19 +
+
gettext (0.19.8.1-4) unstable; urgency=medium

  * Avoid extraneous NUL bytes in .mo files. Closes: #872869.
diff -Nru gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch
--- gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch	1970-01-01 01:00:00.0 +0100
+++ gettext-0.19.8.1/debian/patches/04-enable-jdk9-compatibility.patch	2018-03-20 19:47:19.0 +0100
@@ -0,0 +1,235 @@
+Description: Enable compatibility with JDK 9+
+ According to JEP-182 OpenJDK 9 will only support 1.6 or later for source and
+ target flags. This patch adds supports for 1.6, 1.7, and 1.8 flags for
+ detecting and building gettext java.
+ Modified from opensuse to include support for 1.7 and 1.8.
+Origin: opensuse, https://build.opensuse.org/package/view_file/openSUSE:Factory/gettext-runtime/gettext-0.19.8.1-jdk9.patch
+Bug-Debian: 
+Forwarded: no
+Last-Update: 2018-03-21
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: gettext-0.19.8.1/gettext-runtime/configure.ac
+===
+--- gettext-0.19.8.1.orig/gettext-runtime/configure.ac
 gettext-0.19.8.1/gettext-runtime/configure.ac
+@@ -35,7 +35,7 @@ AC_PROG_YACC
+ 
+ gt_JAVA_CHOICE
+ 
+-gt_JAVACOMP([1.3], [1.1])
++gt_JAVACOMP([1.6], [1.6])
+ AC_CHECK_PROG([JAR], [jar], [jar])
+ if test -n "$HAVE_JAVACOMP" && test -n "$JAR" && test "$JAVA_CHOICE" != no; then
+   BUILDJAVA=yes
+Index: gettext-0.19.8.1/gettext-runtime/gnulib-m4/javacomp.m4
+===
+--- gettext-0.19.8.1.orig/gettext-runtime/gnulib-m4/javacomp.m4
 gettext-0.19.8.1/gettext-runtime/gnulib-m4/javacomp.m4
+@@ -16,6 +16,8 @@ dnl with or without modifications, as lo
+ #   1.4 assert keyword
+ #   1.5 generic classes and methods
+ #   1.6 (not yet supported)
++#   1.7 (not yet supported)
++#   1.8 (not yet supported)
+ #
+ # target-version can be:  classfile version:
+ #   1.1 45.3
+@@ -24,6 +26,8 @@ dnl with or without modifications, as lo
+ #   1.4 48.0
+ #   1.5 49.0
+ #   1.6 50.0
++#   1.7 51.0
++#   1.8 52.0
+ # The classfile version of a .class file can be determined through the "file"
+ # command. More portably, the classfile major version can be determined through
+ # "od -A n -t d1 -j 7 -N 1 classfile".
+@@ -36,6 +40,8 @@ dnl with or without modifications, as lo
+ #   1.4 JDK/JRE 1.4, gij 4.0, 4.1
+ #   1.5 JDK/JRE 1.5
+ #   1.6 JDK/JRE 1.6
++#   1.7 JDK/JRE 7
++#   1.8 JDK/JRE 8
+ # Note: gij >= 3.3 can in some cases handle classes compiled with -target 1.4,
+ # and gij >= 4.1 can in some cases partially handle classes compiled with
+ # -target 1.5, but I have no idea how complete this support is.
+@@ -47,7 +53,9 @@ dnl with or without modifications, as lo
+ # It is unreasonable to ask for:
+ #   - 

Bug#893739: gettext: FTBFS with openjdk-9 as default-jdk

[Tiago Stürmer Daitx]

Package: gettext
Version: 0.19.8-2
Severity: important

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)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Content-Type: multipart/mixed; boundary="===3187527196013602937=="
MIME-Version: 1.0
From: =?utf-8?q?Tiago_St=C3=BCrmer_Daitx?= 
To: Debian Bug Tracking System 
Subject: gettext: FTBFS with openjdk 9 as default-jdk
Message-ID: <152167117225.13763.14111882470295268469.reportbug@tdaitx-P65>
X-Mailer: reportbug 7.1.8ubuntu1
Date: Wed, 21 Mar 2018 23:26:12 +0100
X-Debbugs-Cc: tiago.da...@canonical.com

This is a multi-part MIME message sent by reportbug.


--===3187527196013602937==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Package: gettext
Version: 0.19.8-2
Severity: important

Dear Maintainer,

Currently gettext FTBFS when building with openjdk-9 due to:

cp: cannot stat 'debian/tmp/usr/share/gettext/libintl.jar': No such file or 
directory

which in turn is caused by a configure failing to detect openjdk:

checking for Java virtual machine... java
configure: WARNING: unknown target-version 9, please update gt_JAVACOMP macro
checking for Java compiler... no


For comparison, the above message, when compiling with OpenJDK 8 is:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 1.8, please update gt_JAVACOMP macro
checking for Java compiler... /usr/lib/jvm/default-java/bin/javac -target 1.1 
-source 1.3


The attached debdiff, copied from opensuse and modified to include
support for source/target 1.7 and 1.8, fixes this issue.

The configure message, with the patch applied, is:
checking for Java virtual machine... java
configure: WARNING: unknown target-version 9, please update gt_JAVACOMP macro
checking for Java compiler... no


Please consider applying it to enable the work for transitioning
default-jdk from openjdk-8 to openjdk-9.

thanks
Tiago Daitx

-- System Information:
Debian Release: buster/sid
  APT prefers bionic
  APT policy: (500, 'bionic'), (400, 'bionic-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-10-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--===3187527196013602937==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; 
filename="gettext_0.19.8-1_debdiff_0.19.8-2.patch"

ZGlmZiAtTnJ1IGdldHRleHQtMC4xOS44LjEvZGViaWFuL2NoYW5nZWxvZyBnZXR0ZXh0LTAuMTku
OC4xL2RlYmlhbi9jaGFuZ2Vsb2cKLS0tIGdldHRleHQtMC4xOS44LjEvZGViaWFuL2NoYW5nZWxv
ZwkyMDE4LTAzLTA0IDA5OjI0OjA1LjAwMDAwMDAwMCArMDEwMAorKysgZ2V0dGV4dC0wLjE5Ljgu
MS9kZWJpYW4vY2hhbmdlbG9nCTIwMTgtMDMtMjAgMTk6NDc6MTkuMDAwMDAwMDAwICswMTAwCkBA
IC0xLDMgKzEsMTAgQEAKK2dldHRleHQgKDAuMTkuOC4xLTR1YnVudHU1fjAyKSBVTlJFTEVBU0VE
OyB1cmdlbmN5PW1lZGl1bQorCisgICogZC9wLzA0LWVuYWJsZS1qZGs5LWNvbXBhdGliaWxpdHku
cGF0Y2g6IGVuYWJsZSBidWlsZGluZyB3aXRoCisgICAgc291cmNlIGFuZCB0YXJnZXQgZmxhZ3Mg
c2V0IHRvIDEuODsgdXBkYXRlIGd0X0pBVkFDT01QIG1hY3JvLgorCisgLS0gVGlhZ28gU3TDvHJt
ZXIgRGFpdHggPHRpYWdvLmRhaXR4QHVidW50dS5jb20+ICBUdWUsIDIwIE1hciAyMDE4IDE4OjQ3
OjE5ICswMDAwCisKZ2V0dGV4dCAoMC4xOS44LjEtNCkgdW5zdGFibGU7IHVyZ2VuY3k9bWVkaXVt
CgogICogQXZvaWQgZXh0cmFuZW91cyBOVUwgYnl0ZXMgaW4gLm1vIGZpbGVzLiBDbG9zZXM6ICM4
NzI4NjkuCmRpZmYgLU5ydSBnZXR0ZXh0LTAuMTkuOC4xL2RlYmlhbi9wYXRjaGVzLzA0LWVuYWJs
ZS1qZGs5LWNvbXBhdGliaWxpdHkucGF0Y2ggZ2V0dGV4dC0wLjE5LjguMS9kZWJpYW4vcGF0Y2hl
cy8wNC1lbmFibGUtamRrOS1jb21wYXRpYmlsaXR5LnBhdGNoCi0tLSBnZXR0ZXh0LTAuMTkuOC4x
L2RlYmlhbi9wYXRjaGVzLzA0LWVuYWJsZS1qZGs5LWNvbXBhdGliaWxpdHkucGF0Y2gJMTk3MC0w
MS0wMSAwMTowMDowMC4wMDAwMDAwMDAgKzAxMDAKKysrIGdldHRleHQtMC4xOS44LjEvZGViaWFu
L3BhdGNoZXMvMDQtZW5hYmxlLWpkazktY29tcGF0aWJpbGl0eS5wYXRjaAkyMDE4LTAzLTIwIDE5
OjQ3OjE5LjAwMDAwMDAwMCArMDEwMApAQCAtMCwwICsxLDIzNSBAQAorRGVzY3JpcHRpb246IEVu
YWJsZSBjb21wYXRpYmlsaXR5IHdpdGggSkRLIDkrCisgQWNjb3JkaW5nIHRvIEpFUC0xODIgT3Bl
bkpESyA5IHdpbGwgb25seSBzdXBwb3J0IDEuNiBvciBsYXRlciBmb3Igc291cmNlIGFuZAorIHRh
cmdldCBmbGFncy4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnRzIGZvciAxLjYsIDEuNywgYW5kIDEu
OCBmbGFncyBmb3IKKyBkZXRlY3RpbmcgYW5kIGJ1aWxkaW5nIGdldHRleHQgamF2YS4KKyBNb2Rp
ZmllZCBmcm9tIG9wZW5zdXNlIHRvIGluY2x1ZGUgc3VwcG9ydCBmb3IgMS43IGFuZCAxLjguCitP
cmlnaW46IG9wZW5zdXNlLCBodHRwczovL2J1aWxkLm9wZW5zdXNlLm9yZy9wYWNrYWdlL3ZpZXdf
ZmlsZS9vcGVuU1VTRTpGYWN0b3J5L2dldHRleHQtcnVudGltZS9nZXR0ZXh0LTAuMTkuOC4xLWpk
azkucGF0Y2gKK0J1Zy1EZWJpYW46IAorRm9yd2FyZGVkOiBubworTGFzdC1VcGRhdGU6IDIwMTgt

Bug#893736: glib2.0 FTBFS: ModuleNotFoundError: No module named 'distutils'

[Jeremy Bicha]

Control: found -1 2.54.3-2

I am uploading a fixed glib2.0 soon, but let's let the current version
migrate to Testing to not block several pieces of GNOME 3.28. The bug
is triggered by the recent python3.6 upload.

Thanks,
Jeremy Bicha

Bug#893471: Missing dependency: puppet-module-nanliu-staging

[Sebastien Badia]

owner -1 !
tags -1 + pending confirmed moreinfo
thanks

Hi Thomas,

nanliu-staging seems an un-maintained fork of the voxpupuli module

  https://github.com/nanliu/puppet-staging
  https://github.com/voxpupuli/puppet-staging

puppetlabs-mysql depends on the voxpupuli original module (puppet/staging), we
should maybe RoM the puppet-module-nanliu-staging package and introduce the
puppet-module-puppet-staging (https://forge.puppet.com/puppet/staging) one.

The only reverse dependency of puppet-module-nanliu-staging is 
puppet-module-puppetlabs-rabbitmq
and upstream has dropped nanliu-staging for puppet/archive 
https://github.com/voxpupuli/puppet-rabbitmq/blob/49f5e1fdc38cf10d92250f8a1c24ca9929df5f02/metadata.json#L66-L67
from voxpupuli too (https://forge.puppet.com/puppet/archive)

If it's okay for you, I'm preparing an ITP for 
https://github.com/voxpupuli/puppet-staging

Let me kown…

Cheers,

Sebastien, for the Debian puppet-team


signature.asc
Description: PGP signature

Bug#891803: cracklib2: diff for NMU version 2.9.2-5.1

[Karsten Merker]

Control: tags 891803 + patch
Control: tags 891803 + pending

Dear maintainer,

I've prepared an NMU for cracklib2 (versioned as 2.9.2-5.1) and
will upload it now. Attached is the nmudiff.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nru cracklib2-2.9.2/debian/changelog cracklib2-2.9.2/debian/changelog
--- cracklib2-2.9.2/debian/changelog	2017-05-27 11:41:18.0 +0200
+++ cracklib2-2.9.2/debian/changelog	2018-03-21 22:39:38.0 +0100
@@ -1,3 +1,11 @@
+cracklib2 (2.9.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove the ":native" annotation from the "cracklib-runtime "
+build-dependency. (Closes: #891803)
+
+ -- Karsten Merker   Wed, 21 Mar 2018 22:39:38 +0100
+
 cracklib2 (2.9.2-5) unstable; urgency=medium
 
   * Add Breaks: cracklib-runtime (<< 2.9.2-4) to libcrack2 to configure
diff -Nru cracklib2-2.9.2/debian/control cracklib2-2.9.2/debian/control
--- cracklib2-2.9.2/debian/control	2017-05-27 11:06:18.0 +0200
+++ cracklib2-2.9.2/debian/control	2018-03-21 22:39:20.0 +0100
@@ -8,7 +8,7 @@
automake (>= 1.10),
autotools-dev,
chrpath,
-   cracklib-runtime:native ,
+   cracklib-runtime ,
debhelper (>= 9),
docbook-utils,
docbook-xml,

Bug#893738: certbot: ssl-cert group should be able to read certs

[Jasen Betts]

Package: certbot
Version: 0.10.2-1
Severity: normal

Dear Maintainer,

debian provides a group "ssl-cert" (maybe this is part of snakeoil?)
this group should probably have read permission to the certificates 
generated by certbot.

I was installing "prayer" webmail server and it refued to start in TLS
mode using my letsencrypt cert.

This seems to fix it.

 chmod g+x/etc/letsencrypt/live/ /etc/letsencrypt/archive/
 chown :ssl-cert  /etc/letsencrypt/live/ /etc/letsencrypt/archive/

Read access on those directories is not needed (only execute is needed) 
but denying read is probably not significantly improving security, all
the hidden filenames are easy to guess.

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

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

Versions of packages certbot depends on:
ii  init-system-helpers  1.48
ii  python   2.7.13-2
ii  python-certbot   0.10.2-1

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-apache  
pn  python-certbot-doc 

-- no debconf information

Bug#882224: bs1770gain: enable dh-autoreconf

[James Cowgill]

Hi,

On 21/03/18 19:28, Petter Reinholdtsen wrote:
> [James Cowgill]
>> bs1770gain contains a build-dependency on dh-autoreconf, but since it
>> uses compat 9 and does not enable it manually, it is never used. This
>> looks like an oversight to me.
> 
> It is, but it is harder to fix than expected.  I tried to enable it by
> raising the compat level from 9 to 10, but the build fail.

You can workaround this by disabling automake's -Werror which at least
allows you to build the package. The warnings are things that would be
good to fix though.

--- a/configure.ac
+++ b/configure.ac
@@ -27,7 +27,7 @@
 # AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], 
[other-libraries])
 
 AC_INIT([bs1770gain], [0.4.11-beta-2], [pbelk...@users.sf.net], [], 
[http://bs1770gain.sourceforge.net/])
-AM_INIT_AUTOMAKE([-Wall -Werror foreign])
+AM_INIT_AUTOMAKE([-Wall foreign])
 AC_PROG_CC
 AC_PROG_RANLIB
 
James



signature.asc
Description: OpenPGP digital signature

Bug#891351: Details

[Julien Puydt]

Hi,

can you install scilab-cli to see if it works better?

Snark on #debian-science

Bug#597710: does this problem still exist

[Thorsten Alteholz]

Hi Denis,

While browsing through older bugs of apcupsd I wonder whether you still 
have this problem with a recent version of apcupsd?


Thanks!
  Thorsten

Bug#812941: does this problem still exist?

[Thorsten Alteholz]

Hi Trent,

while browsing through older bugs of apcupsd I wonder whether you still have 
the reported problem.

Do you still have problems with the uninterruptable sleep of apcupsd?

  Thorsten

Bug#893737: RM: oci-image-tool -- NBS; no longer built by src:golang-github-opencontainers-image-spec

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

oci-image-tool is no longer built by
src:golang-github-opencontainers-image-spec.

Bug#319832: Also needed to add route

[Daniel Lo Nigro]

I just encountered this same issue. In addition to the 'ugly workaround', I
also needed to explicitly add the default route otherwise my system did not
have any outbound IPv6 connectivity:

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_fd 0
bridge_maxwait 0

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319832
up ip -6 addr add 2605:6400:20:92e::1337:c0de/64 dev br0
up ip -6 route add 2605:6400:20::1/128 dev br0
up ip -6 route add default via 2605:6400:20::1

down ip -6 addr del 2605:6400:20:92e::1337:c0de/64 dev br0
down ip -6 route del default via 2605:6400:20::1
down ip -6 route del 2605:6400:20::1/128 dev br0

(in my this, 2605:6400:20:92e::1337:c0de is the server's IP while
2605:6400:20::1 is the gateway IP)

Bug#893736: glib2.0 FTBFS: ModuleNotFoundError: No module named 'distutils'

[Helmut Grohne]

Source: glib2.0
Version: 2.56.0-2
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

sbuild -d sid glib2.0 ends with:

| Making all in gio
| make[4]: Entering directory '/<>/debian/build/deb/gio'
| UNINSTALLED_GLIB_SRCDIR=../../../.. \
| UNINSTALLED_GLIB_BUILDDIR=.. \
| /usr/bin/python3 ../../../../gio/gdbus-2.0/codegen/gdbus-codegen.in \
| --interface-prefix org. \
| --generate-c-code gdbus-daemon-generated \
| --c-namespace _G \
| ../../../../gio/dbus-daemon.xml \
| 
| Traceback (most recent call last):
|   File "../../../../gio/gdbus-2.0/codegen/gdbus-codegen.in", line 53, in 

| from codegen import codegen_main
|   File "/<>/gio/gdbus-2.0/codegen/codegen_main.py", line 29, in 

| from . import dbustypes
|   File "/<>/gio/gdbus-2.0/codegen/dbustypes.py", line 22, in 

| from . import utils
|   File "/<>/gio/gdbus-2.0/codegen/utils.py", line 22, in 
| import distutils.version
| ModuleNotFoundError: No module named 'distutils'
| make[4]: *** [Makefile:5019: gdbus-daemon-generated.c] Error 1
| make[4]: Leaving directory '/<>/debian/build/deb/gio'
| make[4]: *** Waiting for unfinished jobs
| make[4]: Entering directory '/<>/debian/build/deb/gio'
| UNINSTALLED_GLIB_SRCDIR=../../../.. \
| UNINSTALLED_GLIB_BUILDDIR=.. \
| /usr/bin/python3 ../../../../gio/gdbus-2.0/codegen/gdbus-codegen.in \
| --interface-prefix org. \
| --generate-c-code gdbus-daemon-generated \
| --c-namespace _G \
| ../../../../gio/dbus-daemon.xml \
| 
| Traceback (most recent call last):
|   File "../../../../gio/gdbus-2.0/codegen/gdbus-codegen.in", line 53, in 

| from codegen import codegen_main
|   File "/<>/gio/gdbus-2.0/codegen/codegen_main.py", line 29, in 

| from . import dbustypes
|   File "/<>/gio/gdbus-2.0/codegen/dbustypes.py", line 22, in 

| from . import utils
|   File "/<>/gio/gdbus-2.0/codegen/utils.py", line 22, in 
| import distutils.version
| ModuleNotFoundError: No module named 'distutils'
| make[4]: *** [Makefile:5019: gdbus-daemon-generated.h] Error 1
| make[4]: Leaving directory '/<>/debian/build/deb/gio'
| make[3]: *** [Makefile:1279: all-recursive] Error 1
| make[2]: *** [Makefile:900: all] Error 2
| dh_auto_build: cd debian/build/deb && make -j8 -O returned exit code 2
| make[1]: *** [debian/rules:137: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:24: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Possibly some dependency is missing?

I guess this is connected to the python3.6/3.6.5~rc1-2 upload.

Helmut

Bug#862604: dh-make-elpa: extending create_docs{}

[Sean Whitton]

Hello,

On Tue, Mar 20 2018, Lev Lamberov wrote:

> Done.

Thanks.

> Do you think the bug should be closed? As I understand, this change is
> what you'd like to have compared to a more complex change with
> multiple docs files for multiple "binaries"?

Seems fine to close the bug because it is not clear what automation
would be desirable.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#893735: paraview FTBFS on armel/armhf: QVTKOpenGLWidget.cxx:458:3: error: 'QOpenGLFunctions_3_2_Core' was not declared in this scope

[Adrian Bunk]

Source: paraview
Version: 5.4.1+dfsg4-1
Severity: serious

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

...
/<>/paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx: In 
member function 'virtual void QVTKOpenGLWidget::paintGL()':
/<>/paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx:458:3:
 error: 'QOpenGLFunctions_3_2_Core' was not declared in this scope
   QOpenGLFunctions_3_2_Core* f =
   ^
/<>/paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx:458:3:
 note: suggested alternative: 'QOpenGLFunctionsPrivate'
   QOpenGLFunctions_3_2_Core* f =
   ^
   QOpenGLFunctionsPrivate
/<>/paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx:458:30:
 error: 'f' was not declared in this scope
   QOpenGLFunctions_3_2_Core* f =
  ^
/<>/paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx:459:83:
 error: no matching function for call to 
'QOpenGLContext::versionFunctions()'
 
QOpenGLContext::currentContext()->versionFunctions();

   ^
In file included from 
/usr/include/arm-linux-gnueabihf/qt5/QtGui/QOpenGLContext:1:0,
 from 
/<>/paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx:18:
/usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglcontext.h:193:11: note: 
candidate: template TYPE* QOpenGLContext::versionFunctions() const
 TYPE *versionFunctions() const
   ^~~~
/usr/include/arm-linux-gnueabihf/qt5/QtGui/qopenglcontext.h:193:11: note:   
template argument deduction/substitution failed:
VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/build.make:453: recipe for 
target 
'VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/QVTKOpenGLWidget.cxx.o' failed
make[3]: *** 
[VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/QVTKOpenGLWidget.cxx.o] Error 
1


On armel/armhf (and on arm64 in Ubuntu) Qt is compiled for OpenGL ES
instead of full OpenGL.

This is caused by:
https://gitlab.kitware.com/vtk/vtk/commit/53c566782950cd94ccd877cb906607e4cc33e1f7

The following fixes the build:

--- paraview-5.4.1+dfsg4.orig/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx
+++ paraview-5.4.1+dfsg4/VTK/GUISupport/Qt/QVTKOpenGLWidget.cxx
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+//#include 
 #include 
 #include 
 #include 
@@ -453,6 +453,7 @@ void QVTKOpenGLWidget::paintGL()
   // before proceeding with blit-ing.
   this->makeCurrent();
 
+#if 0
   // blit from this->FBO to QOpenGLWidget's FBO.
   vtkQVTKOpenGLWidgetDebugMacro("paintGL::blit-to-defaultFBO");
   QOpenGLFunctions_3_2_Core* f =
@@ -485,6 +486,7 @@ void QVTKOpenGLWidget::paintGL()
 f->glColorMask(colorMask[0], colorMask[1], colorMask[2], colorMask[3]);
 f->glClearColor(clearColor[0], clearColor[1], clearColor[2], 
clearColor[3]);
   }
+#endif  /* 0 */
 }
 
 //-


This is obviously not a patch that should be applied,
it serves only to show that it is really just a small piece
of recently added code that prevents compilation here.

If possible, this should be fixed.


In case fixing is not possible or desirable, please:
- change the build dependency from libqt5opengl5-dev
  to libqt5opengl5-desktop-dev, and
- file a removal bug for the old armel+armhf binaries
  against ftp.debian.org

Bug#893734: git-el: smooth automatic migration to elpa-magit (Re: Maintainer scripts for el file removal)

[Jonathan Nieder]

Source: git
Version: 1:2.17~rc0+next.20180315-1
Severity: wishlist
X-Debbugs-Cc: Nicholas D Steeves , 
debian-emac...@lists.debian.org

Nicholas D Steeves wrote[*]:

>  speaking for myself--if I
> wasn't already a magit user I would consider the following scenario a
> happy surprise:
>
> * dist-upgrade from stretch to buster
> * receive a NEWS item from git-el
>   - says something like: git-el is dead, long live magit ;-)
>   - NEWS also points to docs for getting up to speed with magit as
> quickly and as easily as possible.  I'm not sure that most users
> would read README.emacs as part of a dist-upgrade.  Set this to
> display for all versions of git-el since 1:2.11.0-3+deb9u2
>   - P.S. I've side-lined an old project wrt providing quickstarts and
> printable emacs cheatsheets.  Please pester me about this if you
> think it would benefit this hypothetical git-el -> magit
>   - marvel at the productivity boosts from magit

That sounds like a very nice way to go.  Filing this as a wishlist bug
so as not to forget it.

[*] https://lists.debian.org/debian-emacsen/2018/03/msg2.html

Bug#893733: freerdp2-x11: redirect of serial and smart cards does not working on current version of freerdp

[vlk]

Package: freerdp2-x11
Version: 2.0.0~git20170725.1.1648deb+dfsg1-7
Severity: important
Tags: a11y

Dear Maintainer,

I've installed testing relesae of Debian and found following issues:

issued commands - works as expected on freerdp package 1.1 (Debian stable), 
does not on backage 2.0 (current testing release):

aptitude install freerdp2-x11
xfreerdp /clipboard /u:admin /v:10.77.77.1 /smartcard:"Alcor Micro Corp. AU9540 
Smartcard Reader"
xfreerdp /clipboard /u:admin /v:10.77.77.1 /serial:COM8,/dev/ttyACM0


1. redirect of serial port accepts only one number, for example "COM10" error
Output if serial port nubmer has more than one decimal:
#xfreerdp /clipboard /u:admin /v:10.77.77.1 /serial:COM10,/dev/ttyACM0

[21:57:34:186] [3331:3332] [INFO][com.winpr.clipboard] - initialized POSIX 
local file subsystem
[21:57:34:187] [3331:3337] [INFO][com.freerdp.channels.rdpdr.client] - Loading 
device service serial [COM10] (static)
[21:57:34:187] [3331:3337] [ERROR][com.freerdp.channels.serial.client] - 
DefineCommDevice failed!
[21:57:34:187] [3331:3337] [ERROR][com.freerdp.channels.rdpdr.client] - 
devman_load_device_service failed with error 1359!
[21:57:34:188] [3331:3337] [ERROR][com.freerdp.channels.rdpdr.client] - 
rdpdr_process_connect failed with error 1359!
[21:57:34:188] [3331:3332] [ERROR][com.freerdp.core] - 
rdpdr_virtual_channel_client_thread reported an error. Error was 1359
[21:57:34:188] [3331:3332] [INFO][com.freerdp.client.x11] - Network disconnect!
[21:57:34:188] [3331:3332] [ERROR][com.freerdp.client.x11] - Failed to check 
FreeRDP file descriptor

2. redirect of serial port does not work at all
freerdp is able to start using commands above, server can see the redirected 
port, but the communicanion does not work on version 2.0

3. redirect of smartcard does not work at all
the server can not see any redirected device



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

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

Versions of packages freerdp2-x11 depends on:
ii  libc6 2.27-2
ii  libfreerdp-client2-2  2.0.0~git20170725.1.1648deb+dfsg1-7
ii  libfreerdp2-2 2.0.0~git20170725.1.1648deb+dfsg1-7
ii  libwinpr2-2   2.0.0~git20170725.1.1648deb+dfsg1-7
ii  libx11-6  2:1.6.4-3
ii  libxcursor1   1:1.1.15-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrender1   1:0.9.10-1
ii  libxv12:1.0.11-1

freerdp2-x11 recommends no packages.

freerdp2-x11 suggests no packages.

-- no debconf information

Bug#893732: ITP: feersum -- PSGI engine for Perl based on EV/libev

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: feersum
  Version : 1.405
  Upstream Author : Jeremy Stashewsky 
* URL : https://metacpan.org/release/Feersum
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PSGI engine for Perl based on EV/libev

Feersum is an HTTP server built on EV. It fully supports the PSGI 1.03 spec
including the psgi.streaming interface and is compatible with Plack and PSGI
1.1. Feersum also has its own "native" interface which is similar in a lot of
ways to PSGI, but is not compatible with PSGI or PSGI middleware.

Feersum uses a single-threaded, event-based programming architecture to scale
and can handle many concurrent connections efficiently in both CPU and RAM. It
skips doing a lot of sanity checking with the assumption that a "front-end"
HTTP/HTTPS server is placed between it and the Internet.

Bug#879496: 1.4.49

[Clint Adams]

Control: retitle -1 New upstream release 1.4.49 available

http://www.lighttpd.net/2018/3/11/1.4.49/

Bug#893729: sympy FTBFS: python3-distutils is now a separate package

[Rebecca N. Palmer]

Given that the errors suggest it tried and failed to find both 
setuptools and distutils, it probably already can use either (though I 
haven't tried to check this), if they are installed...


On 21/03/18 20:30, Ghislain Vaillant wrote:

Another option could be to patch the build system to use setuptools instead
of distutils as recommended by the PyPA?

Le mer. 21 mars 2018 à 20:45, Rebecca N. Palmer  a
écrit :


Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-pyt...@lists.debian.org

python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
so if you need it, please build-depend on it.  (Or python3-setuptools,
given that this looks like it might prefer that.)

(Has anyone checked whether there are more of these?)

dpkg-buildpackage: info: source package sympy
dpkg-buildpackage: info: source version 1.1.1-4
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Yaroslav Halchenko

dpkg-buildpackage: info: host architecture amd64
   dpkg-source --before-build sympy-1.1.1
   fakeroot debian/rules clean
dh  clean --with python2,python3 --buildsystem=pybuild
 debian/rules override_dh_auto_clean
make[1]: Entering directory
'/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
dh_auto_clean
I: pybuild base:217: python2.7 setup.py clean
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'install_requires'
warnings.warn(msg)
running clean
I: pybuild base:217: python3.6 setup.py clean
Traceback (most recent call last):
File "setup.py", line 46, in 
  from setuptools import setup, Command
ModuleNotFoundError: No module named 'setuptools'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "setup.py", line 49, in 
  from distutils.core import setup, Command
ModuleNotFoundError: No module named 'distutils'
E: pybuild pybuild:330: clean: plugin distutils failed with: exit
code=1: python3.6 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit
code 13
make[1]: *** [debian/rules:29: override_dh_auto_clean] Error 25
make[1]: Leaving directory
'/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
make: *** [debian/rules:10: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
returned exit status 2

Bug#893731: [piuparts] Please add docker support

[Agustin Henze]

Package: piuparts
Version: 0.84
Severity: normal
Tags: patch

I have written a patch for adding docker support on piuparts. A new option is
introduced `--docker-image` e.g.

$ piuparts --docker-image debian:unstable package.deb

Honestly I didn't do too much testing on this, I just have tried using the new
feature of course and I have tried using schroot to check it's not breaking
something. I am willing to help you if you need/want to do extra testing on 
this.
The patch attached is made against origin/master.

Cheers,

-- 
TiN
diff --git a/piuparts.py b/piuparts.py
index 3daba797..a13bd9fc 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -47,6 +47,7 @@ import os
 import tarfile
 import stat
 import re
+import json
 import pickle
 import subprocess
 import traceback
@@ -191,6 +192,7 @@ class Settings:
 self.skip_minimize = True
 self.minimize = False
 self.debfoster_options = None
+self.docker_image = None
 # tests and checks
 self.no_install_purge_test = False
 self.no_upgrade_test = False
@@ -769,7 +771,7 @@ class Chroot:
 def create(self, temp_tgz=None):
 """Create a chroot according to user's wishes."""
 self.panic_handler_id = do_on_panic(self.remove)
-if not settings.schroot:
+if not settings.schroot and not settings.docker_image:
 self.create_temp_dir()
 
 if temp_tgz:
@@ -782,10 +784,12 @@ class Chroot:
 self.setup_from_dir(settings.existing_chroot)
 elif settings.schroot:
 self.setup_from_schroot(settings.schroot)
+elif settings.docker_image:
+self.setup_from_docker(settings.docker_image)
 else:
 self.setup_minimal_chroot()
 
-if not settings.schroot:
+if not settings.schroot and not settings.docker_image:
 self.mount_proc()
 self.configure_chroot()
 
@@ -807,7 +811,7 @@ class Chroot:
 self.run_scripts("post_chroot_unpack")
 
 self.run(["apt-get", "update"])
-if settings.basetgz or settings.schroot or settings.existing_chroot:
+if settings.basetgz or settings.docker_image or settings.schroot or settings.existing_chroot:
 self.run(["apt-get", "-yf", "dist-upgrade"])
 self.minimize()
 self.remember_available_md5()
@@ -832,7 +836,10 @@ class Chroot:
 if settings.schroot:
 logging.debug("Terminate schroot session '%s'" % self.name)
 run(['schroot', '--end-session', '--chroot', "session:" + self.schroot_session])
-if not settings.schroot:
+if settings.docker_image:
+logging.debug("Destroy docker container '%s'" % self.docker_container)
+run(['docker', 'rm', '-f', self.docker_container])
+if not settings.schroot and not settings.docker_image:
 run(['rm', '-rf', '--one-file-system', self.name])
 if os.path.exists(self.name):
 create_file(os.path.join(self.name, ".piuparts.tmpdir"), "removal failed")
@@ -840,6 +847,8 @@ class Chroot:
 elif settings.keep_tmpdir:
 if settings.schroot:
 logging.debug("Keeping schroot session %s at %s" % (self.schroot_session, self.name))
+elif settings.docker_image:
+logging.debug("Keeping container %s" % self.docker_container)
 else:
 logging.debug("Keeping directory tree at %s" % self.name)
 dont_do_on_panic(self.panic_handler_id)
@@ -892,6 +901,25 @@ class Chroot:
 self.name = output.strip()
 logging.info("New schroot session in '%s'" % self.name)
 
+@staticmethod
+def check_if_docker_storage_driver_is_supported():
+ret_code, output = run(['docker', 'info'])
+if 'overlay2' not in output:
+logging.error('Only overlay2 storage driver is supported')
+panic()
+
+def setup_from_docker(self, docker_image):
+self.check_if_docker_storage_driver_is_supported()
+ret_code, output = run(['docker', 'run', '-d', '-it', docker_image, 'bash'])
+if ret_code != 0:
+logging.error("Couldn't start the container from '%s'" % docker_image)
+panic()
+self.docker_container = output.strip()
+ret_code, output = run(['docker', 'inspect', self.docker_container])
+container_data = json.loads(output)[0]
+self.name = container_data['GraphDriver']['Data']['MergedDir']
+logging.info("New container created '%s'" % self.docker_container)
+
 def setup_from_lvm(self, lvm_volume):
 """Create a chroot by creating an LVM snapshot."""
 self.lvm_base = os.path.dirname(lvm_volume)
@@ -938,6 +966,12 @@ class Chroot:
 ["schroot", "--preserve-environment", "--run-session", "--chroot", "session:" +
 self.schroot_session, "--directory", "/", "-u", "root", "--"] + prefix + 

Bug#893729: sympy FTBFS: python3-distutils is now a separate package

[Ghislain Vaillant]

Another option could be to patch the build system to use setuptools instead
of distutils as recommended by the PyPA?

Le mer. 21 mars 2018 à 20:45, Rebecca N. Palmer  a
écrit :

> Source: sympy
> Severity: serious
> Control: tags -1 patch
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
> so if you need it, please build-depend on it.  (Or python3-setuptools,
> given that this looks like it might prefer that.)
>
> (Has anyone checked whether there are more of these?)
>
> dpkg-buildpackage: info: source package sympy
> dpkg-buildpackage: info: source version 1.1.1-4
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Yaroslav Halchenko
> 
> dpkg-buildpackage: info: host architecture amd64
>   dpkg-source --before-build sympy-1.1.1
>   fakeroot debian/rules clean
> dh  clean --with python2,python3 --buildsystem=pybuild
> debian/rules override_dh_auto_clean
> make[1]: Entering directory
> '/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
> dh_auto_clean
> I: pybuild base:217: python2.7 setup.py clean
> /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
> distribution option: 'install_requires'
>warnings.warn(msg)
> running clean
> I: pybuild base:217: python3.6 setup.py clean
> Traceback (most recent call last):
>File "setup.py", line 46, in 
>  from setuptools import setup, Command
> ModuleNotFoundError: No module named 'setuptools'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "setup.py", line 49, in 
>  from distutils.core import setup, Command
> ModuleNotFoundError: No module named 'distutils'
> E: pybuild pybuild:330: clean: plugin distutils failed with: exit
> code=1: python3.6 setup.py clean
> dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit
> code 13
> make[1]: *** [debian/rules:29: override_dh_auto_clean] Error 25
> make[1]: Leaving directory
> '/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
> make: *** [debian/rules:10: clean] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
> returned exit status 2
>
>

Bug#893730: Missing dependency?

[Jack Lloyd]

On Wed, Mar 21, 2018 at 09:13:55PM +0100, VA wrote:
> Package: python3-botan
> Version: 2.4.0-3
> 
> After installing Python bindings for botan, it seems some dependency is
> missing (or not installable):
> 
> >>> import botan2
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/botan2.py", line 39, in 
> botan = CDLL('libbotan-2.so') # pylint: disable=invalid-name
>   File "/usr/lib/python3.6/ctypes/__init__.py", line 348, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: libbotan-2.so: cannot open shared object file: No such file or
> directory

The libbotan-2.so symlink is shipped seperately (in libbotan-2-dev
package), which the Python module does not expect.

This has already been fixed upstream as it was found to affect Fedora also
https://github.com/randombit/botan/issues/1497

Bug#892201: nlohmann-json build issues with gcc 7.2

[Hubert Chathi]

On Wed, 7 Mar 2018 11:50:31 +0100, Muri Nicanor  said:

> Hi Dominique, uhoreg offered to package version 3
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885540) of
> nlohmann-json and already created an ITP for that:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886865

It may be worth backporting the fix to the 2.x branch, since the 3.x
package will be a separate package, so even after the 3.x package is
released, the bug will still be present in the 2.x package.

But it may also be worth looking into whether the issue is still present
when compiling with gcc 7.3, as it may have just been a bug in gcc 7.2.

> cheers, muri

> On 03/06/2018 05:36 PM, Dominique Belhachemi wrote:
>> Package: nlohmann-json Version: 2.1.1-1 Severity: grave
>> 
>> Some applications don't compile with nlohmann-json 2.1.1 and gcc 7.2
>> .
>> 
>> You can find details here:
>> 
>> https://github.com/nlohmann/json/issues/742
>> 
>> Please update the package.
>> 
>> Thanks -Dominique
>> 

Bug#883286: Please ship a python3-gps package

[Bernd Zeimetz]

Hi,


On 03/20/2018 12:05 PM, Paride Legovini wrote:
> On Fri, 1 Dec 2017 13:03:05 -0600 Richard Laager  wrote:
>> Please consider shipping a python3-gps package, either in addition to or
>> instead of python-gps. I don't know how much work that will be, so I
>> understand that it might be a while.
> 
> The Python code in gpsd is compatible with both Python2 and Python3,
> as stated in the header of the Python files:
> 
> # This code runs compatibly under Python 2 and 3.x for x >= 2.
> 
> I believe a python3-gps package will be almost identical to python-gps.

thats all true, but the SConstruct file in 3.17 just does not work with
python3. I could create a hand hacked package, but I'm not keen on doing
that.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

I could somehow udate the symbols list, but still get a lintian warning
[1]. I have pushed my commits, would you mind giving them a look? Will
proceed with other libs once I have confirmation that everything is ok.

Best,

Julien.

[1]
https://lintian.debian.org/tags/symbols-declares-dependency-on-other-package.html

On Wed, Mar 21, 2018 at 6:15 PM, Andreas Tille  wrote:

> Hi Julien,
>
> On Wed, Mar 21, 2018 at 05:25:10PM +0100, Julien Yann Dutheil wrote:
> > I'm starting to package libbpp-core4 from upstream. It works fine but I
> > have a warning because of the symbol files which are not matching. My
> > understanding is that this is due to your previous (unreleased) patch
> which
> > was incrementing the interface number for version 2.3.2. How can I solve
> > that? (basically, discard the previous symbols and use the new one
> instead,
> > as they correspond to the new "official" .so.4 version?).
>
> The build log contains a diff you can use as patch.
>
> > I have not pushed
> > my commits yet, let me know if you need them already.
>
> Feel free to push and ping me in case of trouble so I can fix it.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#893730: Missing dependency?

[VA]

Package: python3-botan
Version: 2.4.0-3

After installing Python bindings for botan, it seems some dependency is 
missing (or not installable):


>>> import botan2
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/botan2.py", line 39, in 
botan = CDLL('libbotan-2.so') # pylint: disable=invalid-name
  File "/usr/lib/python3.6/ctypes/__init__.py", line 348, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libbotan-2.so: cannot open shared object file: No such file or 
directory

Bug#887925: tkdnd uses deprecated Tcl/Tk 8.5

[Sergei Golovan]

Hi Hans-Christoph,

On Wed, Mar 21, 2018 at 6:16 PM, Hans-Christoph Steiner  wrote:
>
> Please take over the maintenance of this from me!

Sorry, I wouldn't like to do that.

> Or at the very least,
> NMU whenever you need to.

Okay, I'll do NMU shortly.

Cheers!
-- 
Sergei Golovan

Bug#893563: whiptail has priority important

[Sven Joachim]

On 2018-03-19 22:34 +0100, Christian Göttsche wrote:

> Package: whiptail
> Version: 0.52.20-3
> Severity: wishlist
>
> Could you consider lowering the priority of whiptail from important to 
> standard?

This has been done in the latest upload, but

a) Priorities are set by the FTP masters, so the change has no effect.
b) It does not look quite correct to me.

> Packages using whiptail should depend on it and the change would help
> keeping minimal systems clean.

The problem is that debconf uses whiptail as its default frontend, but
does _not_ depend on it, so that it does not need to be installed in
build chroots which normally use the "noninteractive" debconf frontend.

For a usable debconf, you really need whiptail or dialog (or one of the
graphical frontends, but those have many additional dependencies and
require X).  See debconf(7).

Cheers,
   Sven

Bug#893659: Please add Python 3 support

[Bernd Zeimetz]

Hi,

the package is in collab-maint - instead of NMUing it just do the
appropriate work and upload it.

But please do proper commits. No all-in-one commit.

What you are suggesting here for a NMU violates the most important rule
for NMUs: no unnecessary changes. It is almost impossible to review that
patch.


Bernd

On 03/20/2018 11:58 PM, Thomas Goirand wrote:
> Package: python-ethtool
> Severity: important
> Tags: patch
> 
> Hi,
> 
> Please add support for Python 3 in this package. I have attached a patch to do
> exactly that. If you don't have time, please allow me to NMU.
> 
> Note that the patch was made against the Git in Alioth, though it doesn't take
> into account the NMU version currently in Sid. So it would have to be fixed
> for that.
> 
> Last, this is important for me, because I've switched all of OpenStack to
> Python 3, and this is on my way to finish the work (and this would fix the
> RC bug: #892882).
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#893729: sympy FTBFS: python3-distutils is now a separate package

[Rebecca N. Palmer]

Source: sympy
Severity: serious
Control: tags -1 patch
X-Debbugs-Cc: debian-pyt...@lists.debian.org

python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2), 
so if you need it, please build-depend on it.  (Or python3-setuptools, 
given that this looks like it might prefer that.)


(Has anyone checked whether there are more of these?)

dpkg-buildpackage: info: source package sympy
dpkg-buildpackage: info: source version 1.1.1-4
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Yaroslav Halchenko 


dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build sympy-1.1.1
 fakeroot debian/rules clean
dh  clean --with python2,python3 --buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'

dh_auto_clean
I: pybuild base:217: python2.7 setup.py clean
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown 
distribution option: 'install_requires'

  warnings.warn(msg)
running clean
I: pybuild base:217: python3.6 setup.py clean
Traceback (most recent call last):
  File "setup.py", line 46, in 
from setuptools import setup, Command
ModuleNotFoundError: No module named 'setuptools'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "setup.py", line 49, in 
from distutils.core import setup, Command
ModuleNotFoundError: No module named 'distutils'
E: pybuild pybuild:330: clean: plugin distutils failed with: exit 
code=1: python3.6 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit 
code 13

make[1]: *** [debian/rules:29: override_dh_auto_clean] Error 25
make[1]: Leaving directory 
'/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'

make: *** [debian/rules:10: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess 
returned exit status 2

Bug#836368: ITA: pev -- text-based tool to analyze PE files

[Petter Reinholdtsen]

[Robert Haist]
> As I plan to use pev for $dayjob I would like to adopt the pev package.

Sound good.  Do you have a time frame for this, and do you need any help
getting started?

-- 
Happy hacking
Petter Reinholdtsen

Bug#882224: bs1770gain: enable dh-autoreconf

[Petter Reinholdtsen]

[James Cowgill]
> bs1770gain contains a build-dependency on dh-autoreconf, but since it
> uses compat 9 and does not enable it manually, it is never used. This
> looks like an oversight to me.

It is, but it is harder to fix than expected.  I tried to enable it by
raising the compat level from 9 to 10, but the build fail.

I used this change:

diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index 02d1b6c..b113e5d 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: sound
 Priority: optional
 Maintainer: Debian Multimedia Team 

 Uploaders: Petter Reinholdtsen 
-Build-depends: debhelper (>> 9)
+Build-depends: debhelper (>> 10~)
  , dh-autoreconf
  , libsox-dev
  , libavformat-dev (>= 7:2.7.0)

This is the failure I got:

   dh_autoreconf
automake: warnings are treated as errors
bs1770gain/Makefile.am:97: warning: call SOLIB,,avutil,$(FFSOX_AVUTIL_V: 
non-POSIX variable name
bs1770gain/Makefile.am:97: (probably a GNU make extension)
bs1770gain/Makefile.am:98: warning: call 
SOLIB,,swresample,$(FFSOX_SWRESAMPLE_V: non-POSIX variable name
bs1770gain/Makefile.am:98: (probably a GNU make extension)
bs1770gain/Makefile.am:99: warning: call SOLIB,,avcodec,$(FFSOX_AVCODEC_V: 
non-POSIX variable name
bs1770gain/Makefile.am:99: (probably a GNU make extension)
bs1770gain/Makefile.am:100: warning: call SOLIB,,avformat,$(FFSOX_AVFORMAT_V: 
non-POSIX variable name
bs1770gain/Makefile.am:100: (probably a GNU make extension)
bs1770gain/Makefile.am:101: warning: call SOLIB,lib,sox,$(FFSOX_LIBSOX_V: 
non-POSIX variable name
bs1770gain/Makefile.am:101: (probably a GNU make extension)
bs1770gain/Makefile.am:104: warning: call SOLIB,,avutil,$(FFSOX_AVUTIL_V: 
non-POSIX variable name
bs1770gain/Makefile.am:104: (probably a GNU make extension)
bs1770gain/Makefile.am:105: warning: call 
SOLIB,,swresample,$(FFSOX_SWRESAMPLE_V: non-POSIX variable name
bs1770gain/Makefile.am:105: (probably a GNU make extension)
bs1770gain/Makefile.am:106: warning: call SOLIB,,avcodec,$(FFSOX_AVCODEC_V: 
non-POSIX variable name
bs1770gain/Makefile.am:106: (probably a GNU make extension)
bs1770gain/Makefile.am:107: warning: call SOLIB,,avformat,$(FFSOX_AVFORMAT_V: 
non-POSIX variable name
bs1770gain/Makefile.am:107: (probably a GNU make extension)
bs1770gain/Makefile.am:108: warning: call SOLIB,lib,sox,$(FFSOX_LIBSOX_V: 
non-POSIX variable name
bs1770gain/Makefile.am:108: (probably a GNU make extension)
bs1770gain/Makefile.am:112: warning: call SOLIB,lib,sox,$(FFSOX_LIBSOX_V: 
non-POSIX variable name
bs1770gain/Makefile.am:112: (probably a GNU make extension)
bs1770gain/Makefile.am:113: warning: call SOLIB,,avformat,$(FFSOX_AVFORMAT_V: 
non-POSIX variable name
bs1770gain/Makefile.am:113: (probably a GNU make extension)
bs1770gain/Makefile.am:114: warning: call SOLIB,,avcodec,$(FFSOX_AVCODEC_V: 
non-POSIX variable name
bs1770gain/Makefile.am:114: (probably a GNU make extension)
bs1770gain/Makefile.am:115: warning: call 
SOLIB,,swresample,$(FFSOX_SWRESAMPLE_V: non-POSIX variable name
bs1770gain/Makefile.am:115: (probably a GNU make extension)
bs1770gain/Makefile.am:116: warning: call SOLIB,,avutil,$(FFSOX_AVUTIL_V: 
non-POSIX variable name
bs1770gain/Makefile.am:116: (probably a GNU make extension)
bs1770gain/Makefile.am:118: warning: '%'-style pattern rules are a GNU make 
extension
bs1770gain/Makefile.am:121: warning: '%'-style pattern rules are a GNU make 
extension
bs1770gain/Makefile.am:124: warning: '%'-style pattern rules are a GNU make 
extension
/usr/share/automake-1.15/am/library.am: warning: 'libbs1770gain.a': linking 
libraries using a non-POSIX
/usr/share/automake-1.15/am/library.am: archiver requires 'AM_PROG_AR' in 
'configure.ac'
bs1770gain/Makefile.am:65:   while processing library 'libbs1770gain.a'
bs1770gain/Makefile.am:1: warning: 'CFLAGS' is a user variable, you should not 
override it;
bs1770gain/Makefile.am:1: use 'AM_CFLAGS' instead
bs1770gain/Makefile.am:16: warning: 'CPPFLAGS' is a user variable, you should 
not override it;
bs1770gain/Makefile.am:16: use 'AM_CPPFLAGS' instead
bs1770gain/Makefile.am:25: warning: 'LDFLAGS' is a user variable, you should 
not override it;
bs1770gain/Makefile.am:25: use 'AM_LDFLAGS' instead
/usr/share/automake-1.15/am/library.am: warning: 'lib1770_2.a': linking 
libraries using a non-POSIX
/usr/share/automake-1.15/am/library.am: archiver requires 'AM_PROG_AR' in 
'configure.ac'
lib1770-2/Makefile.am:24:   while processing library 'lib1770_2.a'
lib1770-2/Makefile.am:1: warning: 'CFLAGS' is a user variable, you should not 
override it;
lib1770-2/Makefile.am:1: use 'AM_CFLAGS' instead
lib1770-2/Makefile.am:13: warning: 'CPPFLAGS' is a user variable, you should 
not override it;
lib1770-2/Makefile.am:13: use 'AM_CPPFLAGS' instead
/usr/share/automake-1.15/am/library.am: warning: 

Bug#893728: [python3-zmq] spyder3 fails to initialize the kernel with the current version of python3-zmq

[Bob]

Package: python3-zmq
Version: 16.0.2-2+b1
Severity: normal

Spyder3 fails to initialize the kernel. Updating python3-zmq to 17.0.0 
through pip3 solves the problem.


Temporary solution:

pip3 install --user pyzmq



--- System information. ---
Architecture:
Kernel: Linux 4.15.0-11.1-liquorix-amd64

Debian Release: buster/sid
500 testing ftp.nl.debian.org
500 data neurodebian.ovgu.de
500 buster neurodebian.ovgu.de


--- Package information. ---
Depends (Version) | Installed
=-+-==
python3 (<< 3.7) | 3.6.4-1
python3 (>= 3.5~) | 3.6.4-1
python3:any (>= 3.3.2-2~) |
libc6 (>= 2.14) |
libzmq5 (>= 4.1.2) |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#893727: [python-zmq] spyder fails to initialize the kernel with the current version of python-zmq

[Bob]

Package: python-zmq
Version: 16.0.2-2+b1
Severity: normal

Spyder fails to initialize the kernel. Updating python-zmq to 17.0.0 
through pip solves the problem.


Temporary solution:

pip install --user pyzmq


--- System information. ---
Architecture:
Kernel: Linux 4.15.0-11.1-liquorix-amd64

Debian Release: buster/sid
500 xenial ppa.launchpad.net
500 testing ftp.nl.debian.org
500 stable dl.google.com
500 data neurodebian.ovgu.de
500 buster neurodebian.ovgu.de
500 bionic ppa.launchpad.net

--- Package information. ---
Depends (Version) | Installed
-+-==
python (<< 2.8) | 2.7.14-4
python (>= 2.7~) | 2.7.14-4
python:any (<< 2.8) |
python:any (>= 2.7.5-5~) |
libc6 (>= 2.14) |
libzmq5 (>= 4.1.2) |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#609009: apcupsd: please add logcheck rules to the packages

[Thorsten Alteholz]

Hi Radek,

while browsing through the old bug reports of apcupsd, I wonder whether 
you already created a file that you want to share?


Thanks!
 Thorsten

Bug#884425: apcupsd start immediately after apt install

[Thorsten Alteholz]

Hi,

I am not sure that the startup behaviour of the daemon should depend on 
the maintainer scripts executed during installation.


Wouldn't it be better to let the admin decide and configure it? In this 
case something like:


 # echo -e '#!/bin/bash\nexit 101' > /usr/sbin/policy-rc.d
 # chmod +x /usr/sbin/policy-rc.d
 # /usr/sbin/policy-rc.d
 # echo $?
 101

should do the trick.
If you want different daemons to have a different startup behaviour, you 
could evaluate the first parameter of policy-rc.d as described in [1].


  Thorsten

[1] https://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt

Bug#880771: Fwd: Re: Cross-compiling libdwarf

[Helmut Grohne]

On Wed, Mar 21, 2018 at 08:42:45AM -0700, David Anderson wrote:
> That embedding a copy of
> 
> ax_cc_for_build.m4
> 
> in one's release is considered an appropriate thing to do is
> quite a surprise to me.   Even shocking.

This is quite difficult for me. Personally, I very much think that such
embedded code copies are a bad thing and should go away. When packaging
a software it is often a good idea to simply wipe such copies, because
they are always outdated and tend to contain fixed bugs. Numerous times,
I've filed bugs saying "please update your embedded copy, because it has
bugs that are fixed upstream".

Yet, that's exactly what autoconf upstream recommends. There even is a
tool(!) for managing these embedded copies: aclocal. It creates an
aclocal.m4 by copying macros from other sources (e.g. autoconf-archive)
into aclocal.m4, which is supposed to be part of a source code release.
See e.g. https://autotools.io/autoconf/macros.html

> [And what about libelf?  Include it too because
> it is not available automatically to all?
> Where to stop embedding?]

If you ask me, don't embed. Just don't do it. Also don't ship compiled
code (e.g. generated configure scripts). But that's just me.

So now you essentially have a choice of:
 * Depend on autoconf-archive.
 * Embed the damn macro.
 * Use AC_PATH_PROG([CC_FOR_BUILD],[cc]) as a simple substitute.
 * Ignore cross building.

There is no silver bullet.

Helmut

Bug#893442: lynkeos.app: FTBFS on ppc64el: AltiVec argument passed to unprototyped function

[Frédéric Bonnard]

Hi Yavor,
thanks for already digging into this issue.
I'm not an altivec expert but I was interested to look into this and
maybe help.

On Sun, 18 Mar 2018 22:33:16 +0200, Yavor Doganov  wrote:
> Source: lynkeos.app
> Version: 2.10+dfsg1-2
> Severity: serious
> Tags: patch
> User: debian-powe...@lists.debian.org
> Usertags: ppc64el
> 
> I would appreciate if someone knowledgeable from -powerpc confirms
> that the attached patch is correct.  The build failure is:
> 
> gcc /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m 
> -c \
>   -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -I. -I.. 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep.. 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep/../ThreadConnectionSources 
> -I/<>/lynkeos.app-2.10+dfsg1/GNUstep/../ThirdPartySources/SMDoubleSlider
>  -DNO_FRAMEWORK_CHECK=1 -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 
> -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 
> -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS 
> -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -g -O2 
> -fdebug-prefix-map=/<>/lynkeos.app-2.10+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fgnu-runtime 
> -Wno-unknown-pragmas -Wno-cpp -fconstant-string-class=NSConstantString -I. 
> -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
>-o obj/Lynkeos.obj/MyDeconvolution.m.o
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m: In 
> function 'vector_Process_One_line':
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:72:44:
>  warning: excess elements in vector initializer
> 0x04050607, 0x04050607 };
> ^~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:72:44:
>  note: (near initialization for 'Vperma')
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:72:56:
>  warning: excess elements in vector initializer
> 0x04050607, 0x04050607 };
> ^~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:72:56:
>  note: (near initialization for 'Vperma')
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:74:44:
>  warning: excess elements in vector initializer
> 0x0C0D0E0F, 0x0C0D0E0F };
> ^~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:74:44:
>  note: (near initialization for 'Vpermb')
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:74:56:
>  warning: excess elements in vector initializer
> 0x0C0D0E0F, 0x0C0D0E0F };
> ^~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:74:56:
>  note: (near initialization for 'Vpermb')
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:88:13:
>  warning: implicit declaration of function 'vec_madd' 
> [-Wimplicit-function-declaration]
>Vdx = vec_madd( vec_ld(0,expXptr), Vdy, Vzero );
>  ^~~~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:88:23:
>  warning: implicit declaration of function 'vec_ld'; did you mean 'vector'? 
> [-Wimplicit-function-declaration]
>Vdx = vec_madd( vec_ld(0,expXptr), Vdy, Vzero );
>^~
>vector
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:88:7:
>  error: AltiVec argument passed to unprototyped function
>Vdx = vec_madd( vec_ld(0,expXptr), Vdy, Vzero );
>^~~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:89:41:
>  warning: implicit declaration of function 'vec_cmplt' 
> [-Wimplicit-function-declaration]
>const __vector __bool int Vmask = vec_cmplt(Vdx,Vthr);
>  ^
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:89:7:
>  error: AltiVec argument passed to unprototyped function
>const __vector __bool int Vmask = vec_cmplt(Vdx,Vthr);
>^
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:90:27:
>  warning: implicit declaration of function 'vec_and'; did you mean 'vscanf'? 
> [-Wimplicit-function-declaration]
>__vector REAL Vge = vec_and(Vdx,Vmask);
>^~~
>vscanf
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:90:7:
>  error: AltiVec argument passed to unprototyped function
>__vector REAL Vge = vec_and(Vdx,Vmask);
>^~~~
> /<>/lynkeos.app-2.10+dfsg1/GNUstep/../Sources/MyDeconvolution.m:91:27:
>  warning: implicit declaration of function 'vec_andc'; did you mean 'vscanf'? 
> 

Bug#892707: ufraw: Depends on gconf

[Hubert Chathi]

On Mon, 12 Mar 2018 01:26:33 -0400, Jeremy Bicha  said:

> Your package depends or build-depends on gconf, but gconf will be
> removed from Debian soon.

Thanks for the report.  The gconf dependency was removed previously, but
seems to have crept back in somehow.  I'll look into why it came back
again.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#893622: deepin-movie-reborn: Fails to build

[Adrian Bunk]

Control: retitle -1 deepin-movie-reborn: Fails to build on !amd64
Control: severity -1 important

On Tue, Mar 20, 2018 at 11:37:32AM -0400, Jeremy Bicha wrote:
> Source: deepin-movie-reborn
> Version: 3.2.3-1
> Severity: serious
> 
> deepin-movie-reborn fails to build from source:
> 
> https://buildd.debian.org/status/package.php?p=deepin-movie-reborn

Builds on amd64, so technically not RC:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/deepin-movie-reborn.html

> Thanks,
> Jeremy Bicha

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#891665: normal for you, grave for me.

[積丹尼 Dan Jacobson]

Normal for you, grave for me.

Bug#893608: sbuild: Silent arch:all defaults change breaks buildd setups

[Michael Stapelberg]

control: tags -1 + pending

Hi James,

James Clarke  writes:
> In the latest upload, #870263 was fixed (which I support, for what it's worth;
> any+all builds is the right default for users), meaning that buildd setups now
> build arch:all packages, which we *have* to work around by setting
> $build_arch_all=0 in sbuild.conf. Without this, uploads are rejected by the
> archive (the buildd's signing key does not have upload rights for arch:all
> packages, the arch:all packages already exist, etc). This is therefore a
> breaking change, and so deserves at least a mention in the NEWS file. 
> Moreover,
> having to configure this in sbuild.conf is sub-optimal; ideally, buildd would
> pass --no-arch-all to sbuild when an arch:any build is requested by 
> wanna-build;
> as far as I know, the assumption is always that a non-Architecture:all build 
> is
> arch:any.

Addressed by the following commit IIUC:
https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=821144b5ef48bb11bf98657349ba808c25452721

> We probably also don't want lintian run during buildd builds as it fork-bombs 
> on
> packages like gcc-8-cross-ports (#890873), and there's lintian.debian.org 
> doing
> that for x86, which is probably good enough, though I suppose in an ideal 
> world
> it would be run too.

https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?id=e8da1ee764d8b3b5aaa0fe82aac8e877f1cc4f4d

-- 
Best regards,
Michael

Bug#845297: Bug #845297: Website transition from CVS to Git

[Laura Arjona Reina]

Hello

I have updated the "git cvsimport" conversion:

https://anonscm.debian.org/cgit/webwml/webwml2git.git/

and uploaded a copy of that repo to my personal area in Salsa:

https://salsa.debian.org/larjona/webwml

Then, I've run the other script, cvs2git, including the file with author data,
and uploaded to my personal area in Salsa too:

https://salsa.debian.org/larjona/webwml_cvs2git

I have some questions:
1.- would the cvs2git script allow incremental updates? in case "yes", wouldn't
make more sense to avoid the extra commits related to the conversion? I'm
talking about these lines in the script:

git add .
git commit -m 'Add CVS to git conversion tool'
git revert --no-commit @
git commit -m 'Remove CVS to git conversion tool, done'

(or maybe comment them meanwhile we're just testing things, and add them when we
do the actual migration).

2.- Does anybody prefer that I upload this repo to
https://anonscm.debian.org/cgit/webwml too?

3.- Which are the next steps? (I guess attack the Perl scripts, or find a way of
facilitating translators the work to keep translations in sync with the
"english" folder). About this, I have some new ideas (not sure if they are good
or silly. Just throwing them here for the case it rings a bell for anybody):

* Maybe Gitlab CI can help to "generate a translator dashboard" in a simpler way
than the scripts that currently create the pages of the type:
https://www.debian.org/devel/website/stats/es

* I'll try to explore the integration with a Weblate instance. I think that
Weblate does not handle wml files, but maybe I can cheat it to make it think
that the files are HTML files, maybe we can make it handle the work of handling
sync/outdated translations from the git commits, automatically. Even if people
don't use weblate to translate properly, the dashboard can be useful. That's
plan Z for me, because weblate is not packaged in Debian, but maybe we can use
hosted.weblate.org temporarily meanwhile a better solution is found.

That's all from my side, for now!
Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#893712: [pkg-lxqt-devel] Bug#893712: libfm-qt: please use arch-bits=32/arch-bits=64 in symbol files

[Alf Gaida]

Why do you think that would be helpful? And which new architectures?

Sorry, but the symbols right now are more or less fine and a pain in the
arse to maintain - using arch bits will not change anything beside
introducing two new classes of symbols imho.

Bug#890400: Any news about a new upstream version with new SONAME?

[Andreas Tille]

Hi Julien,

On Wed, Mar 21, 2018 at 05:25:10PM +0100, Julien Yann Dutheil wrote:
> I'm starting to package libbpp-core4 from upstream. It works fine but I
> have a warning because of the symbol files which are not matching. My
> understanding is that this is due to your previous (unreleased) patch which
> was incrementing the interface number for version 2.3.2. How can I solve
> that? (basically, discard the previous symbols and use the new one instead,
> as they correspond to the new "official" .so.4 version?).

The build log contains a diff you can use as patch.

> I have not pushed
> my commits yet, let me know if you need them already.

Feel free to push and ping me in case of trouble so I can fix it.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#888077: RFA: diamond – smart data producer for Graphite graphing package

[Luca Boccassi]

On Wed, 2018-03-21 at 16:56 +, David Stapleton wrote:
> Hi Sandro,
> 
> I've been using diamond internally for a while now and have a good
> understanding of how it hangs together. I've also been making
> contributions
> to the code on the Github project.
> 
> Also, as far as I can see, a Subversion source repository is being
> used,
> but I believe this will have to be converted to git very soon as
> Alioth is
> being deprecated (based on details at
> https://wiki.debian.org/Alioth#Deprecation_of_Alioth). This is
> something
> that I'm interested in doing.
> 
> So in summary, I'd be happy to adopt this package.
> 
> I should also mention that bl...@debian.org is willing to sponsor the
> uploads.
> 
> If there are any further details you need from me, let me know.
> 
> Thanks,
> David

I work with David, I'd be happy to help him and sponsor the uploads.

-- 
Kind regards,
Luca Boccassi

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

Bug#888077: RFA: diamond – smart data producer for Graphite graphing package

[David Stapleton]

Hi Sandro,

I've been using diamond internally for a while now and have a good
understanding of how it hangs together. I've also been making contributions
to the code on the Github project.

Also, as far as I can see, a Subversion source repository is being used,
but I believe this will have to be converted to git very soon as Alioth is
being deprecated (based on details at
https://wiki.debian.org/Alioth#Deprecation_of_Alioth). This is something
that I'm interested in doing.

So in summary, I'd be happy to adopt this package.

I should also mention that bl...@debian.org is willing to sponsor the
uploads.

If there are any further details you need from me, let me know.

Thanks,
David

Bug#893726: dasher: Direct mode does not work in Wayland windows

[Thibaut Paumard]

Package: dasher
Version: 5.0.0~beta~repack-6
Severity: important
Tags: upstream

Dear team,

Now that #852699 is closed, the basic functionalities of Dasher work in a
Wayland session.

However, this is making use of the X11 backend. The drawback is that Direct
mode only works for X11 windows (e.g. emacs or any Gtk window started with
GDK_BACKEND=x11).

A global workaround would be for users to go back using an X11 session.

So, in my opinion, now that the default GNOME session uses Wayland, this bug is
of severity 'important'. (In this context, #852699 would even have been
'serious').

Unfortunately I have no clue how to fix this.

Kind regards, Thibaut.



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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dasher depends on:
ii  dasher-data  5.0.0~beta~repack-6
ii  libatk-adaptor   2.26.2-1
ii  libatspi2.0-02.28.0-1
ii  libc62.27-2
ii  libcairo21.15.10-1
ii  libexpat12.2.5-3
ii  libgcc1  1:8-20180312-2
ii  libglib2.0-0 2.54.3-2
ii  libgtk-3-0   3.22.29-1
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libspeechd2  0.8.8-1
ii  libstdc++6   8-20180312-2

dasher recommends no packages.

dasher suggests no packages.

-- no debconf information

Bug#893725: variety manpage at the end speaks about info but cannot find any info file

[shirish शिरीष]

Package: variety
Version: 0.6.6-2
Severity: normal

Dear Maintainer,

At the end of the manpage, get the information that the whole
documentation is in
info. Trying to poke into info gets the following -

$ info variety
bash: info: command not found

FWIW, both texinfo and command-not-found are installed so shouldn't be getting
the above output.


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages variety depends on:
ii  gir1.2-gdkpixbuf-2.0 2.36.11-1
ii  gir1.2-gexiv2-0.10   0.10.8-1
ii  gir1.2-glib-2.0  1.54.1-4
ii  gir1.2-gtk-3.0   3.22.29-1
ii  gir1.2-notify-0.70.7.7-3
ii  gir1.2-pango-1.0 1.40.14-1
ii  imagemagick  8:6.9.9.39+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.39+dfsg-1
ii  python   2.7.14-4
ii  python-bs4   4.6.0-1
ii  python-cairo 1.16.2-1
ii  python-configobj 5.0.6-2
ii  python-dbus  1.2.6-1
ii  python-gi-cairo  3.26.1-2
ii  python-pil   4.3.0-2
ii  python-pycurl7.43.0.1-0.2
ii  python-requests  2.18.4-2
ii  python2.72.7.14-7

Versions of packages variety recommends:
ii  gir1.2-appindicator3-0.1  0.4.92-5
ii  python-httplib2   0.9.2+dfsg-1

Versions of packages variety suggests:
pn  feh   
pn  gnome-shell-extension-top-icons-plus  
pn  nitrogen  

-- no debconf information


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

Bug#893724: gajim: Cannot open preferences

[Dominik George]

Package: gajim
Version: 1.0.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When trying to open preferences, I get the following error:

## Versions
- - OS: Linux
- - GTK+ Version: 3.22.29
- - PyGObject Version: 3.26.1
- - python-nbxmpp Version: 0.6.4
- - Gajim Version: 1.0.0

## Traceback
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gajim/app_actions.py", line 56, in 
on_preferences
config.PreferencesWindow()
  File "/usr/lib/python3/dist-packages/gajim/config.py", line 402, in __init__
create_av_combobox('audio_input', AudioInputManager().get_devices())
  File "/usr/lib/python3/dist-packages/gajim/common/multimedia_helpers.py", 
line 30, in get_devices
self.detect()
  File "/usr/lib/python3/dist-packages/gajim/common/multimedia_helpers.py", 
line 60, in detect
'%s is-live=true name=gajim_vol')
  File "/usr/lib/python3/dist-packages/gajim/common/multimedia_helpers.py", 
line 36, in detect_element
if hasattr(element.props, 'device'):
AttributeError: 'NoneType' object has no attribute 'props'


I have PulseAudio running; this seems unrelated to the other bug.

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

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

Versions of packages gajim depends on:
ii  gir1.2-gtk-3.03.22.29-1
ii  python3   3.6.4-1
ii  python3-gi3.26.1-2
ii  python3-gi-cairo  3.26.1-2
ii  python3-idna  2.6-1
ii  python3-nbxmpp0.6.4-1
ii  python3-openssl   17.5.0-1
ii  python3-pyasn10.4.2-3

Versions of packages gajim recommends:
ii  alsa-utils  1.1.3-1
ii  aspell-en [aspell-dictionary]   2017.08.24-0-0.1
ii  ca-certificates 20170717
ii  dbus1.12.6-2
ii  fonts-noto-color-emoji  0~20180102-1
ii  gajim-omemo 2.5.7-1
ii  gajim-pgp   1.2.2-1
ii  gir1.2-farstream-0.20.2.8-4
ii  gir1.2-geoclue-2.0  2.4.7-1
ii  gir1.2-gspell-1 1.6.1-1
ii  gir1.2-gst-plugins-base-1.0 1.14.0-1
ii  gir1.2-gstreamer-1.01.14.0-1
ii  gir1.2-gupnpigd-1.0 0.2.5-2
ii  gir1.2-networkmanager-1.0   1.10.6-2
ii  gir1.2-secret-1 0.18.5-6
ii  gstreamer0.10-plugins-ugly  0.10.19-2.1+b3
ii  notification-daemon 3.20.0-3
ii  plasma-workspace [notification-daemon]  4:5.12.3-1
ii  pulseaudio-utils11.1-4
ii  python3-crypto  2.6.1-8
ii  python3-dbus1.2.6-1
ii  python3-gnupg   0.4.1-2
ii  python3-keyring 10.6.0-1
ii  python3-pil 5.0.0-1
pn  python3-precis-i18n 
ii  sox 14.4.2-3

Versions of packages gajim suggests:
ii  avahi-daemon  0.7-3.1
ii  libxss1   1:1.2.2-1+b2
pn  nautilus-sendto   
pn  python3-avahi 
pn  python3-gconf 
pn  python3-gnome2
ii  python3-kerberos  1.1.14-1
ii  python3-pycurl7.43.0.1-0.2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlqyiYgxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pb+MBAAwhuO+rcviHekRZPWKGC5+H/oUeVB
96nEDTr+RiU0ocIfj1SBkEMJSmH5O6apJni9PDMjGGhhu7QfMSKYnGIq3moKysOP
8r00Jr0vzCIYAH6pEixkCKxwp1dqKw14pCaOU0JJ9cTYkq7D1/hAOshY/bybY/8T
BzM9hUdthi9ysWZS0SzthHUD/5Sz3A5y/yyHibeHvQWG2P6eShxyMV5vooWJNWBG
c6zYVF1ED14LwZNpiCGgtYOaXugLR2tNlRGwEP0XogQ0OpMR0ZaoHGhEa8ggPJEE
O0CzifuH4JRAyvUKbdeFPpgucAgO1ia0vFDqbeeaTE1BXhkStrkevIfyp6v8IAve
7Fk6QTa1WmzR+S+cuuKjZ8ourvjmn7WIwbLxfVq8gm+noBfXeRoX/aK2c4Xt50kU
uasDN9dimRAZpDFo7vUoeOPpBManv22PiPVjPz9HXfpauJo7Kq7YP+YDiVGoO9im
lcbMV+AXMs6TwWl8NNdjo6f2D6J95onNHGy0pnGzAQiH5yP2+9wFnsfy0wIkTgvw
Ik1jb1zLJjakwN1QkqwXHTbacEUYNC8Ril91XNV8QHszBjN9V3d2WetRSYw7jTMG
VDWSriwQ8YC6OpmFYETExJPJiGceDQ9Av1FtHuKQO2o+N4fZM71V+i/Wa64VMJgl
UKT3xrW+2Pw1DHI=
=p015
-END PGP SIGNATURE-

Bug#893566: linux-image-4.9.0-6-amd64: Logitech wireless mouse freezes with linux-image-4.9.0-6-amd64 (4.9.0-5 worked)

[Paolo Giannozzi]

Well...maybe I jumped to the conclusion too quickly. Also with kernel
linux-image-4.9.0-5-amd64 the mouse stops working from time to time, while
the touchpad always work; it also does not work if I suspend and restart
(by closing and reopening the lid).

On Mon, Mar 19, 2018 at 11:02 PM, Paolo Giannozzi 
wrote:

> Package: src:linux
> Version: 4.9.82-1+deb9u3
> Severity: normal
>
> Dear Maintainer
>
> after updating to debian 9.4, my Logitech wireless mouse (via USB) freezes
> more
> often than not. If I remove and reinsert the battery, the mouse works for
> some
> time (ot much) before freezing again. I downgraded (from the boot menu) to
> kernel linux-image-4.9.0-5-amd64 and the mouse works perfectly again.
>
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
>
> ** Model information
> sys_vendor: Acer
> product_name: TravelMate P253
> product_version: V2.07
> chassis_vendor: Acer
> chassis_version: V2.07
> bios_vendor: Acer
> bios_version: V2.07
> board_vendor: Acer
> board_name: BA51_HC_CR
> board_version: Type2 - Board Version
>
> ** Network interface configuration:
>
> source /etc/network/interfaces.d/*
>
> auto lo
> iface lo inet loopback
>
> ** PCI devices:
> 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM
> Controller [8086:0154] (rev 09)
> Subsystem: Acer Incorporated [ALI] 3rd Gen Core processor DRAM
> Controller [1025:064b]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0
> Capabilities: 
> Kernel driver in use: ivb_uncore
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
> processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA
> controller])
> Subsystem: Acer Incorporated [ALI] 3rd Gen Core processor Graphics
> Controller [1025:064b]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 27
> Region 0: Memory at c000 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at b000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 2000 [size=64]
> [virtual] Expansion ROM at 000c [disabled] [size=128K]
> Capabilities: 
> Kernel driver in use: i915
> Kernel modules: i915
>
> 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216
> Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
> Subsystem: Acer Incorporated [ALI] 7 Series/C216 Chipset Family
> MEI Controller [1025:064b]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 25
> Region 0: Memory at c0604000 (64-bit, non-prefetchable) [size=16]
> Capabilities: 
> Kernel driver in use: mei_me
> Kernel modules: mei_me
>
> 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset
> Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20
> [EHCI])
> Subsystem: Acer Incorporated [ALI] 7 Series/C216 Chipset Family
> USB Enhanced Host Controller [1025:064b]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 16
> Region 0: Memory at c0609000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: 
> Kernel driver in use: ehci-pci
> Kernel modules: ehci_pci
>
> 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset
> Family High Definition Audio Controller [8086:1e20] (rev 04)
> Subsystem: Acer Incorporated [ALI] 7 Series/C216 Chipset Family
> High Definition Audio Controller [1025:064b]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 26
> Region 0: Memory at c060 (64-bit, non-prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: snd_hda_intel
> Kernel modules: snd_hda_intel
>
> 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset Family
> PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>