Bug#843216: switch libupnp-dev to Architecture: any

[Helmut Grohne]

Package: libupnp-dev
Version: 1:1.6.19+git20160116-1.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:amule src:djmount src:gmediaserver 
src:gmrender-resurrect src:linphone src:linux-igd src:mpd src:openclonk 
src:ring src:silverjuke src:vlc src:wmaloader

The affected packages cannot satisfy their cross Build-Depends, because
their dependency on libupnp-dev is not satisfiable. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign. In this case, such a marking would be
fatal, because those source package would receive a build architecture
libupnp when requesting a host architecture one and thus failing to find
libupnp. So libupnp-dev needs to switch to Architecture: any and thus
transfer any architecture constraints to its dependencies. In general,
the architecture of transitional and meta packages should match the
architecture of their main dependency.

The attached patch also adds a few Multi-Arch headers to further aid
cross compilation. Please consider applying both changes.

Helmut
diff --minimal -Nru libupnp-1.6.19+git20160116/debian/changelog 
libupnp-1.6.19+git20160116/debian/changelog
--- libupnp-1.6.19+git20160116/debian/changelog 2016-10-19 22:03:51.0 
+0200
+++ libupnp-1.6.19+git20160116/debian/changelog 2016-11-05 06:43:41.0 
+0100
@@ -1,3 +1,10 @@
+libupnp (1:1.6.19+git20160116-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch libupnp-dev to Arch:any and add Multi-Arch (Closes: #-1).
+
+ -- Helmut Grohne   Sat, 05 Nov 2016 06:43:19 +0100
+
 libupnp (1:1.6.19+git20160116-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff --minimal -Nru libupnp-1.6.19+git20160116/debian/control 
libupnp-1.6.19+git20160116/debian/control
--- libupnp-1.6.19+git20160116/debian/control   2016-01-04 09:26:07.0 
+0100
+++ libupnp-1.6.19+git20160116/debian/control   2016-11-05 06:42:47.0 
+0100
@@ -9,6 +9,7 @@
 
 Package: libupnp6
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: libupnp0, libupnp2, libupnp3, libupnp4 (<< 1.8.0~svn20090313)
@@ -41,7 +42,8 @@
  uPnP.
 
 Package: libupnp-dev
-Architecture: all
+Architecture: any
+Multi-Arch: same
 Section: libdevel
 Depends: libupnp6-dev (>= ${binary:Version}), ${misc:Depends}
 Description: Portable SDK for UPnP Devices (development files)
@@ -56,6 +58,7 @@
 
 Package: libupnp6-dbg
 Architecture: any
+Multi-Arch: same
 Section: debug
 Priority: extra
 Depends: libupnp6 (= ${binary:Version}), ${misc:Depends}
@@ -76,6 +79,7 @@
 
 Package: libupnp6-doc
 Architecture: all
+Multi-Arch: foreign
 Section: doc
 Depends: ${misc:Depends}
 Replaces: libupnp3-dev

Bug#814657: Acknowledgement (ghc: Please add initial platform support for x32)

[John Paul Adrian Glaubitz]

On 11/05/2016 06:32 AM, John Paul Adrian Glaubitz wrote:
> Attaching a refined patch with more fine-grained x32 detection and
> updated for ghc 8.0.1.

Whoops, forgot to set INTEGER_LIBRARY to integer-simple with the 8.0.1
patch. I have re-added it and attach the updated patch.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/ghc-8.0.1/debian/patches/series new/ghc-8.0.1/debian/patches/series
--- old/ghc-8.0.1/debian/patches/series	2016-11-01 16:05:20.0 +0100
+++ new/ghc-8.0.1/debian/patches/series	2016-11-05 06:25:08.308319129 +0100
@@ -10,3 +10,4 @@
 no-pie
 find-tycon-panic
 compiler-cmm-PprC-sparc-alignment.patch
+x32-use-native-x86_64-insn.patch
diff -Nru old/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch new/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch
--- old/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch	1970-01-01 01:00:00.0 +0100
+++ new/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch	2016-11-05 06:26:05.760389006 +0100
@@ -0,0 +1,25 @@
+Description: Use native x86_64 instructions on x32
+ This patch enables a few native 64-bit integer instructions
+ on x32 which are available on this architecture despite using
+ 32-bit pointers. These instructions are present on x86_64 but
+ not on x86 and ghc checks the size of (void *) to determine
+ that. This method fails on x32 since despite using 32-bit
+ pointers and hence sizeof(void *) == 4, it still uses the
+ full x86_64 instruction set and software-emulated variants
+ of the aforementioned 64-bit integer instructions are
+ therefore not present in the toolchain which will make ghc
+ fail to build on x32.
+ See: https://ghc.haskell.org/trac/ghc/ticket/11571
+ .
+
+--- ghc-8.0.1.orig/rts/RtsSymbols.c
 ghc-8.0.1/rts/RtsSymbols.c
+@@ -737,7 +737,7 @@
+ 
+ 
+ // 64-bit support functions in libgcc.a
+-#if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32)
++#if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) && !(defined(__x86_64__) && defined(__ILP32__))
+ #define RTS_LIBGCC_SYMBOLS \
+   SymI_NeedsProto(__divdi3)\
+   SymI_NeedsProto(__udivdi3)   \
diff -Nru old/ghc-8.0.1/debian/rules new/ghc-8.0.1/debian/rules
--- old/ghc-8.0.1/debian/rules	2016-11-01 16:10:01.0 +0100
+++ new/ghc-8.0.1/debian/rules	2016-11-05 06:39:20.302348557 +0100
@@ -38,6 +38,10 @@
 BUILD_HADDOCK_DOCS=YES
 DEB_HOOGLE_TXT_DIR = /usr/lib/ghc-doc/hoogle/
 
+ifeq (x32,$(DEB_HOST_ARCH))
+  EXTRA_CONFIGURE_FLAGS += --enable-unregisterised
+endif
+
 %:
 	dh $@ --with autotools-dev
 
@@ -59,6 +63,9 @@
 ifneq (,$(findstring $(DEB_HOST_ARCH), mips mipsel))
 	echo "SRC_HC_OPTS += -optc--param -optcggc-min-expand=10" >> mk/build.mk
 endif
+ifeq (x32,$(DEB_HOST_ARCH))
+	echo "INTEGER_LIBRARY = integer-simple" >> mk/build.mk
+endif
 ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 #	echo "GhcStage1HcOpts += -DDEBUG" >> mk/build.mk
 #	echo "GhcStage2HcOpts += -DDEBUG" >> mk/build.mk

Bug#814657: Acknowledgement (ghc: Please add initial platform support for x32)

[John Paul Adrian Glaubitz]

Hi!

Attaching a refined patch with more fine-grained x32 detection and
updated for ghc 8.0.1.

Could you please apply it so we can enable ghc on the buildds for x32
again?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/ghc-8.0.1/debian/patches/series new/ghc-8.0.1/debian/patches/series
--- old/ghc-8.0.1/debian/patches/series	2016-11-01 16:05:20.0 +0100
+++ new/ghc-8.0.1/debian/patches/series	2016-11-05 06:25:08.308319129 +0100
@@ -10,3 +10,4 @@
 no-pie
 find-tycon-panic
 compiler-cmm-PprC-sparc-alignment.patch
+x32-use-native-x86_64-insn.patch
diff -Nru old/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch new/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch
--- old/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch	1970-01-01 01:00:00.0 +0100
+++ new/ghc-8.0.1/debian/patches/x32-use-native-x86_64-insn.patch	2016-11-05 06:26:05.760389006 +0100
@@ -0,0 +1,25 @@
+Description: Use native x86_64 instructions on x32
+ This patch enables a few native 64-bit integer instructions
+ on x32 which are available on this architecture despite using
+ 32-bit pointers. These instructions are present on x86_64 but
+ not on x86 and ghc checks the size of (void *) to determine
+ that. This method fails on x32 since despite using 32-bit
+ pointers and hence sizeof(void *) == 4, it still uses the
+ full x86_64 instruction set and software-emulated variants
+ of the aforementioned 64-bit integer instructions are
+ therefore not present in the toolchain which will make ghc
+ fail to build on x32.
+ See: https://ghc.haskell.org/trac/ghc/ticket/11571
+ .
+
+--- ghc-8.0.1.orig/rts/RtsSymbols.c
 ghc-8.0.1/rts/RtsSymbols.c
+@@ -737,7 +737,7 @@
+ 
+ 
+ // 64-bit support functions in libgcc.a
+-#if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32)
++#if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) && !(defined(__x86_64__) && defined(__ILP32__))
+ #define RTS_LIBGCC_SYMBOLS \
+   SymI_NeedsProto(__divdi3)\
+   SymI_NeedsProto(__udivdi3)   \
diff -Nru old/ghc-8.0.1/debian/rules new/ghc-8.0.1/debian/rules
--- old/ghc-8.0.1/debian/rules	2016-11-01 16:10:01.0 +0100
+++ new/ghc-8.0.1/debian/rules	2016-11-05 06:24:36.720280326 +0100
@@ -38,6 +38,10 @@
 BUILD_HADDOCK_DOCS=YES
 DEB_HOOGLE_TXT_DIR = /usr/lib/ghc-doc/hoogle/
 
+ifeq (x32,$(DEB_HOST_ARCH))
+  EXTRA_CONFIGURE_FLAGS += --enable-unregisterised
+endif
+
 %:
 	dh $@ --with autotools-dev
 

Bug#841670: lintian: Check udev rules and AppStream metadata

[Petter Reinholdtsen]

Here are a new set of patches rebased on the current master branch.  The
tag description in the last patch is slightly modified based on feedback
from the appstream maintainer.

Is there any hope this change can land in unstable early enough for the
package maintainers to react to the checks before Stretch?
-- 
Happy hacking
Petter Reinholdtsen
>From 44d2bcab866db48ace8110046eb23fda3911f8c9 Mon Sep 17 00:00:00 2001
From: Petter Reinholdtsen 
Date: Wed, 26 Oct 2016 12:01:16 +
Subject: [PATCH 1/3] Added two new test debs udev-rules and appstream-metadata
 for AppStream and udev checks.

---
 .../appstream-metadata-obsolete.metadata.xml   |  2 ++
 .../debian/debian/appstream-metadata.desktop   |  8 
 .../debian/debian/appstream-metadata.dirs  |  2 ++
 .../debian/debian/appstream-metadata.metadata.xml  | 22 ++
 .../debian/debian/appstream-metadata.udev  | 14 ++
 t/tests/appstream-metadata/debian/debian/rules | 14 ++
 t/tests/appstream-metadata/desc|  8 
 t/tests/appstream-metadata/tags|  6 ++
 t/tests/udev-rules/debian/debian/rules | 13 +
 t/tests/udev-rules/debian/debian/udev-rules.dirs   |  2 ++
 .../debian/debian/udev-rules.metadata.xml  | 22 ++
 t/tests/udev-rules/debian/debian/udev-rules.udev   | 17 +
 t/tests/udev-rules/desc|  7 +++
 t/tests/udev-rules/tags|  4 
 14 files changed, 141 insertions(+)
 create mode 100644 t/tests/appstream-metadata/debian/debian/appstream-metadata-obsolete.metadata.xml
 create mode 100644 t/tests/appstream-metadata/debian/debian/appstream-metadata.desktop
 create mode 100644 t/tests/appstream-metadata/debian/debian/appstream-metadata.dirs
 create mode 100644 t/tests/appstream-metadata/debian/debian/appstream-metadata.metadata.xml
 create mode 100644 t/tests/appstream-metadata/debian/debian/appstream-metadata.udev
 create mode 100644 t/tests/appstream-metadata/debian/debian/rules
 create mode 100644 t/tests/appstream-metadata/desc
 create mode 100644 t/tests/appstream-metadata/tags
 create mode 100644 t/tests/udev-rules/debian/debian/rules
 create mode 100644 t/tests/udev-rules/debian/debian/udev-rules.dirs
 create mode 100644 t/tests/udev-rules/debian/debian/udev-rules.metadata.xml
 create mode 100644 t/tests/udev-rules/debian/debian/udev-rules.udev
 create mode 100644 t/tests/udev-rules/desc
 create mode 100644 t/tests/udev-rules/tags

diff --git a/t/tests/appstream-metadata/debian/debian/appstream-metadata-obsolete.metadata.xml b/t/tests/appstream-metadata/debian/debian/appstream-metadata-obsolete.metadata.xml
new file mode 100644
index 000..31d281e
--- /dev/null
+++ b/t/tests/appstream-metadata/debian/debian/appstream-metadata-obsolete.metadata.xml
@@ -0,0 +1,2 @@
+
+
diff --git a/t/tests/appstream-metadata/debian/debian/appstream-metadata.desktop b/t/tests/appstream-metadata/debian/debian/appstream-metadata.desktop
new file mode 100644
index 000..4c91430
--- /dev/null
+++ b/t/tests/appstream-metadata/debian/debian/appstream-metadata.desktop
@@ -0,0 +1,8 @@
+[Desktop Entry]
+Version=1.0
+Type=Application
+Name=appstream-udev-data
+Terminal=true
+Exec=true
+Categories=ConsoleOnly;Game;
+Keywords=Text;
diff --git a/t/tests/appstream-metadata/debian/debian/appstream-metadata.dirs b/t/tests/appstream-metadata/debian/debian/appstream-metadata.dirs
new file mode 100644
index 000..402f5d5
--- /dev/null
+++ b/t/tests/appstream-metadata/debian/debian/appstream-metadata.dirs
@@ -0,0 +1,2 @@
+usr/share/metainfo
+usr/share/appdata
diff --git a/t/tests/appstream-metadata/debian/debian/appstream-metadata.metadata.xml b/t/tests/appstream-metadata/debian/debian/appstream-metadata.metadata.xml
new file mode 100644
index 000..82294c1
--- /dev/null
+++ b/t/tests/appstream-metadata/debian/debian/appstream-metadata.metadata.xml
@@ -0,0 +1,22 @@
+
+
+  appstream-udev-data
+  MIT
+  lintian appstream-udev-data
+  Test AppStream and udev related checks in lintian
+  
+
+  This is a test package designed to exercise some feature or tag
+  of Lintian.  It is part of the Lintian test suite and may do
+  very odd things.  It should not be installed like a regular
+  package.  It may be an empty package.
+
+  
+  
+usb:vp0001d*
+usb:vp0002d*
+usb:vp0003d*
+usb:vp0004d*
+usb:vp000ad*
+  
+
diff --git a/t/tests/appstream-metadata/debian/debian/appstream-metadata.udev b/t/tests/appstream-metadata/debian/debian/appstream-metadata.udev
new file mode 100644
index 000..e2f2841
--- /dev/null
+++ b/t/tests/appstream-metadata/debian/debian/appstream-metadata.udev
@@ -0,0 +1,14 @@
+SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="", ATTR{idProduct}=="0001", \
+MODE="0666"
+
+SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="", 

Bug#842905: rdepends need to be removed first

[Scott Kitterman]

Checking reverse dependencies...
# Broken Depends:
pynfft: python-pynfft
python-pynfft-dbg
python3-pynfft
python3-pynfft-dbg
yorick-ynfft: yorick-ynfft


Please remove the moreinfo tag once these are addressed.

Scott K

Bug#840881: xserver-xorg-video-vmware: Please announce supported hardware using AppStream

[Paul Wise]

Control: tags -1 - wontfix + upstream

On Sun, 16 Oct 2016 15:09:43 +0200 Julien Cristau wrote:

> is what I'm talking about.  I don't want to maintain this in the debian
> package.

So the bug should be fixed in Debian but only via upstream, fixing the tags.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#841781: Still rdepends

[Scott Kitterman]

More rdpends left than I care to count.  Need to have them rm'ed or something.

Please removed the moreinfo tag once that's done.

Scott K

Bug#843215: fwupd: Please announce supported hardware using appstream

[Paul Wise]

Package: fwupd
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias
X-Debbugs-CC: p...@debian.org

Please announce the supported hardware via AppStream. That will allow
users that are using isenkram to know that they might want to install
fwupd when they plugin a device that can get firmware updates.

More info about how to do this is available on the wiki page:

https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843214: dfu-util: Please announce supported hardware using appstream

[Paul Wise]

Package: dfu-util
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias
X-Debbugs-CC: p...@debian.org

Please announce the supported hardware via AppStream. That will allow
users that are using isenkram to know that they might want to install
dfu-util when they plugin a device that is in DFU mode.

More info about how to do this is available on the wiki page:

https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843213: unrar: Segmentation fault or invalid stdio handle when copypasting certain commands

[drcnjio908]

Package: unrar
Version: 1:5.3.2-1
Severity: normal

Dear Maintainer,

In short: I automatically sent invalid input to the file-overwrite-prompt,
crashing it.

What led up to the situation?

touch b
rar a b.rar b

Now I was copy pasting something like the following command (everthing between
the quotes) into xfce4-terminal:

"unrar x b.rar
e12345678901234567890123456789012345678901234567
0123456789012345678901234567890
"

Note that the clipboard should contain the last newline / linefeed, also the
'e' at the beginning seems to be important, the numbers are not. Now I get the
following output:

UNRAR 5.30 beta 2 freeware  Copyright (c) 1993-2015 Alexander Roshal


Extracting from b.rar


Would you like to replace the existing file b
 0 bytes, modified on 2016-11-05 05:19
with a new one
 0 bytes, modified on 2016-11-05 05:19

[Y]es, [N]o, [A]ll, n[E]ver, [R]ename, [Q]uit
No files to extract
Segmentation fault

When increasing the clipboard to the output changes, e.g.:

"unrar x b.rar
e12345678901234567890123456789012345678901234567
012345678901234567890123456789012345678901234567
"

results in:

UNRAR 5.30 beta 2 freeware  Copyright (c) 1993-2015 Alexander Roshal


Extracting from b.rar


Would you like to replace the existing file b
 0 bytes, modified on 2016-11-05 05:19
with a new one
 0 bytes, modified on 2016-11-05 05:19

[Y]es, [N]o, [A]ll, n[E]ver, [R]ename, [Q]uit
No files to extract
Fatal error: glibc detected an invalid stdio handle
Aborted

It seems to me that the additional two lines after the command are being sent
to the prompt and effectively fuzzying it. Indeed the problem can be reproduced
like this:

echo "e12345678901234567890123456789012345678901234567
012345678901234567890123456789012345678901234567
" | unrar x b.rar



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

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

Versions of packages unrar depends on:
ii  libc6   2.24-5
ii  libgcc1 1:6.2.0-10
ii  libstdc++6  6.2.0-10

unrar recommends no packages.

unrar suggests no packages.

-- no debconf information

Bug#843211: gradle: please add dependency “Suggests: gradle-doc”

[Ben Finney]

Package: gradle
Version: 2.13-4
Severity: minor

Dear Maintainer,

Working with the ‘gradle’ packages requires understanding how it works
and what it does.

Please set a “Suggests: gradle-doc” dependency to the binary package
‘gradle’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “If we listen only to those who are like us, we will squander |
  `\   the great opportunity before us: To live together peacefully in |
_o__)a world of unresolved differences.” —David Weinberger |
Ben Finney 


signature.asc
Description: PGP signature

Bug#841909: Merging bugs about pinentry failing without GNOME-connected d-bus

[Daniel Kahn Gillmor]

Control: reassign 841909 842015 842334 pinentry-gnome3 0.9.7-6
Control: forcemerge 841909 842015 842334
Control: tag 841909 + patch pending

The three bugs above are all caused by a situation where the user wants
to use secret key material with gpg, while relying on pinentry-gnome3
with access to a d-bus session, but where that d-bus session has no
access to an expected GNOME session.

if pinentry-gnome3 knows that there is no d-bus session available, it
will fall back to curses.

But if it has access to a d-bus session where the Gcr prompter is
potentially active, it will try to use it, even if that Gcr prompter
cannot possibly display a prompt because no GNOME session is connected
to it.  This is a bug in pinentry-gnome3, not a bug in gpg or gpg-agent.

I have a patch in the pipeline for pinentry-gnome3 that enables fallback
to curses in the situation where a d-bus session is available but Gcr
prompter is not.

 --dkg


signature.asc
Description: PGP signature

Bug#841760: firejail: Network namespace disconnect

[Aidan Gauland]

On 05/11/16 11:18, Reiner Herrmann wrote:
> On Sat, Nov 05, 2016 at 11:09:31AM +1300, Aidan Gauland wrote:
>> I can successfully ping 8.8.8.8, and the contents of /etc/resolv.conf
>> both in and out of the sandbox is the single line,
>>
>> nameserver fe80::c6e9:84ff:fe9f:7bb2%eth0
> 
> Are you able to reach (ping6) this address?
> If yes, are you able to use it for dns lookups
> (nslookup debian.org fe80::c6e9:84ff:fe9f:7bb2%eth0)?

Only outside the sandbox; inside the sandbox, it gives me "unknown
host", but if I change "%eth0" to "%eth0-11278", I can ping it, and I
can use it for DNS lookups.

> Do you also have the package resolvconf installed?

No, and I don't think I ever have on this system.


So now that we have narrowed down the cause of the lookup failures, how
do I fix this?  And why on Earth does this happen only after the system
has been up for a few minutes, and not all the time?  rdnssd has been on
my system for a long time, but it's possible that I have unwittingly
changed some system configuration that affecting /etc/resolv.conf



signature.asc
Description: OpenPGP digital signature

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Guillem Jover]

Hi!

On Fri, 2016-11-04 at 10:47:07 +, Chris Lamb wrote:
> Guillem Jover wrote:
> > If you notice this is still a problem, please do file a bug!
> 
> Indeed I can still reproduce it:
> 
>  
> https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/redis_3.2.5-1_amd64.buildinfo
>  https://gist.github.com/lamby/214906fbfa8814acc8b920b800977216/raw
> 
> Note that this is using dpkg-dev "1.18.10.0~reproducible1" (hey, these
> .buildinfo files are rather useful…).

I tried building that package with the fix (from git master) enabled and
disabled and I see the buildinfo w/o and w/ the duped entry in the field.
So this confirms the fix works. :)

Thanks,
Guillem

Bug#843163: dpkg: -V fails on files with \ in the name

[Guillem Jover]

Control: reassign -1 debhelper
Control: affects -1 dpkg debsums

[ Leaving enough context for debhelper maintainers. ]

Hi!

On Fri, 2016-11-04 at 14:14:05 +0100, Bernd Zeimetz wrote:
> Package: dpkg
> Severity: normal
> Version: 1.18.10

> open-vm-tools-desktop contains a systemd mount unit with a maybe unusal
> filename:
> 
> /lib/systemd/system/run-vmblock\x2dfuse.mount
> 
> \x2d is the systemd way to escape characters, see systemd.unit(5):
>Basically, given a path, "/" is replaced by "-", and
>all other characters which are not ASCII alphanumerics are
>replaced by C-style "\x2d" escapes (except that "_" is never
>replaced and "." is only replaced when it would be the first
>character in the escaped path).
> 
> dpkg -V fails on that:
> 
> # dpkg -V open-vm-tools-desktop
> dpkg: error: control file 'md5sums' missing value separator
> 
> Reason for that seems to be that md5sum - similar as sha256sum and others,
> seems to start such lines with a \:
> 
> \dde14951417e0e9f73b80f871e6540d1
> lib/systemd/system/run-vmblock\\x2dfuse.mount
> 
> Removing the \ from the beginning of the line make dpkg -V verify the
> package successfull.
> 
> So either dh_md5sums should remove \-es, or dpkg should handle the format
> md5sum produces.

Hmm, this is also not what dpkg will generate when creating md5sums
itself, when the packages does not ship one. Also debsums does not
seem like it handles this weird GNU-specific escaping extension.

I've checked around and other md5sum implementations do not support
this, for example FreeBSD, NetBSD nor Mac OS X. In addition the GNU
md5sum --tag option generates BSD-style output with escaped content
which is not understood by the BSD implementations!

The upcoming dpkg-gendigests command will also not generate those
escaped entries, so IMO debhelper should be fixed to either strip
them, switch to a pure perl implementation, or wait a bit and use
the upcoming dpkg-gendigests command. Meanwhile you could strip
them in the open-vm-tools package debian/rules file.

Thanks,
Guillem

Bug#833850: dpkg-dev: add per-architecture optimisation flags to dpkg-buildflags

[Guillem Jover]

Control: reassign -1 gcc-6

[ Leaving enough context for gcc maintainers. ]

On Tue, 2016-08-09 at 14:08:45 +0200, Ximin Luo wrote:
> Package: dpkg-dev
> Version: 1.18.10
> Severity: wishlist

> Many software packages (e.g. see #833846) like to set optimisation
> flags based on autodetecting CPU features of the build machine. Of
> course this is not suitable for binary distributors in general, and
> for Debian package maintainers should instead hard-code optimisation
> flags based on DEB_HOST_ARCH.
> 
> However as far as I can tell, there is no central documentation
> resource that describes the optimisation flags suitable for each
> Debian architecture. Because of this, in practise package maintainers
> will just disable all build-time CPU detection to avoid generating
> illegal instructions. I have done this myself in the past, and this
> is what I suggest in #833846. But it's a shame to disable *all*
> optimisations.
> 
> dpkg-buildflags would be a good place to put these flags. Maintainers
> can do what they were doing before (disable build-time CPU autodetection)
> but still get a somewhat-optimised build - in fact, the most optimised
> that it can validly be for a Debian binary package. It would also act
> as a good central location to document which instructions each Debian
> architecture actually supports, and including how this might change
> over time - e.g. how i386 was bumped up to requiring i686 this May.

I think the right place to enable any such default ISAs is the
compiler (gcc in this case), because that is the one defining the
ISAs baseline. For example, at least according to the gcc-6 docs,
-msse and -msse2 are already enabled by default on amd64. So if other
architectures are missing similar settings then I'd suggest you propose
to enable them on gcc on this bug report.

Thanks,
Guillem

Bug#828215: unattended-upgrades: resets "automatically installed" state when upgrading packages

[Paul Wise]

On Sun, 26 Jun 2016 09:42:53 +0200 Paul Wise wrote:

> I noticed that unattended-upgrades resets the "automatically installed"
> state when upgrading packages, which means that when I remove a package
> that has been upgraded, apt will not automatically remove the installed
> dependencies that have been unattended-upgraded.

Would it be possible to get the fix for this uploaded soon?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#842715: Increasing severity (should have done this sooner)

[Lisandro Damián Nicanor Pérez Meyer]

Control: severity -1 serious

Better late than never I guess...

Pino: I looked into updating skrooge with the patch in this bug but found out 
that you where packaging a new version already (svn trunk).

At this point I don't even remember how to handle this situation on SVN 
anymore :S. Should I increase cp the last tag into a new one and work there, 
backporting the changes to trunk? Should I just wait for you?

Thanks a lot in advance, Lisandro.

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


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

Bug#701478: Changing fonts-open-sans ITP back to RFP

[Adrian Bunk]

Control: retitle -1 RFP: fonts-open-sans -- sans serif typeface
Control: noowner -1

No progress since January 2015.

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#843168: closed by Joerg Jaspert <jo...@debian.org> (done (Produce DEFERRED queue overviews again, closes: #843168))

[Eriberto]

Thanks!

Em sexta-feira, 4 de novembro de 2016, Debian Bug Tracking System <
ow...@bugs.debian.org> escreveu:

> This is an automatic notification regarding your Bug report
> which was filed against the ftp.debian.org package:
>
> #843168: deferred queue: does not showing delayed packages
>
> It has been closed by Joerg Jaspert >.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Joerg Jaspert <
> jo...@debian.org > by
> replying to this email.
>
>
> --
> 843168: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843168
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org  with problems
>

Bug#843209: Please permit class directory-like feature for fai-diskimage

[Thomas Lange]

Just as a short note. There's the commands fai-deps(8) which can be
used to define dependencies inside classes. It's available in FAI but
not used (means called) by default.
-- 
regards Thomas

Bug#843209: Please permit class directory-like feature for fai-diskimage

[Sam Hartman]

package: fai
version: 5.2
severity: wishlist.

FAI has a great feature in the class directory that allows a
configuration space to infer classes from things such as the installed
hardware.
This is not currently available from fai-diskimage.
I'd really like to have a feature like that for fai-diskimage.

My recommendation is that the class script be run for fai-diskimage, and
that there be some way for a script to determine if it is producing a
diskimage so that scripts that do things like output classes based on
the current machine would not run.

An alternative would be to have a directory parallel to class that was
only used for diskimage.
A far less desirable alternative would be for the cloud team to wrap
fai-diskimage for this purpose.
We'll almost certainly wrap fai-diskimage, but I was hoping that our
wrappers would focus on things like uploading images, not on stuff like
this.

You said you didn't see the point for disk-images.
You don't infer things from the current environment, but you infer
aspects of configuration from other aspects of configuration to improve
maintainability, and simplicity of calling the interface.
Here are examples where this is useful.

* inferring either GRUB_PC or GRUB_EFI from AMD64 and whether the
  provider in question currently uses EFI

* Any of GCE or EC2 implying CLOUD

* Implying classes from release.  For example, as we moved from wheezy
  to jessie, SYSTEMD might be implied.  It seems likely that there will
  be similar future-such that will be triggered either by Debian
  release, or by the time frame and provider


For non-cloud work, I think I'll want this feature in my own
fai-diskimage usage.
Inside my employer, Hadron, we'll have a number of classes related to
things like whether a desktop is installed, whether we're building an
installer image, or an image to be given to hardware vendors to be
burned into systems before they are delivered to us.
Only a couple of these configurations will be supported at any given
time, but to ease comprehension of the configuration space and to deal
with code evolution, these will be  split into classes.
I'd prefer that people calling fai-diskimage provide in one top-level
class corresponding to one of the supported top-level configurations.


--Sam
I'm happy to work on an implementation once you figure out what
approaches you'd be willing to accept.

Bug#842919: transition: xen

[Emilio Pozuelo Monfort]

On 05/11/16 01:00, Ian Jackson wrote:
> Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
>> Control: tags -1 confirmed
> ...
>> Sounds good to me. Please go ahead.
> 
> Thanks.  For the avoidance of doubt, was that an instruction to upload
> the new version of xen to unstable ?

It is.

Cheers,
Emilio

Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit

[Walter Landry]

Rock Storm  wrote:
> On Mon, 2016-10-31 at 14:02 -0700, Walter Landry wrote:
>> FYI, I created a package for this for my own use.
> 
> That's awesome! Is it uploaded somewhere? Could you share it with me? I
> would love to take a look at it.

Here is a tarball.

  https://caltech.box.com/s/f64t26xgauc9re6k3sryv5spagipslnu

As promised, the package is not optimal.  It is versioned with git,
but the modifications to debian/ and the main package are mixed.  If
DEBFULLNAME and DEBEMAIL are set, then running

  fakeroot debian/rules binary

should give you three rpms

  cspice_0065-1_amd64.deb
  libcspice-dev_0065-1_amd64.deb
  libcspice_0065-1_amd64.deb

I replaced the build system with waf.  I have a waf package already.
Waf is a bit controversial in Debian, so I need to make an ITP and see
what the Debian consensus is.

Cheers,
Walter Landry

Bug#833055: Packaging of mongoclient replacement library: mongocxx

[Giulio Paci]

Hi Apollon,

Il 04/nov/2016 14:13, "Apollon Oikonomopoulos"  ha
scritto:
> First of all, thanks for packaging the MongoDB C++ driver!

You are welcome. :-)

> Now that Debian has moved to MongoDB 2.6+, it would be great if we could
> upload libmongoclient-dev to unstable

What is blocking me from trying to move it to unstable is this discussion
that I had with upstream:

https://jira.mongodb.org/plugins/servlet/mobile#issue/CXX-923

They finally released mongocxx 3.0.x, that they currently recommend for new
development. On the other hand, my use case for this package (Orion context
broker, https://github.com/telefonicaid/fiware-orion), seems to still use
the version I packaged, so I kept the package in experimental.

> (and possibly have
> mongo-cxx-driver-legacy provide mongodb-dev as a metapackage as well),

What is the purpouse of this metapackage?

> as at least one package (uwsgi) could make use of it.

Maybe the new driver could be an alternative for this package?

> Please let me know if you need any assistance; I'm also available to
> sponsor the upload.

Currently I have no time at all (and will likely not have time for the next
few months). So feel free to work on this package as you want/need.
I am open to co-maintainance or even to orphan this package, if you want to
adopt it.

Best,
Giulio

Bug#843208: plasma-workspace: Does not start plasmashell on the KDE.

[Diederik de Haas]

On zaterdag 5 november 2016 00:57:17 CET Santiago José López Borrazás wrote:
> ii  libqt5core5a 5.7.1~20161021+dfsg-5

You got caught up in the middle of the transition of qt5:
https://release.debian.org/transitions/html/qtbase-abi-5-7-1.html

All the packages that are using qt5 will therefor need to be rebuild and 
that'll take time.
So afaik you have 2 options:
- wait till the migration finishes and have a (mostly) non-working system till 
then
- Use qt5 from testing (and maybe also various applications if they already 
have been recompiled against qt5 5.7.1~x)

Welcome to sid, where you get to keep both halves ;-)

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

Bug#842919: transition: xen

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> Control: tags -1 confirmed
...
> Sounds good to me. Please go ahead.

Thanks.  For the avoidance of doubt, was that an instruction to upload
the new version of xen to unstable ?

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#843208: plasma-workspace: Does not start plasmashell on the KDE.

[Santiago José López Borrazás]

Package: plasma-workspace
Version: 4:5.8.2-1
Severity: important

Dear Maintainer,

The screen is BLACK vision and the process plasmashell is missing and
closing in one minute. Not executing new programs and not working on the 
versions packages in this moment.

Problem on the akonadi? Any ideas?

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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x11 1.10.12-1
ii  frameworkintegration 5.27.0-1
ii  gdb  7.11.1-2
ii  iso-codes3.70-1
ii  kactivitymanagerd5.8.2-1
ii  kde-cli-tools4:5.8.2-1
ii  kded55.27.0-1
ii  kinit5.27.0-1
ii  kio  5.27.0-2
ii  kpackagetool55.27.0-1
ii  libc62.24-5
ii  libcln6  1.3.4-2
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-1
ii  libgcc1  1:6.2.0-11
ii  libgps22 3.16-3
ii  libice6  2:1.0.9-1+b1
ii  libkf5activities55.27.0-1
ii  libkf5auth5  5.27.0-1
ii  libkf5baloo5 5.27.0-1
ii  libkf5bookmarks5 5.27.0-1
ii  libkf5calendarevents55.27.0-1+b1
ii  libkf5completion55.27.0-1
ii  libkf5configcore55.27.0-1
ii  libkf5configgui5 5.27.0-1
ii  libkf5configwidgets5 5.27.0-1
ii  libkf5coreaddons55.27.0-1
ii  libkf5crash5 5.27.0-1
ii  libkf5dbusaddons55.27.0-1
ii  libkf5declarative5   5.27.0-1+b1
ii  libkf5globalaccel-bin5.27.0-1
ii  libkf5globalaccel5   5.27.0-1
ii  libkf5guiaddons5 5.27.0-1
ii  libkf5holidays5  16.04.2-1
ii  libkf5i18n5  5.27.0-2
ii  libkf5iconthemes55.27.0-1
ii  libkf5idletime5  5.27.0-1
ii  libkf5itemviews5 5.27.0-1
ii  libkf5jobwidgets55.27.0-1
ii  libkf5js55.27.0-1
ii  libkf5jsembed5   5.27.0-1
ii  libkf5kdelibs4support5   5.27.0-1
ii  libkf5kiocore5   5.27.0-2
ii  libkf5kiofilewidgets55.27.0-2
ii  libkf5kiowidgets55.27.0-2
ii  libkf5networkmanagerqt6  5.27.0-1
ii  libkf5newstuff5  5.27.0-1
ii  libkf5notifications5 5.27.0-1
ii  libkf5notifyconfig5  5.27.0-1
ii  libkf5package5   5.27.0-1
ii  libkf5plasma55.27.0-1
ii  libkf5plasmaquick5   5.27.0-1
ii  libkf5quickaddons5   5.27.0-1+b1
ii  libkf5runner55.27.0-1
ii  libkf5service-bin5.27.0-1
ii  libkf5service5   5.27.0-1
ii  libkf5solid5 5.27.0-1
ii  libkf5texteditor55.27.0-1
ii  libkf5textwidgets5   5.27.0-1
ii  libkf5wallet-bin 5.27.0-1
ii  libkf5wallet55.27.0-1
ii  libkf5waylandclient5 4:5.27.0-1
ii  libkf5widgetsaddons5 5.27.0-1
ii  libkf5windowsystem5  5.27.0-1
ii  libkf5xmlgui55.27.0-1
ii  libkf5xmlrpcclient5  5.27.0-1
ii  libkscreenlocker55.8.2-1
ii  libksgrd74:5.8.2-1
ii  libkworkspace5-5 4:5.8.2-1
ii  libphonon4qt5-4  4:4.9.0-4
ii  libplasma-geolocation-interface5 4:5.8.2-1
ii  libprocesscore7  4:5.8.2-1
ii  libprocessui74:5.8.2-1
ii  libqalculate5v5  0.9.7-9.1+b1
ii  libqt5core5a 5.7.1~20161021+dfsg-5
ii  libqt5dbus5  5.7.1~20161021+dfsg-5
ii  libqt5gui5   5.7.1~20161021+dfsg-5
ii  libqt5network5   5.7.1~20161021+dfsg-5
ii  libqt5qml5   5.7.1~20161021-4

Bug#827199: hfst: FTBFS: twolc test fails on big-endian systems

[Tino Didriksen]

On 4 November 2016 at 20:49, Jonathan Wiltshire  wrote:

> > > While it did successfully build in the past, that was only because the
> test
> > > suite was disabled until recently. The tests revealed the unsigned char
> > > issue which was easy to fix, and now the endian issue which will not
> be as
> > > easy.
>
> Any news?


Yes, it will be fixed this month. We've got a strategy that'll work for the
primary usecases - using little-endian everywhere.

-- Tino Didriksen

Bug#843207: ITP: man2texi -- man page to texinfo file converter

[Paul Hardy]

Package: wnpp
Severity: wishlist
Owner: "Paul Hardy" 
Version: 0.02
Upstream Author: Nelson Beebe
URL: http://ftp.math.utah.edu/pub/man2texi/
License: GPL2+, GFDL1.3+
Programming Lang: Bourne shell, awk, sed
Description: man page to texinfo file converter

Debian packages require man pages, GNU packages require texinfo files,
and never the twain shall meet...until now.  The man2texi package can
convert single man pages to texinfo files, or convert multiple man
pages to texinfo files in a batch mode.

The upstream author, Professor Nelson Beebe of the University of Utah,
is very active in the TeX and GNU communities.  He wrote an earlier
version of this converter, man2texi version 0.01, over a decade ago.
Someone else with the GNU Project and I have further modified that
package.  I am working in cooperation with Professor Beebe to produce
a version 0.02 with these modifications.  We expect this to be done
shortly.  "When it is ready" (to coin a phrase), I intend to package
it for Debian.

The package consists mainly of: a Bourne-type shell script (which will
be installed as /usr/bin/man2texi), an awk script and a sed script
that will be installed in /usr/share/man2texi/, and a man2texi.1.gz
man page.

Although the version number is low, this package performs a batch
conversion on all of the man pages in my Unifont package with one
command, producing perfect texinfo output.

The GNU (and Debian) autogen package already has a file named
man2texi, but it is buried in the autogen directory and will not cause
any conflict.  It does not have a man page either, so there will be no
conflict with the man2texi man page.  I have been in contact with the
Debian Developer who maintains autogen, Andreas Metzler, about this.

There is one usage quirk with this package: the sed script will
convert man pages containing ISO-8859-1 (Latin 1) characters, not
UTF-8 characters.  Because of this, I run the command by setting
"LC_ALL=C".  I do not think this is a show stopper, as this
environment variable can be set on a command line in a Makefile, and
this usage is documented in the man2texi man page.

The package is small and simple, so it should not take long to review
once ready.  I am hoping to get it into Testing before the upcoming
freeze.


Paul Hardy
GNU Unifont Maintainer

Bug#843194: chirp: running chirp as non-root

[Josiah Ritchie]

That means add your user with a command on the command line like `sudo
adduser myusername dialout`. Then you'll be good to use your USB serial
ports to the radio without root access.

On Fri, Nov 4, 2016 at 2:21 PM Colin Tuckley  wrote:

> On 04/11/16 19:55, Arturo Borrero Gonzalez wrote:
> > Package: chirp
> > Version: 1:20160717-1
> > Severity: normal
>
> > I'm running into problems using chirp as a non-root user.
> >
> > When it comes to read/write from an usb connected walkie-talkie, chirp
> > complains about wrong permissions and refuses to work.
> >
> > Perhaps I need additional permission configuration in my machine.
>
> As it says in the manual - to use chirp with a serial port (which is
> what you are doing via the USB connection) your user needs to be a
> member of the 'dialout' group.
>
> 73, Colin
>
>

Bug#843146: /usr/bin/vim.gtk3: grey rectangle, no text shown or insertable

[James McCoy]

Control: reassign -1 libgtk-3-0 3.22.2-1
Control: forcemerge 842070 -1

On Fri, Nov 04, 2016 at 11:24:32AM +0100, Ph. Marek wrote:
> # vim.gtk3 -g -u NONE -U NONE -N
> gives me a window, but where the text should be only a grey rectangle is 
> visible. No text shown (expected version info etc.), no cursor, nothing 
> insertable.

Merging with existing bug reports.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#842919: transition: xen

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 04/11/16 01:25, Ian Jackson wrote:
> Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
>> On 02/11/16 11:47, Ian Jackson wrote:
> ...
>>> All that is needed from the build-rdeps is a rebuild.  That is, of:
>>>   libvirt qemu xenwatch python-pyxenstore collectd grub2
>>>
>>> I have checked that they all build against the new libxen{-4.8,-dev},
>>> at least on amd64.  I don't anticipate trouble on other architectures.
>>
>> The ben tracker only lists qemu and libvirt as rdeps of the binaries
>> that are removed in the new version. Why do the other packages need
>> a rebuild? Do any of them statically link libxen or something?
> 
> (Hi.  Thanks for your attention.  I am somewhat full of wine right
> now, so my answers may be wrong.  It seemed better to reply sooner.
> My work hat can produce more sober replies tomorrow:)
> 
> I got the list from "build-rdeps".  Is it wrong ?  It's the list of
> things which have libxen-dev as a build-dep.
> 
> Hrm.  I looked at xenwatch and python-pyxenstore and though the source
> packages Build-Depend on libxen, the binaries Depend only libxenstore
> whose ABI version and package name have not changed.  So I think,
> then, that there is actually no need to recompile those two, although
> it would probably be best to do so as a precaution (in case the ABI
> has unwittingly changed, in which case it would be somewhat better for
> stretch to be internally consistent).
> 
> In my test rebuild, collectd.deb Depends libxen-4.8.  My apt-cache
> show thinks that sid's current collectd Depends libxen-4.6.  I'm not
> sure why a collectd rebuild would not be needed.
> 
> grub2 is more complicated.  I am going to reply separately about that,
> CC grub2@p.d.o.

Sounds good to me. Please go ahead.

Thanks,
Emilio

Bug#819530: transition: icu

[Emilio Pozuelo Monfort]

Control: reopen -1

On 04/11/16 23:51, Mattia Rizzolo wrote:
> On Fri, Nov 04, 2016 at 10:24:52PM +0100, Emilio Pozuelo Monfort wrote:
>> And this is finally finished.
> 
> Umh, though there is still the old version libicu55 on s390x, due to
> xerces-c - #833754

Oh, I knew about that, but thought it had been fixed because the tracker
disappeared from 'pending transitions'. Now I realise that was because there is
a new one in 'planned transitions' because of the new package in experimental,
which causes the other one to disappear.

Let's reopen this.

Cheers,
Emilio

Bug#839869: transition: poppler 0.48.0

[Emilio Pozuelo Monfort]

On 31/10/16 08:28, Emilio Pozuelo Monfort wrote:
> On 31/10/16 07:57, Pino Toscano wrote:
>> In data giovedì 20 ottobre 2016 13:49:55 CET, Emilio Pozuelo Monfort ha 
>> scritto:
>>> Control: tags -1 confirmed
>>>
>>> On 18/10/16 23:30, Pino Toscano wrote:
 In data lunedì 17 ottobre 2016 21:11:00 CEST, Emilio Pozuelo Monfort ha 
 scritto:
> On 08/10/16 20:34, Pino Toscano wrote:
>> In data giovedì 6 ottobre 2016 10:25:57 CEST, Rene Engelhard ha scritto:
>>> Hi,
>>>
>>> On Wed, Oct 05, 2016 at 10:13:14PM +0200, Pino Toscano wrote:
 This transition impacts the existing poppler libraries in the 
 following ways:
 - libpoppler61 → libpoppler64
>>> [...]
   boomaga
   calligra
   cups-filters
   emacs-pdf-tools
   gambas3
   gdal
   gdcm
   inkscape
   ipe-tools
   pdf2djvu
   pdf2htmlex
   popplerkit.framework
   texlive-bin
   texworks
   xpdf
>>>
>>> I believe there's stuff missing there for whatever reason. E.g. 
>>> libreoffice
>>> (via libreoffice-pdfimport, 
>>> https://packages.debian.org/sid/libreoffice-pdfimport).
>>>
>>> Was in your last transition bugs afaicr, so I wonder what went wrong 
>>> this time ;)
>>
>> Oh right, sorry, it was indeed missing.  In the above list there is also:
>>
>>   libreoffice
>>   openscenegraph
>>   openscenegraph-3.4
>
> I see the new poppler is now in experimental. Do the rdeps build against 
> the new
> version?

 I could test everything but LibreOffice: no failures.

 Rene, could you please give LO + poppler/experimental a try? Thanks!
>>>
>>> Rene told me LO is fine. Please go ahead.
>>
>> Sorry for the late reply -- I was busy and thus I couldn't dedicate the
>> proper time to follow the transition.
>>
>> Is the slot for this transtition still open, or should I wait for any
>> other in progress transitions?
> 
> Let's wait for the gdal transition to finish. Thanks for checking first.

gdal is done. Let's do this.

Cheers,
Emilio

Bug#819530: transition: icu

[Mattia Rizzolo]

On Fri, Nov 04, 2016 at 10:24:52PM +0100, Emilio Pozuelo Monfort wrote:
> And this is finally finished.

Umh, though there is still the old version libicu55 on s390x, due to
xerces-c - #833754

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

[James McCoy]

On Fri, Nov 04, 2016 at 01:39:35PM +, Steven Chamberlain wrote:
> Hi,
> 
> If you've no objection, I may build vim on the kfreebsd-* porterboxes
> with DEB_BUILD_OPTIONS=nocheck, and binNMU the result.

What about just disabling the Perl bindings on kfreebsd-any for now?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#842714: libwebp: CVE-2016-9085: several integer overflows

[Jeff Breidenbach]

Working with upstream on this.

Bug#843167: bash: when called as 'sh' interprets backslash in single quotes

[Leszek Dubiel]

At the present time that is the current expected behavior.  I see no
bug here.  Except for the bug of using escape sequences with echo.
But that is a bug in any shell script that uses it and not in either
bash or dash.

Bob



Please close the bug. I have found that it is echo behaviour instead of 
shell's.

Bug#843206: Enabling gdbm

[Hans van Kranenburg]

Package: libaprutil1
Version: 1.5.4-2
Severity: wishlist

Hi apr-util maintainer,

I would ask you to consider enabling gdbm support in apr-util so that
users can use mod_authn_dbm in apache with AuthDBMType GDBM

Because of performance problems with the size of a htpasswd file, we
switched to using a gdbm file as it's the easiest performance upgrade
available, with a big reward.

Building the gdbm so was removed in 2006. Here's the commit, there's no
explanation why at all in the commit, so that info is lost, or maybe
Tollef Fog Heen will be reading this and remembering it.

https://anonscm.debian.org/cgit/pkg-apache/apr-util.git/commit/?id=8e74bcdc83a53e4ef6bea1e1ae4b8993a410a834

When adding libgdbm-dev to the Build-Depends and changing --without-gdbm
into --with-gdbm, the package will include
/usr/lib/x86_64-linux-gnu/apr-util-1/apr_dbm_gdbm-1.so

By the way, it works like a charm. It's O(1) lookups instead of O(N) and
it saves a lot of cpu cycles otherwise spend parsing lines of text.

Thanks,

-- 
Hans van Kranenburg

Bug#843205: monodevelop: Conflicts (aka breaks) with its own suggestion monodevelop-debugger-gdb

[Petter Reinholdtsen]

Package: monodevelop
Version: 5.10.0.871-2

The package control file include this:

  Suggests: ..., monodevelop-debugger-gdb, ...
  Breaks: monodevelop-debugger-gdb

Notice how it is conflicting with its own suggested package.  I guess
either the suggest or the breaks should go?

The problem is not present in Jessie (version 4.0.12+dfsg-6).
-- 
Happy hacking
Petter Reinholdtsen

Bug#841760: firejail: Network namespace disconnect

[Reiner Herrmann]

On Sat, Nov 05, 2016 at 11:09:31AM +1300, Aidan Gauland wrote:
> nameserver fe80::c6e9:84ff:fe9f:7bb2%eth0

I think that could be the issue, as you have no eth0 in the sandbox.


signature.asc
Description: Digital signature

Bug#843204: ftp.debian.org: remove powerpc from testing

[Jonathan Wiltshire]

Package: ftp.debian.org
Severity: normal

Hi,

britney has learned about the powerpc removal from testing [1]. Please
complete the removal on the archive side.

Thanks,

1: https://lists.debian.org/debian-devel-announce/2016/10/msg8.html

Bug#843203: python-kdcproxy: Please add README to binary packages

[Jochen Hein]

Package: python-kdcproxy
Version: 0.3.2-3
Severity: wishlist

Dear Maintainer,

in the binary package is no documentation - a look at github and
I see that the README is well written and describes how to
configure apache to use python-kdcproxy. I'd like to have
the README packaged - my first look was at /usr/share/doc...

Thanks
Jochen

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates'), (99, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages python-kdcproxy depends on:
ii  python-dnspython  1.12.0-1
ii  python-pyasn1 0.1.7-1
pn  python:any

python-kdcproxy recommends no packages.

python-kdcproxy suggests no packages.

-- no debconf information

Bug#841760: firejail: Network namespace disconnect

[Reiner Herrmann]

On Sat, Nov 05, 2016 at 11:09:31AM +1300, Aidan Gauland wrote:
> I can successfully ping 8.8.8.8, and the contents of /etc/resolv.conf
> both in and out of the sandbox is the single line,
> 
> nameserver fe80::c6e9:84ff:fe9f:7bb2%eth0

Are you able to reach (ping6) this address?
If yes, are you able to use it for dns lookups
(nslookup debian.org fe80::c6e9:84ff:fe9f:7bb2%eth0)?

> > I saw that you are running rdnssd, which might overwrite
> > /etc/resolv.conf.
> 
> I think rdnssd was part of the base Debian installation, so that
> shouldn't suddenly be causing problems now.  Could it?

It is installed as a suggestion of ifupdown.
Do you also have the package resolvconf installed?


signature.asc
Description: Digital signature

Bug#841760: firejail: Network namespace disconnect

[Aidan Gauland]

On 05/11/16 10:40, Reiner Herrmann wrote:
> On Sat, Nov 05, 2016 at 10:32:21AM +1300, Aidan Gauland wrote:
 $ w3m google.com
 w3m: Can't load google.com.
>>>
>>> The same error occurs when only DNS is not working.
>>> Can you please try pinging your default gateway?
>>
>> Yes, pinging the default gateway works just fine with 0% packet loss
>> (tested with 20 packets).
> 
> Interesting, then I assume pinging an external IP address also works
> (like 8.8.8.8)?  Can you check /etc/resolv.conf if a valid nameserver
> is configured?

I can successfully ping 8.8.8.8, and the contents of /etc/resolv.conf
both in and out of the sandbox is the single line,

nameserver fe80::c6e9:84ff:fe9f:7bb2%eth0

> I saw that you are running rdnssd, which might overwrite
> /etc/resolv.conf.

I think rdnssd was part of the base Debian installation, so that
shouldn't suddenly be causing problems now.  Could it?



signature.asc
Description: OpenPGP digital signature

Bug#843202: flashplugin-nonfree: Can't update Flash plugin version

[Alexandre Lymberopoulos]

Package: flashplugin-nonfree
Version: 1:3.7
Severity: important

Dear Maintainer,

It has nothing to do with the FlashPlugin itself. I've tried to update the 
outdated version of flash plugin with the usual command

update-flashplugin-nonfree --install

and I get the following:

ERROR: wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.11.2.202.643.sha512.amd64.pgp.asc

It seems simple to fix this just by uploading the right file to the place 
above, right?

Thanks in advance,

Alexandre.

-- Package-specific info:
Debian version: stretch/sid
Architecture: amd64
Package version: 1:3.7
Adobe Flash Player version: LNX 11,2,202,632
MD5 checksums:
29c85bc8504422120cf89702986ff8e1  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
ace1a0801f00a25fd90172f63e98e101  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
e3a1280f91b278b8832500f362d0546b  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
lrwxrwxrwx 1 root root 34 Aug 21 23:16 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

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

Versions of packages flashplugin-nonfree depends on:
ii  binutils   2.27-9+b1
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  2.1.15-4
ii  gnupg2 2.1.15-4
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.6-1+b1
ii  libcurl3-gnutls7.50.1-1
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.2.0-10
ii  libglib2.0-0   2.50.1-1
ii  libgtk2.0-02.24.31-1
ii  libnspr4   2:4.12-2
ii  libnss32:3.26.2-1
ii  libpango1.0-0  1.40.3-2
ii  libstdc++6 6.2.0-10
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.18-4

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
ii  firefox-esr45.4.0esr-2
ii  fonts-dejavu   2.37-1
pn  hal-flash  
pn  iceweasel  
pn  konqueror-nsplugins
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#843198: gcc-6: Cross-compiles older GCC badly

[Matthew Gabeler-Lee]

Correction: I hadn't smacked the cross-compiler build process hard
enough to get -fno-pie -no-pie into all its compile steps.  Once I hit
it with a bigger stick, that did function as a workaround for this issue
for me, albeit an ugly one.

Bug#843127: [Paul Wise] Bug#843127: notmuch: race condition in `notmuch new`?

[Jani Nikula]

On Fri, 04 Nov 2016, David Bremner  wrote:
> I wonder if this some kind of race condition in `notmuch new`
> processing.

Do you have some other software modifying your mail store while you're
running notmuch new?

BR,
Jani.

Bug#841760: firejail: Network namespace disconnect

[Reiner Herrmann]

On Sat, Nov 05, 2016 at 10:32:21AM +1300, Aidan Gauland wrote:
> >> $ w3m google.com
> >> w3m: Can't load google.com.
> > 
> > The same error occurs when only DNS is not working.
> > Can you please try pinging your default gateway?
> 
> Yes, pinging the default gateway works just fine with 0% packet loss
> (tested with 20 packets).

Interesting, then I assume pinging an external IP address also works
(like 8.8.8.8)?  Can you check /etc/resolv.conf if a valid nameserver
is configured?

I saw that you are running rdnssd, which might overwrite
/etc/resolv.conf.


signature.asc
Description: Digital signature

Bug#841760: firejail: Network namespace disconnect

[Aidan Gauland]

On 05/11/16 06:05, Reiner Herrmann wrote:
> 
> Unfortunately I was not yet able to reproduce this behavior.
> 
>> $ w3m google.com
>> w3m: Can't load google.com.
> 
> The same error occurs when only DNS is not working.
> Can you please try pinging your default gateway?

Yes, pinging the default gateway works just fine with 0% packet loss
(tested with 20 packets).

>> The only possibly relevant changes to my system that I can think of
>> (even after
>> consulting system logs) is that this occurred after I removed the package
>> iptables-persistent, but reinstalling this did not resolve the problem.
> 
> iptables is only necessary if you use --netfilter.

I still have iptables installed, but my thinking here was that changes
to the host's netfilter may interfere with the sandboxes.

> Are you using any network managers? Could you please list the processes
> running on the host?

I am 99% sure I am not running a network manager, but of course
(`ps -ef` output attached).

Regards,
Aidan
UIDPID  PPID  C STIME TTY  TIME CMD
root 1 0  0 Nov03 ?00:00:00 /sbin/init
root 2 0  0 Nov03 ?00:00:00 [kthreadd]
root 3 2  0 Nov03 ?00:00:00 [ksoftirqd/0]
root 4 2  0 Nov03 ?00:00:00 [kworker/0:0]
root 5 2  0 Nov03 ?00:00:00 [kworker/0:0H]
root 7 2  0 Nov03 ?00:00:00 [rcu_sched]
root 8 2  0 Nov03 ?00:00:00 [rcu_bh]
root 9 2  0 Nov03 ?00:00:00 [migration/0]
root10 2  0 Nov03 ?00:00:00 [lru-add-drain]
root11 2  0 Nov03 ?00:00:00 [watchdog/0]
root12 2  0 Nov03 ?00:00:00 [cpuhp/0]
root13 2  0 Nov03 ?00:00:00 [cpuhp/1]
root14 2  0 Nov03 ?00:00:00 [watchdog/1]
root15 2  0 Nov03 ?00:00:00 [migration/1]
root16 2  0 Nov03 ?00:00:00 [ksoftirqd/1]
root18 2  0 Nov03 ?00:00:00 [kworker/1:0H]
root19 2  0 Nov03 ?00:00:00 [cpuhp/2]
root20 2  0 Nov03 ?00:00:00 [watchdog/2]
root21 2  0 Nov03 ?00:00:00 [migration/2]
root22 2  0 Nov03 ?00:00:00 [ksoftirqd/2]
root24 2  0 Nov03 ?00:00:00 [kworker/2:0H]
root25 2  0 Nov03 ?00:00:00 [cpuhp/3]
root26 2  0 Nov03 ?00:00:00 [watchdog/3]
root27 2  0 Nov03 ?00:00:00 [migration/3]
root28 2  0 Nov03 ?00:00:00 [ksoftirqd/3]
root30 2  0 Nov03 ?00:00:00 [kworker/3:0H]
root31 2  0 Nov03 ?00:00:00 [kdevtmpfs]
root32 2  0 Nov03 ?00:00:00 [netns]
root33 2  0 Nov03 ?00:00:00 [khungtaskd]
root34 2  0 Nov03 ?00:00:00 [oom_reaper]
root35 2  0 Nov03 ?00:00:00 [writeback]
root36 2  0 Nov03 ?00:00:00 [kcompactd0]
root38 2  0 Nov03 ?00:00:00 [ksmd]
root39 2  0 Nov03 ?00:00:00 [khugepaged]
root40 2  0 Nov03 ?00:00:00 [crypto]
root41 2  0 Nov03 ?00:00:00 [kintegrityd]
root42 2  0 Nov03 ?00:00:00 [bioset]
root43 2  0 Nov03 ?00:00:00 [kblockd]
root44 2  0 Nov03 ?00:00:00 [devfreq_wq]
root45 2  0 Nov03 ?00:00:00 [watchdogd]
root48 2  0 Nov03 ?00:00:00 [kswapd0]
root49 2  0 Nov03 ?00:00:00 [vmstat]
root63 2  0 Nov03 ?00:00:00 [kthrotld]
root64 2  0 Nov03 ?00:00:00 [ipv6_addrconf]
root70 2  0 Nov03 ?00:00:00 [deferwq]
root   113 2  0 Nov03 ?00:00:00 [acpi_thermal_pm]
root   114 2  0 Nov03 ?00:00:00 [ata_sff]
root   115 2  0 Nov03 ?00:00:00 [kpsmoused]
root   177 2  0 Nov03 ?00:00:00 [scsi_eh_0]
root   178 2  0 Nov03 ?00:00:00 [scsi_tmf_0]
root   179 2  0 Nov03 ?00:00:00 [scsi_eh_1]
root   180 2  0 Nov03 ?00:00:00 [scsi_tmf_1]
root   181 2  0 Nov03 ?00:00:00 [scsi_eh_2]
root   182 2  0 Nov03 ?00:00:00 [scsi_tmf_2]
root   183 2  0 Nov03 ?00:00:00 [scsi_eh_3]
root   184 2  0 Nov03 ?00:00:00 [scsi_tmf_3]
root   185 2  0 Nov03 ?00:00:00 [scsi_eh_4]
root   186 2  0 Nov03 ?00:00:00 [scsi_tmf_4]
root   187 2  0 Nov03 ?00:00:00 [scsi_eh_5]
root   188 2  0 Nov03 ?00:00:00 [scsi_tmf_5]
root   195 2  0 Nov03 ?00:00:00 [bioset]
root   196 2  0 Nov03 ?00:00:00 [bioset]
root   197 2  0 Nov03 ?00:00:00 [bioset]
root   201 2  0 Nov03 ?00:00:00 [kworker/0:1H]
root   216 2  0 Nov03 ?00:00:00 [md]
root   233 2  0 Nov03 ?

Bug#843032: Now this issue hit backports

[Rainer Dorsch]

Hi,

I see now the same issue within backports:

blackbox:~# apt-get upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  ffmpeg libavdevice57 libavfilter6 libavformat57 librecad librecad-data
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up qemu-user-static (1:2.7+dfsg-3~bpo8+1) ...
update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
Invalid argument
update-binfmts: warning: unable to enable binary format qemu-mips
update-binfmts: exiting due to previous errors
dpkg: error processing package qemu-user-static (--configure):
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 qemu-user-static
E: Sub-process /usr/bin/dpkg returned an error code (1)
blackbox:~# 

on a stable system.

Since it breaks the package on stable-backports I would think the severity of 
the issue should be raised, such that apt-listbugs has a chance to report it.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#843201: spamassassin: @@LOCAL_RULES_DIR@@ not expanded in configuration files

[Christoph Biedl]

Source: spamassassin
Version: 3.4.1-5.1
Severity: minor

Dear Maintainer,

the files in /usr/share/spamassassin/*.cf contain the following remark:

| # Please don't modify this file as your changes will be overwritten with
| # the next update. Use @@LOCAL_RULES_DIR@@/local.cf instead.

It would be nice if @@LOCAL_RULES_DIR@@ was replaced with the actual
directory during build.

Christoph

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

Kernel: Linux 4.4.27 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect



signature.asc
Description: Digital signature

Bug#843194: chirp: running chirp as non-root

[Colin Tuckley]

On 04/11/16 19:55, Arturo Borrero Gonzalez wrote:
> Package: chirp
> Version: 1:20160717-1
> Severity: normal

> I'm running into problems using chirp as a non-root user.
> 
> When it comes to read/write from an usb connected walkie-talkie, chirp
> complains about wrong permissions and refuses to work.
> 
> Perhaps I need additional permission configuration in my machine.

As it says in the manual - to use chirp with a serial port (which is
what you are doing via the USB connection) your user needs to be a
member of the 'dialout' group.

73, Colin

Bug#843200: prosody: Please provide 0.9.11

[Alexander Dahl]

Package: prosody
Version: 0.9.10-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

upstream released 0.9.11 containing several bugfixes. Especially #648
is annoying in our setup here. See the release announcement:

https://prosody.im/doc/release/0.9.11

Thanks and greets
Alex

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

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

Versions of packages prosody depends on:
ii  adduser 3.115
ii  libc6   2.24-5
ii  libidn111.33-1
ii  libssl1.0.2 1.0.2j-1
ii  lua-expat [lua5.1-expat]1.3.0-3
ii  lua-filesystem [lua5.1-filesystem]  1.6.3-1
ii  lua-sec [lua5.1-sec]0.6-1
ii  lua-socket [lua5.1-socket]  3.0~rc1+git+321c0c9-1
ii  lua5.1  5.1.5-8.1+b1
ii  ssl-cert1.0.38

Versions of packages prosody recommends:
ii  lua-event [lua5.1-event]  0.4.3-2

Versions of packages prosody suggests:
pn  lua-dbi-mysql   
pn  lua-dbi-postgresql  
ii  lua-dbi-sqlite3 0.5.hg5ba1dd988961-3
ii  lua-zlib0.2+git+1+9622739-2

-- Configuration Files:
/etc/prosody/conf.avail/example.com.cfg.lua [Errno 13] Keine Berechtigung: 
u'/etc/prosody/conf.avail/example.com.cfg.lua'
/etc/prosody/conf.avail/localhost.cfg.lua [Errno 13] Keine Berechtigung: 
u'/etc/prosody/conf.avail/localhost.cfg.lua'
/etc/prosody/prosody.cfg.lua [Errno 13] Keine Berechtigung: 
u'/etc/prosody/prosody.cfg.lua'

-- no debconf information


pgpyHzE6sz1JB.pgp
Description: PGP signature

Bug#843133: transition: poco

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 04/11/16 11:26, Jochen Sprickerhof wrote:
> * Emilio Pozuelo Monfort  [2016-11-04 09:24]:
>> Do the rdeps build fine with the new version? Particularly note the recent 
>> boost
>> 1.62 change, which affects a bunch of the rdeps.
> 
> I tested all without problems (using Boost 1.62), except gpsshogi which
> FTBFS with gcc6 (#811689) and is flagged for removal (#840245).

Sounds good. Go ahead.

Maybe you can look at #841405 in exchange :)

Cheers,
Emilio

Bug#843199: perf is linked to libcrypto - licence incompatibility

[Ben Hutchings]

Package: src:linux
Version: 4.7.8-1
Severity: serious

perf uses SHA1 and MD5 implementations from OpenSSL's libcrypto if it
is found at build time.  Since perf is under GPLv2 without an OpenSSL
exception, this isn't allowed in Debian.

We need to disable this feature or substitute implementations under
another licence.

Ben.

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

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

Bug#843198: gcc-6: Cross-compiles older GCC badly

[Matthew Gabeler-Lee]

Package: gcc-6
Version: 6.2.0-11
Severity: normal

I'm working on a project that uses a Linaro gcc 4.8.3 cross compiler for
ARM, which I'm building on my Debian desktop.

As of gcc-6 6.2.0-6, this worked fine.

As of gcc-6 6.2.0-10, a subtly bad cross-compiler seems to be generated.  My
build is failing in an area related to precompiled headers:

cc1: warning: /path/to/foo.h.gch: had text segment at different address 
[enabled by default]
cc1: error: one or more PCH files were found, but they were invalid
cc1: fatal error: /path/to/foo.h: No such file or directory

I confirmed that if I downgrade all the binary packages I have installed
from the gcc-6 source to 6.2.0-6 and rebuild, things work again.

Scanning the changelogs, I came upon the idea that the default enabling of
-fPIE/-pie in 6.2.0-7 might have something to do with this, so I switched to
that version and tried again, and it failed, so at the very least the
problem is something that came in between the -6 and -7 releases.

Rebuilding the cross-toolchain with -fno-PIE -no-pie produced linker errors
complaining that it needed -fPIC, and rebuilding with -fno-PIE -no-pie -fPIC
produced the same errors, so I don't know what to do now :(

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

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

Versions of packages gcc-6 depends on:
ii  binutils  2.27.51.20161102-1
ii  cpp-6 6.2.0-6
ii  gcc-6-base6.2.0-6
ii  libc6 2.24-5
ii  libcc1-0  6.2.0-6
ii  libgcc-6-dev  6.2.0-6
ii  libgcc1   1:6.2.0-6
ii  libgmp10  2:6.1.1+dfsg-1
ii  libisl15  0.17.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.5-1
ii  libstdc++66.2.0-6
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-5

Versions of packages gcc-6 suggests:
ii  gcc-6-doc 6.1.0-1
pn  gcc-6-locales 
pn  gcc-6-multilib
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#823706: [Pkg-pascal-devel] Bug#823706: Bug#823706: lazarus opengl

[Abou Al Montacir]

Hi All,

On Fri, 2016-11-04 at 14:40 +0100, Michalis Kamburelis wrote:
> "2016-11-04 9:47 GMT+01:00 Paul Gevers :
> > I don't know how to build the component without a Makefile(.fpc). Would
> > it be sufficient (a little hackish) for now (as you mention a wizard) to
> > just make sure that the *.lpk are included (in lcl-units-1.6 as the
> > other lpk files)?
> 

> The way to compile Lazarus package is either to use Lazarus GUI, or
> (from command-line) just call the "lazbuild xxx.lpk". This will call
> fpc with appropriate options underneath.
Michalis explained it well!
> 
That being said, simply providing sources for these packages, and
> making sure they compile "out of the box" with the current Lazarus +
> FPC in Debian, would be probably enough for practical uses. You can
> test it e.g. by compiling Castle Game Engine package in
> "packages/castle_components.lpk" -- it has the "LazOpenGLContext"
> package in it's dependencies. If it compiles OK, you should be able to
> compile any LCL-based example in the engine, like
> "examples/lazarus/model_3d_viewer/model_3d_viewer.lpi".
> 
All these files (applications and packages, *.lpi and *.lpk) can be
> either compiled from GUI, or using the "lazbuild" from command-line.
> 
Please note that *.lpk files should be included in binary packages not in source
one because they are mandatory for lazarus to resolve dependencies and paths of
ppu files as explained one by Mattias Gaertner.
-- 
Cheers,
Abou Al Montacir

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

Bug#843197: FIxed by installing package baloo

[Christopher Bachner]

balooctl is not available either. Installing baloo will fix this issue. So
it probably needs to be made part of kde-full.

Bug#843197: kde-full: Baloo is not installed with kde-full

[Chris]

Package: kde-full
Version: 5:91
Severity: important



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

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

Versions of packages kde-full depends on:
ii  kde-plasma-desktop  5:91
ii  kde-standard5:91
ii  kdeadmin4:15.08.0+5.91
ii  kdeartwork  4:15.08.3-2
ii  kdeedu  4:15.08.0+5.91
ii  kdegames4:15.08.0+5.91
ii  kdegraphics 4:15.08.0+5.91
ii  kdemultimedia   4:15.08.0+5.91
ii  kdenetwork  4:15.08.0+5.91
ii  kdepim  4:16.04.3-2
ii  kdeutils4:15.08.0+5.91

Versions of packages kde-full recommends:
ii  kdeaccessibility  4:15.08.0+5.91
ii  kdesdk4:15.08.0+5.91
ii  kdetoys   4:15.08.0+5.91
ii  kdewebdev 4:16.04.3-1

Versions of packages kde-full suggests:
pn  calligra  
pn  kde-l10n  
ii  xorg  1:7.7+16

-- no debconf information!

Bug#843196: pythonmagick: FTBFS: can't identify Python 3 support library

[Aaron M. Ucko]

Source: pythonmagick
Version: 0.9.14-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Automated builds of pythonmagick have been failing; for some reason,
configure hasn't been able to identify an appropriate Boost.Python
support library for Python 3.5, leading to a linker error.  It may be
relevant that the autobuilders are using Boost 1.62 (the current
default in unstable), whereas your original amd64 build was against
Boost 1.61.

Could you please take a look?

Thanks!

Here's excerpted build output from arm64:

I: pybuild base:184: dh_auto_configure --buildsystem=autoconf 
--builddirectory="/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build" -- 
--disable-silent-rules --disable-static --with-python-min-version=3.5
   ../../../configure --build=aarch64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/aarch64-linux-gnu 
--libexecdir=\${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules --disable-static 
--with-python-min-version=3.5
[...]
checking for Python library path... -L/usr/lib -lpython3.5m
[...]
checking whether the Boost::Python library is available... yes
checking for exit in -lboost_python-py27... no
checking for exit in -lboost_python-py27... (cached) no
checking for exit in -lboost_python-py27... (cached) no
checking for exit in -lboost_python-py35... no
checking for exit in -lboost_python-py35... (cached) no
checking for exit in -lboost_python-py35... (cached) no
checking for exit in -lboost_python... no
checking for exit in -lboost_python... (cached) no
checking for exit in -lboost_python... (cached) no
checking for exit in -lboost_python... (cached) no
[...]
/bin/bash ./libtool  --tag=CXX   --mode=link g++  -g -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat 
-Werror=format-security -DBOOST_PYTHON_DYNAMIC_LIB -I/usr/include/python3.5m 
-avoid-version -module -L/usr/lib/aarch64-linux-gnu -Wl,-z,relro -o 
_PythonMagick.la -rpath /usr/lib/python3.5/site-packages/PythonMagick  
pythonmagick_src/libpymagick.la helpers_src/libhelper.la 
-L/usr/lib/aarch64-linux-gnu -l -lMagick++-6.Q16 -lMagickWand-6.Q16 
-lMagickCore-6.Q16  
libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/aarch64-linux-gnu/6/../../../aarch64-linux-gnu/crti.o 
/usr/lib/gcc/aarch64-linux-gnu/6/crtbeginS.o  -Wl,--whole-archive 
pythonmagick_src/.libs/libpymagick.a helpers_src/.libs/libhelper.a 
-Wl,--no-whole-archive  -L/usr/lib/aarch64-linux-gnu -l 
/usr/lib/aarch64-linux-gnu/libMagick++-6.Q16.so 
/usr/lib/aarch64-linux-gnu/libMagickWand-6.Q16.so 
/usr/lib/aarch64-linux-gnu/libMagickCore-6.Q16.so 
-L/usr/lib/gcc/aarch64-linux-gnu/6 
-L/usr/lib/gcc/aarch64-linux-gnu/6/../../../aarch64-linux-gnu 
-L/usr/lib/gcc/aarch64-linux-gnu/6/../../../../lib -L/lib/aarch64-linux-gnu 
-L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/aarch64-linux-gnu/6/../../.. 
-lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/aarch64-linux-gnu/6/crtendS.o 
/usr/lib/gcc/aarch64-linux-gnu/6/../../../aarch64-linux-gnu/crtn.o  -g -O2 
-fstack-protector-strong -Wl,-z -Wl,relro   -fopenmp -pthread -Wl,-soname 
-Wl,_PythonMagick.so -o .libs/_PythonMagick.so
/usr/bin/ld: cannot find -l/usr/lib/aarch64-linux-gnu/libMagick++-6.Q16.so
collect2: error: ld returned 1 exit status
Makefile:555: recipe for target '_PythonMagick.la' failed
make[2]: *** [_PythonMagick.la] Error 1

-- 
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#822699: Fix for the libucimf FTBFS

[Adrian Bunk]

Control: tags -1 patch

What broke the build is that gcc 6 changed the default C++ standard
from C++98 to C++14.

Not all valid C++98 code is also valid C++11 and C++14 code.

Note that this just changed the default, when told to process C++98 code 
gcc 6 does not differ in any significant way from gcc 5.

Making the code compatible with C++14 would be the best possible 
solution, but as a workaround it is possible to fix the build with
this change to tell gcc that this is C++98 code.


--- debian/rules.old2016-11-04 20:08:33.0 +
+++ debian/rules2016-11-04 20:09:12.0 +
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
+export DEB_CXXFLAGS_MAINT_APPEND = -std=gnu++98
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-z,defs -Wl,--as-needed 
-Wl,--no-undefined
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 


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#832297: closed by Mike Hommey <gland...@debian.org> (Bug#832297: fixed in firefox 49.0-5)

[Laurent Bigonville]

Le 29/10/16 à 17:00, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the firefox package:

#832297: firefox: Please add symbolic icon

It has been closed by Mike Hommey .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Mike Hommey 
 by
replying to this email.


Thanks for adding the symbolic icon.

Just a small remark, the icon shipped by Fedora is bit bigger and looks 
better in gnome-shell.

Bug#821530: Fix from Ubuntu for sparkline-php

[Adrian Bunk]

Control: tags -1 patch

The fix I found in Ubuntu for this bug is attached.

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

diff -pruN 0.2-5/debian/control 0.2-5ubuntu1/debian/control
--- 0.2-5/debian/control	2011-04-29 14:17:08.0 +
+++ 0.2-5ubuntu1/debian/control	2016-04-02 00:44:52.0 +
@@ -10,7 +11,7 @@ Homepage: http://sparkline.org/
 
 Package: libsparkline-php
 Architecture: all
-Depends: ${misc:Depends}, php5-gd | php4-gd
+Depends: ${misc:Depends}, php-gd
 Description: sparkline graphing library for php
  A library for php, to create sparklines. Sparklines are small word-size 
  graphic charts. This library supports drawing both line charts and bar

Bug#843160: udev: systemd-udevd times out

[Sven Joachim]

On 2016-11-04 14:40 +0100, Sven Joachim wrote:

> On 2016-11-04 13:23 +0100, Sven Joachim wrote:
>
>> Package: udev
>> Version: 232-1
>> Severity: important
>>
>> Upon upgrading from 231-10, systemd-udevd.service times out.  Systemd
>> tries to restart it in an endless loop, but to no avail.
>> [...]
>> Architecture: i386 (x86_64)
>
> It looks like this combination is what does not work.  When I tried to
> reboot with the Debian 4.8.0-1-amd64 kernel, systemd-journald failed to
> start, causing the boot to hang (I didn't write down the exact error
> message, sorry).  Since I did not have any 32-bit kernel at hand, this
> was rather embarrassing.  I finally resorted to booting with
> init=/bin/bash and downgrading all systemd packages to 231-10.

This was red herring, after installing and booting the 4.8.0-1-686-pae
kernel I observed exactly the same problem when upgrading systemd and
udev again.  I can also confirm that there is no problem on an amd64
system, as observed in https://github.com/systemd/systemd/issues/4575.

Cheers,
   Sven

Bug#693945: raising severity

[Noah Meyerhans]

Control: severity 693945 important
Control: severity 831848 important

Per discussion among the cloud team, I'm raising these bugs to
important. We want to be sure we release stretch with at least basic
support for the cloud.debian.org pseudopackage.

noah



signature.asc
Description: PGP signature

Bug#843195: chirp: please upgrade to upstream release 201611xx

[Arturo Borrero Gonzalez]

Package: chirp
Version: 1:20160717-1
Severity: wishlist
Tags: upstream

Dear maintainers,

your work with the chirp package is really appreciated, I use it a lot for
my walkie-talkies.

Would you please package for debian upstream release 201611xx?

thanks, best regards.

Bug#843194: chirp: running chirp as non-root

[Arturo Borrero Gonzalez]

Package: chirp
Version: 1:20160717-1
Severity: normal

Dear maintainers, thanks for your work with chirp, it's really
appreciated.

I'm running into problems using chirp as a non-root user.

When it comes to read/write from an usb connected walkie-talkie, chirp
complains about wrong permissions and refuses to work.

Perhaps I need additional permission configuration in my machine.

Anyway, any hint?

thanks, best regards.

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

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

Versions of packages chirp depends on:
ii  python-gtk2  2.24.0-5.1
ii  python-libxml2   2.9.4+dfsg1-2
ii  python-libxslt1  1.1.29-2
ii  python-serial3.1.1-1
pn  python:any   

chirp recommends no packages.

chirp suggests no packages.

-- no debconf information

Bug#843193: Systemd notify does not work in s3ql

[Michaël Marchegay]

Package: s3ql

Version: 2.11.1+dfsg-3.1


In jessie, s3ql.mount does not send send notification to systemd even
if python3-systemd is installed.


After applying the patch bellow (taken upstream), notification are
actually sent :


diff -r -u5 a/src/s3ql/mount.py b/src/s3ql/mount.py
--- a/src/s3ql/mount.py 2016-11-04 20:30:10.763791775 +0100
+++ b/src/s3ql/mount.py 2016-11-04 20:30:56.564020273 +0100
@@ -39,11 +39,11 @@
 import time
 import shutil
 import atexit

 try:
-import systemd.daemon.notify as sd_notify
+from systemd.daemon import notify as sd_notify
 except ImportError:
 sd_notify = None

 log = logging.getLogger(__name__)




Regards,

Michael

Bug#842497: krb5: [INTL:de] German translation is missing

[Sam Hartman]

> "Chris" == Chris Leick  writes:

Chris> Package: krb5 Version: 1.14.3+dfsg Severity: minor Tags: l10n


Chris> Hi,

Chris> I've seen, that the German translation isn't included in
Chris> version 1.14.3. Is there an issue with the translated file?
Chris> Please let me know, if I can help. The translation was sent
Chris> with Bug 816548.

Hi.
As best I can tell we're shipping src/po/de.po in our builds.
Is it possiblee that the issue is we're shipping the German translations
but not using them?
I am testing a fix if that's the case.

Bug#827199: hfst: FTBFS: twolc test fails on big-endian systems

[Jonathan Wiltshire]

Hi,

On Sat, Oct 01, 2016 at 06:42:04PM +0200, Emilio Pozuelo Monfort wrote:
> On Wed, 15 Jun 2016 17:03:20 +0200 Tino Didriksen  wrote:
> > On 13 June 2016 at 18:00, Aaron M. Ucko  wrote:
> > 
> > > Justification: fails to build from source (but built successfully in the
> > > past)
> > >
> > > Thanks for taking care of the twolc errors I reported in #826659.  The
> > > twolc test now succeeds on little-endian systems, and no longer hangs
> > > anywhere, but still fails on big-endian architectures (mips, powerpc,
> > > s390x, and several non-release architectures).  I don't have further
> > > details, but perhaps you can reproduce the problem on a porterbox.
> > > Could you please take a look?
> > 
> > 
> > Can reproduce. Looking into it upstream:
> > https://github.com/hfst/hfst/issues/328
> > 
> > While it did successfully build in the past, that was only because the test
> > suite was disabled until recently. The tests revealed the unsigned char
> > issue which was easy to fix, and now the endian issue which will not be as
> > easy.

Any news?

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#805268: Bug #805268: ITA: syslinux -- collection of bootloaders (DOS FAT and NTFS bootloader)

[Christian Seiler]

X-Debbugs-Cc: debian-de...@lists.debian.org
Control: owner -1 !
Control: retitle -1 ITA: syslinux -- collection of bootloaders (DOS FAT and 
NTFS bootloader)

On Mon, 16 Nov 2015 08:29:30 + Mattia Rizzolo  wrote:
> Some information about this package:
> 
> Homepage: http://www.syslinux.org/
> Package: syslinux
> Architecture: amd64 i386 x32
> Description: collection of bootloaders (DOS FAT and NTFS bootloader)
>  syslinux is a suite of bootloaders, currently supporting DOS FAT and NTFS
>  filesystems (SYSLINUX), Linux ext2/ext3/ext4, btrfs, and xfs filesystems
>  (EXTLINUX), PXE network boots (PXELINUX), or ISO 9660 CD-ROMs (ISOLINUX).
>  .
>  This package contains the bootloader for DOS FAT and NTFS filesystems
>  (SYSLINUX).

I intend to adopt this package in the near future.

Regards,
Christian

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

I looked at it briefly, but had to refocus on  other issues before I
could really get anywhere. I'll get it sorted out and/or forwarded
shortly.

Thanks for the ping!

On Thu, Nov 03, 2016 at 04:10:27PM -0400, Sandro Tosi wrote:
> On Mon, 8 Aug 2016 13:24:48 + Mattia Rizzolo  wrote:
> > source: xerces-c
> > version: 3.1.3+debian-2.1
> > severity: serious
> >
> > Dear maintainer,
> >
> > your package failed to build on buildds on the s390x architecure only
> > during a rebuild for the transition to icu57, using gcc6 as compiler.
> > You can see the build log at:
> > https://buildd.debian.org/status/fetch.php?pkg=xerces-c=s390x=3.1.3%2Bdebian-2.1%2Bb1=1470418530
> 
> Hey William, did you have a chance to look at this bug? i couldnt find
> much on the upstream bug tracker but there is also a 3.1.4 new release
> you might want to test if fixes this bug else report it upstream.
> thanks!!

Bug#843192: FTBFS on armel: 'check_qcurves' failed

[Jonathan Wiltshire]

Source: eclib
Version: 20160720-1
Severity: serious
Justification: FTBFS, but did so in the past

Hi,

During a rebuild for the pari transition, eclib failed its tests on armel:

| Testing mmattest...
| 3c3
| < egr bound = -8.66631e-40
| ---
| > egr bound = 0
| Makefile:1293: recipe for target 'check_qcurves' failed
| make[3]: *** [check_qcurves] Error 1
 
Full build log: 
https://buildd.debian.org/status/fetch.php?pkg=eclib=armel=20160720-1%2Bb1=1478267433


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

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

Bug#842496: [PKG-Openstack-devel] Bug#842496: Bug#842496: Bug#842496: closed by Thomas Goirand <z...@debian.org> (Re: neutron-fwaas-common: Missing /usr/bin/neutron-fwaas-l3-agent 'binary')

[Thomas Goirand]

On 11/04/2016 12:28 PM, Turbo Fredriksson wrote:
> Even though this is Unstable, that package (or rather the issues with 
> upgrades) will
> eventually end up in Stable.
> 
> So if a minor upgrade(s) between versions don’t work in Unstable, imagine the
> problem that will come when Stable becomes a new/other Stable!

Upstream does *not* support "jumping" version. The reason is because
alembic migration code also imports code from the release. So until we
have Bikesheds in Debian, upgrade from old-stable to stable is simply
impossible.

> I’ve had _SERIOUS_ problem with upstream documentation in the past, and I 
> probably
> alienated myself from most of the community because of it. But, and I’ve said 
> that
> before, “blaming upstream” is not how we should do it..

I haven't said we should blame upstream, but that docs should be written
there first. But I'm not 100% sure that's the place, and probably the
Debian package is the right place to talk about package upgrade.

> But in this specific case, what _REALLY_ pisses me of is that “no-one” (and 
> feel free
> to blame this on upstream - I do :) seems to give a F on this change being 
> done
> between minor versions! It should ONLY have been allowed into a major 
> version!!

This really is the case that it happened between major versions. If it
happened between b1, b2, b3, rc1 and final, that's during the dev cycle
of Newton, so that's what I'd say match a major version.

Never the less, you're right. :)

> I’m going to take some (a lot actually I guess) of the “blame” here. My 
> upgrade
> was unintentional. I’m not going to blame you for pushing a new version of
> OS (Newton) to Sid when I was pretty happy running Mitaka. You did your
> job, Sid is exactly the place for this. Although.. It might have been better 
> to
> push it to Experimental and let it roost there for a few months, then mention
> the upcoming upgrade of Sid on the list and “elsewhere” well in advance..

The normal workflow is to push all to Experimental until the day of the
release, where all of it is pushed to Sid. So far, I always have been
able to run tempest successfully on the RC versions before the releases,
which makes me confident enough that the new release is working. The
release dates for OpenStack are documented here:

https://releases.openstack.org/

> But to learn something from this, push it to Experimental first, then mention
> it on the list, THEN push it to Sid.. ??

You're now aware of the workflow, so I guess it wont be a surprise for
you next time. Though next time, we'll have Stretch frozen, so I'm not
sure if I'll be able to upload Ocata to Sid though...

> Or maybe you did, and I didn’t bother paying attention :).

I just make the assumption that users know already because they've been
following what happened before. Maybe the process should be documented
somewhere in https://wiki.debian.org/OpenStack/

> And I fully realise (and accept) that your time is no less valued than mine 
> and
> we all have many things on our plate and there’s to few hours in the day :(.

OpenStack in Debian is currently maintained mostly by me only, with
Ondrej doing Swift, and Canonical only helping for Python modules (ie:
not on the services). Considering the amount of work that there's to do
on each release, if we want improvements on the documentation side of
the packages, it is my view that we need more contributors.

>> "Earlier the FWaaS agent integrated with the L3 agent by having the L3
>> Agent class inherit from the FWaaS Agent class. This meant that other
>> service agents could not also integrate with the L3 agent. Now, using
>> the L3 agent extensions mechanism, FWaaS (v1 and v2) plugs in to the L3
>> agent. This means that it can interoperate peacefully with other L3
>> advanced services that also implement the L3 agent extension mechanism,
>> all without any code changes to Neutron."
>>
>> OpenStack users should read these before upgrading. But like for Debian,
>> users don't read the release notes... :)
> 
> This is exactly what I mean!! Even _IF_ I had read that before hand, I would
> be absolutely clueless to what to do!! That is a very valid excuse and reason
> for doing the change, there’s no question there! However, there is absolutely
> NO information on what to actually DO!

I've been thinking about the issue, and I now think part of the fix
should be this:

https://review.openstack.org/393917

(ie: the now transitional package neutron-fwaas-l3-agent runtime depends
on neutron-l3-agent)

I first need to fix the build CI though, so if it currently fails to
build in OpenStack infra, that's because we need to finish fixing the
issues related to the latest sbuild upload in jessie-backports.

It would still need manual neutron.conf tweaks though.

> Yeah, I "wish I had the time” :D. But even if I did, I don’t have neither the
> experience nor the knowledge to help :(. All I can do is let you know of my
> experiences when I’m “kicked in the jewels” as it where 

Bug#843191: systemd-sysv-install: policy creds not carried forward

[Felipe Sateler]

On 4 November 2016 at 16:05, Ritesh Raj Sarraf  wrote:
> Package: systemd
> Version: 232-1
> Severity: normal
> File: systemd-sysv-install
>
>
> rrs@learner:/var/tmp/Debian-Build/Result$ systemctl status apport
> ● apport.service - LSB: automatic crash report generation
>Loaded: loaded (/etc/init.d/apport; generated; vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:systemd-sysv-generator(8)
> 2016-11-05 / 00:29:30 ♒♒♒  ☹  => 3
>
> rrs@learner:/var/tmp/Debian-Build/Result$ systemctl enable apport
> apport.service is not a native service, redirecting to systemd-sysv-install.
> Executing: /lib/systemd/systemd-sysv-install enable apport
> insserv: can not symlink(../init.d/apport, ../rc2.d/S01apport): Permission 
> denied
> insserv: can not symlink(../init.d/apport, ../rc3.d/S01apport): Permission 
> denied
> insserv: can not symlink(../init.d/apport, ../rc4.d/S01apport): Permission 
> denied
> insserv: can not symlink(../init.d/apport, ../rc5.d/S01apport): Permission 
> denied
> insserv: fopen(.depend.stop): Permission denied
> update-rc.d: error: no runlevel symlinks to modify, aborting!
> 2016-11-05 / 00:29:35 ♒♒♒  ☹  => 1
>
> rrs@learner:/var/tmp/Debian-Build/Result$ sudo systemctl enable apport
> [sudo] password for rrs:
> apport.service is not a native service, redirecting to systemd-sysv-install.
> Executing: /lib/systemd/systemd-sysv-install enable apport
> 2016-11-05 / 00:29:48 ♒♒♒  ☺
>
>
>
> As I understand from the logs above, systemctl gained root access
> through policykit. Then it realized that apport is not a native service.
> And then tried to invoke systemd-sysv-install. But that tool complained
> that it does not have the necessary privileges.

systemd-sysv-install is executed at the client side, not on the server
side. This is something that probably makes sense fixing upstream, as
units enabled/disabled via the bus are not synchronized with sysv
state.

-- 

Saludos,
Felipe Sateler

Bug#843190: ITP: elpa-ido-vertical-mode -- make ido-mode display vertically

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: elpa-ido-vertical-mode
  Version : 0.1.6
  Upstream Author : Steven Degutis 
* URL : https://github.com/creichert/ido-vertical-mode.el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : make ido-mode display vertically

This mode takes care of some caveats that are otherwise ugly to store in your
init file. It makes ido-mode display prospects vertically, which looks quite
nicely.

Bug#842195: patch

[Brent S. Elmer Ph.D.]

I have found a fix thanks to Tibor Boesze.  He fixed an older version
of Ubuntu so I applied the fix to debian.  The only change is in 
/auth-dialog/main.c.

@@ -997,6 +997,7 @@ static int get_config (GHashTable *optio
    if (csd_wrapper && !csd_wrapper[0])
    csd_wrapper = NULL;

+   openconnect_set_xmlpost(vpninfo, 0);
    openconnect_setup_csd(vpninfo, getuid(), 1, OC3DUP
(csd_wrapper));
    }


His comments were 
* Do not attempt to post XML authentication requests when a cds
 wrapper is configured.

I have never made a patch before but I tried.  I will attach my attempt
at a patch.

Once I make the small change, network-manager-openconnect connects to
my vpn.

I am guessing that the change above is doing what 
--no-xmlpost is doing in the openconnect command line connection that
works.Description: 
 network-manager-openconnect (1.2.2+nxp1) UNRELEASED; urgency=medium
 .
   * Non-maintainer upload.
   * Do not attempt to post XML authentication requests when a cds
 wrapper is configured.
Author: Tibor Bősze 

 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 network-manager-openconnect (1.2.2-1) unstable; urgency=medium
 .
   [ Aron Xu ]
   * New upstream release.
 .
   [ Mike Miller ]
   * Add dependency on network-manager (>= 1.2) to ensure non-absolute
 plugin paths are handled.
   * No longer need to build with configure option --enable-absolute-
 paths.
Author: Mike Miller 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2016-11-04

--- network-manager-openconnect-1.2.2.orig/auth-dialog/main.c
+++ network-manager-openconnect-1.2.2/auth-dialog/main.c
@@ -418,7 +418,7 @@ static gboolean ui_add_select (ui_fragme
if (g_queue_peek_tail(ui_data->form_entries) == data)
gtk_widget_grab_focus (combo);
g_signal_connect(G_OBJECT(combo), "changed", G_CALLBACK(combo_changed), 
data);
-   /* Hook up the 'show' signal to ensure that we override prompts on
+   /* Hook up the 'show' signal to ensure that we override prompts on
   UI elements which may be coming later. */
g_signal_connect(G_OBJECT(combo), "show", G_CALLBACK(combo_changed), 
data);

@@ -524,7 +524,7 @@ static gboolean ui_form (struct oc_auth_
data = g_slice_new0 (ui_fragment_data);
data->ui_data = ui_data;
data->opt = opt;
-
+
if (opt->type == OC_FORM_OPT_PASSWORD ||
opt->type == OC_FORM_OPT_TEXT) {
g_mutex_lock (_data->form_mutex);
@@ -567,7 +567,7 @@ static gboolean ui_form (struct oc_auth_
} else
g_slice_free (ui_fragment_data, data);
}
-
+
return ui_show(ui_data);
 }

@@ -981,7 +981,7 @@ static int get_config (GHashTable *optio

openconnect_set_xmlsha1 (vpninfo, (char *)sha1_text, 
strlen(sha1_text) + 1);
g_checksum_free(sha1);
-
+
parse_xmlconfig (config_str);
}

@@ -997,6 +997,7 @@ static int get_config (GHashTable *optio
if (csd_wrapper && !csd_wrapper[0])
csd_wrapper = NULL;

+   openconnect_set_xmlpost(vpninfo, 0);
openconnect_setup_csd(vpninfo, getuid(), 1, OC3DUP 
(csd_wrapper));
}

@@ -1528,7 +1529,7 @@ static auth_ui_data *init_ui_data (char

 #if OPENCONNECT_CHECK_VER(1,4)
openconnect_set_cancel_fd (ui_data->vpninfo, ui_data->cancel_pipes[0]);
-#endif
+#endif

 #if 0
ui_data->vpninfo->proxy_factory = px_proxy_factory_new();

Bug#843167: bash: when called as 'sh' interprets backslash in single quotes

[Bob Proulx]

Leszek Dubiel wrote:
> Dear Maintainer, :)

Note that I am not the maintainer but another long time shell user.

> Create file /tmp/test that contains: 
> 
>   echo 'a\nb'

Use of the echo command with escape sequences is inherently
non-portable behavior.  See the bash FAQ item E5.

  http://tiswww.case.edu/php/chet/bash/FAQ

Also there are endless mailing list discussions on this behavior that
argues both directions.  It is non-portable behavior.  It has always
been different on different operating systems.

Portable scripts should never use escape sequences in echo strings.
Instead they should use printf which is standard and portable.

> Now run this two commands: 
> 
> sh /tmp/mytest
> bash /tmp/mytest
> 
> One of these commands prints two lines while other prints one line: 
>
> root@orion:/tmp# cat mytest 
> echo 'a\nb'
> root@orion:/tmp# sh ./mytest 
> a
> b
> root@orion:/tmp# bash ./mytest 
> a\nb
> root@orion:/tmp# 

At the present time that is the current expected behavior.  I see no
bug here.  Except for the bug of using escape sequences with echo.
But that is a bug in any shell script that uses it and not in either
bash or dash.

Bob

Bug#843160: udev: systemd-udevd times out

[Sven Hartge]

On 04.11.2016 19:18, Sven Hartge wrote:
> On 04.11.2016 19:11, Sven Hartge wrote:
>> On 04.11.2016 19:09, Michael Biebl wrote:
>>
>>> You kernel config would be helpful as well
>>
>> This is a stock normal Debian Kernel from Unstable as of now, i386 to be
>> precise.
> 
> Ah, this is rubbish, of course. The faulty system still has
> linux-image-4.7.0-1-amd64-4.7.2-1.

To clarify further: The system showing the problem is running a 32bit
userspace on a 64bit amd64 kernel.

The working systems are all 64bit amd64 ones.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#842503: mercurial-git: Type error when cloning https

[Christophe Troestler]

See 
https://bitbucket.org/durin42/hg-git/issues/189/hg-pull-over-https-fails-with-mercurial-39 
for a patch.

Bug#832719: this patch doesn't work

[Matthias Klose]

Control: retitle -1 dangling src.zip symlink

the proposed patch doesn't work, because the src package is a binary independent
package.

Bug#820519: sitecopy: fails to accept SSL certificates issued by a CA (Let's Encrypt)

[Francesco Poli]

On Fri, 04 Nov 2016 08:07:44 +0100 Christian Marillat wrote:

> On 02 nov. 2016 23:22, Francesco Poli  wrote:
> 
> > On Wed, 02 Nov 2016 16:44:33 +0100 Christian Marillat wrote:
> 
> [...]
> 
> >> Did you read the upstream site recently ?
> >> 
> >> http://www.manyfish.co.uk/sitecopy/
> >
> > Sorry, but what do you mean?
> >
> > I hadn't read the upstream site recently.
> > I have taken a look now: I failed to find any useful information about
> > my issue.
> >
> > Do you mean that I should notice that no new upstream version has been
> > released since 2008?
> 
> Yes.

Well, that does not imply that a bug report on the Debian BTS should be
left unanswered.

Is upstream really unresponsive?
Have you tried forwarding my bug report upstream?!?
In case upstream is indeed unresponsive, you could still fix the bug
yourself, or seek help from someone else...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpNWhWnpiJ38.pgp
Description: PGP signature

Bug#843189: ITP: prometheus-blackbox-exporter -- Prometheus exporter for blackbox monitoring

[Filippo Giunchedi]

Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi 

* Package name: prometheus-blackbox-exporter
  Version : 0.2.0+git20160930.6.8cf9605-1
  Upstream Author : Prometheus Authors
* URL : https://github.com/prometheus/blackbox_exporter
* License : Apache-2.0
  Programming Lang: Go
  Description : Prometheus exporter for blackbox monitoring

 The blackbox exporter allows blackbox probing of network endpoints over HTTP,
 HTTPS, DNS, TCP and ICMP. Additional modules can be defined to suit other 
needs.
 .
 Querying of endpoints happens via HTTP GET queries, by specifying the target
 name and what kind of probing to execute. Results from the probe are returned
 in the form of Prometheus metrics.

Bug#843160: udev: systemd-udevd times out

[Sven Hartge]

On 04.11.2016 19:17, Michael Biebl wrote:
> Am 04.11.2016 um 19:09 schrieb Michael Biebl:
> 
>> So running it manually seems to work, which makes me suspect that it is
>> one of the new confinement options, like
>>
>> MemoryDenyWriteExecute=yes
>> RestrictRealtime=yes
>> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
>>
> 
> 
> https://github.com/systemd/systemd/issues/4575
> 
> might be related

Seems like this. Trying to restart systemd-journald.service also hangs,
just like the other ones.

S°




signature.asc
Description: OpenPGP digital signature

Bug#843160: udev: systemd-udevd times out

[Michael Biebl]

Am 04.11.2016 um 19:09 schrieb Michael Biebl:

> So running it manually seems to work, which makes me suspect that it is
> one of the new confinement options, like
> 
> MemoryDenyWriteExecute=yes
> RestrictRealtime=yes
> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6
> 


https://github.com/systemd/systemd/issues/4575

might be related



signature.asc
Description: OpenPGP digital signature

Bug#843160: udev: systemd-udevd times out

[Sven Hartge]

On 04.11.2016 19:09, Michael Biebl wrote:

> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

This is the winner. Commenting this for systemd-udevd and
systemd-networkd "fixes" this bug on Linux 4.7.2.

S°



signature.asc
Description: OpenPGP digital signature

Bug#843160: udev: systemd-udevd times out

[Sven Hartge]

On 04.11.2016 19:11, Sven Hartge wrote:
> On 04.11.2016 19:09, Michael Biebl wrote:
> 
>> You kernel config would be helpful as well
> 
> This is a stock normal Debian Kernel from Unstable as of now, i386 to be
> precise.

Ah, this is rubbish, of course. The faulty system still has
linux-image-4.7.0-1-amd64-4.7.2-1.

The *working* systems have an up-to-date kernel.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#843188: ITP: freeture -- A Free software to capTure meteors

[Chiara Marmo]

Package: wnpp
Owner: Chiara Marmo 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org

* Package name: freeture
  Version : 1.1
  Upstream Author : Yoan Audureau 
* URL : https://github.com/fripon/freeture
* License : GPL-3.0
  Programming Lang: C++/C
  Description : a free software to capture meteors

FreeTure has been developed in the framework of the FRIPON project 
(www.fripon.org): it aims to detect meteors using Giga Ethernet and USB cameras.
Watec cameras are also supported via video4linux library, even if control 
options are limited by the specific digital wrapper.

I intend to maintain this package in collaboration with the Debian Astro team.

Best regards,

Chiara

Bug#783210: [PATCH] nscd_stat.c: make the build reproducible

[Ximin Luo]

Ximin Luo:
> Mike Frysinger:
>> On 28 Jul 2016 15:15, Florian Weimer wrote:
>>> On 03/09/2016 05:30 PM, Mike Frysinger wrote:
 would it be so terrible to properly marshall this data ?
>>>
>>> Ximin Luo and I discussed this and I wonder if it is possible to read 
>>> out the libc.so.6 build ID if it is present.  It should indirectly call 
>>> all the layout dependencies and be reasonably easy to access because it 
>>> is in an allocated section (and we might want to print it from an 
>>> libc.so.6 invocation, too).
>>>
>>> We still need the time-based approach if the build ID is not available, 
>>> but I expect most distributions will have something like it.
>>>
>>> The Debian bug is:
>>>
>>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783210
>>>
>>> (Also Cc:ed)
>>
>> agreed that build-id should be an acceptable replacement for what the
>> code is doing today, but in order to pull that off, i guess you'd have
>> to have to do a configure test to see if build-id is active ?  if you
>> leave the logic to runtime, you'd still need to include the datetime
>> stamp in the object which would still make the build unreproducible.
>>
>> this also doesn't really cover the quoted idea of marshalling the data
>> between client & server :).
>> -mike
>>
> 
> Hi all,
> 
> I've written a small program that prints out the Build IDs of all the objects 
> that are dynamically linked to it, plus itself.
> 
> It works well, although I'm not a C expert so I don't know if it is portable 
> enough. For example, I hard-code some >>2 <<2s in there, along with a uint8_t 
> - I didn't see a corresponding ElfW(xxx) type in elf.h
> 
> Another downside is it needs to be linked against libdl, which I think is not 
> the case currently with nscd. I'm not sure if this carries extra security 
> risk or whatever.
> 

Oh! Actually it doesn't need to be linked against libdl. That was from an 
earlier version of the code where I was using dlinfo instead of 
dl_iterate_phdr. But this latter function doesn't need extra libs. :)

> An alternative would be to detect the build-id *at build time* and then 
> monkey-patch it into the binary itself.
> 
> What do you all think? How shall I proceed?
> 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#843184: [Reportbug-maint] Bug#843184: reportbug: test

[Sandro Tosi]

use --debug

On Fri, Nov 4, 2016 at 1:20 PM, Roland Hieber  wrote:
> Package: reportbug
> Version: 6.6.3
> Severity: normal
>
> Dear Maintainer,
>
>
>
> -- Package-specific info:
> ** Environment settings:
> EDITOR="vim"
> EMAIL="roh...@rohieb.name"
> NAME="Roland Hieber"
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
> 'stable-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages reportbug depends on:
> ii  apt   1.0.9.8.3
> ii  python2.7.9-1
> ii  python-reportbug  6.6.3
> pn  python:any
>
> reportbug recommends no packages.
>
> Versions of packages reportbug suggests:
> pn  claws-mail   
> pn  debconf-utils
> ii  debsums  2.0.53
> pn  dlocate  
> pn  emacs23-bin-common | emacs24-bin-common  
> ii  file 1:5.22+15-2+deb8u2
> ii  gnupg1.4.18-7+deb8u3
> ii  postfix [mail-transport-agent]   2.11.3-1
> ii  python-gtk2  2.24.0-4
> pn  python-gtkspell  
> pn  python-urwid 
> pn  python-vte   
> ii  xdg-utils1.1.0~rc1+git20111210-7.4
>
> Versions of packages python-reportbug depends on:
> ii  apt   1.0.9.8.3
> ii  python-debian 0.1.27
> ii  python-debianbts  1.12
> pn  python:any
>
> python-reportbug suggests no packages.
>
> -- no debconf information
>
> ___
> Reportbug-maint mailing list
> reportbug-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reportbug-maint



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

Bug#843160: udev: systemd-udevd times out

[Sven Hartge]

On 04.11.2016 19:09, Michael Biebl wrote:

> You kernel config would be helpful as well

This is a stock normal Debian Kernel from Unstable as of now, i386 to be
precise.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#843187: Please correct or change the default defaultPB value

[mikey d]

Package: pastebinit
Version: 1.5


This has been a long standing issue, especially if you run a Debian variant
that is not strictly within the lsb-release calculated values.

Some backstory and a good read:
http://mewbies.com/pastebinit_how_to_pastebin_commnad_line_output_from_terminal_to_pastebin.htm


man pastebinit | pastebinit -a test
 Output: THIS API HAS BEEN DISABLED. Please use Pastebin's new API.
 http://pastebin.com/api

 This is the problem on Debian since pastebin.com is the default URL. To
 get around that either:
 1. Signup to pastebin: Pastebin.com FAQ: "Yes, we have got an API
 available, but we do require you to be a member of the website to access
 it."

 OR
 2. Use another URL. From pastebinit man:
 Select another URL (-b) ('-a test' will show as the author test):
 man pastebinit | pastebinit -a test -b http://paste.ubuntu.com
 The output is the URL where your paste is.


TL:DR - pastebin.com is not available as a public anonymous API. This
requires a login. You may argue "well, if we support Debian and it uses
paste.debian.net," that is beyond the point. The fallback URL does not
function.

-- 
Michael DeGuzis
Email: mdegu...@gmail.com
Website: http://www.libregeek.org
Linked In Resume/Profile

Projects: GitHub Projects 

Bug#843137: [buildd-tools-devel] Bug#843137: Bug#843137: sbuild: fails to deal with sid chroots (missing gpg)

[Johannes Schauer]

Hi,

Quoting Raphael Hertzog (2016-11-04 16:01:21)
> On Fri, 04 Nov 2016, Johannes Schauer wrote:
> >  2. the amount of effort required to cope with the changed situation in 
> > stretch
> > (especially with respect to gpg) is huge. The existing patches are 
> > several
> > hundred lines long. Help would indeed be appreciated to backport these
> > patches. I fought with the gnupg situation for months to get it right 
> > and
> > make things both forward and backward compatible. Lots of work is 
> > needed to
> > do this right and test everything for a stable update. Unfortunately, 
> > this
> > is time I currently don't have. I would be available though for guidance
> > for anybody who's willing to give this a go.
> 
> An easy fix might be to modifiy sbuild-createchroot to install gpg and to
> document this requirement?

as I pointed in other mails in this bug report, if you *do* sign the internal
dummy repository, then you run into loads of other problems because of changes
in gnupg2. You could of course turn off signing but then you loose support for
building in chroots with Squeeze (where apt is too old). But then, even if you
decide that squeeze is too old and we don't want to support it anymore in the
current stable, you will run into issues because gnupg is for example needed to
import apt keys or for external repositories and then you are back at the
gnupg2 incompatibilities and at making sure to kill the gnupg agent or
otherwise your schroot session cannot end. See the bugreports and commits I
listed for a good overview of all the problems.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#842939: WOT found guilty to sell user data

[Moritz Muehlenhoff]

B0;115;0cOn Fri, Nov 04, 2016 at 03:07:17AM +0100, ilf wrote:
> kpcyrd:
> >I think this project doesn't align with the debian goals and I
> >would welcome if it's getting removed from current and future
> >releases.
> 
> Mozilla removed it from addons.mozilla.org: 
> http://www.faz.net/aktuell/politik/skandal-um-datenschnueffler-mozilla-loescht-web-of-trust-erweiterung-14511304.html
> 
> I think Debian should do the same.

Ack, let's remove in the next point release.

Cheers,
Moritz

Bug#843160: udev: systemd-udevd times out

[Michael Biebl]

Am 04.11.2016 um 18:48 schrieb Sven Hartge:
> Um 14:26 Uhr am 04.11.16 schrieb Sven Hartge:
>> On 04.11.2016 14:25, Sven Hartge wrote:
> 
>> Another data point: I did the same upgrade on my Laptop, which runs
>> 4.8.0-1-amd64 #1 SMP Debian 4.8.5-1 (2016-10-28) and this problem did
>> not happen.
> 
> Here (1. attachement) is the output from /lib/systemd/systemd-udevd 
> --debug, running under Linux 4.7.2-1 , but I don't see anything unusual. 

So running it manually seems to work, which makes me suspect that it is
one of the new confinement options, like

MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6

This would explain why systemd-networkd fails as well.
Could you try and remove those options temporarily one by one to find
out if one of those options is the culprit.

You kernel config would be helpful as well



signature.asc
Description: OpenPGP digital signature

Bug#843137: [buildd-tools-devel] Bug#843137: Bug#843137: sbuild: fails to deal with sid chroots (missing gpg)

[Raphael Hertzog]

On Fri, 04 Nov 2016, Johannes Schauer wrote:
>  2. the amount of effort required to cope with the changed situation in 
> stretch
> (especially with respect to gpg) is huge. The existing patches are several
> hundred lines long. Help would indeed be appreciated to backport these
> patches. I fought with the gnupg situation for months to get it right and
> make things both forward and backward compatible. Lots of work is needed 
> to
> do this right and test everything for a stable update. Unfortunately, this
> is time I currently don't have. I would be available though for guidance
> for anybody who's willing to give this a go.

An easy fix might be to modifiy sbuild-createchroot to install gpg and to
document this requirement?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#783210: [PATCH] nscd_stat.c: make the build reproducible

[Ximin Luo]

Mike Frysinger:
> On 28 Jul 2016 15:15, Florian Weimer wrote:
>> On 03/09/2016 05:30 PM, Mike Frysinger wrote:
>>> would it be so terrible to properly marshall this data ?
>>
>> Ximin Luo and I discussed this and I wonder if it is possible to read 
>> out the libc.so.6 build ID if it is present.  It should indirectly call 
>> all the layout dependencies and be reasonably easy to access because it 
>> is in an allocated section (and we might want to print it from an 
>> libc.so.6 invocation, too).
>>
>> We still need the time-based approach if the build ID is not available, 
>> but I expect most distributions will have something like it.
>>
>> The Debian bug is:
>>
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783210
>>
>> (Also Cc:ed)
> 
> agreed that build-id should be an acceptable replacement for what the
> code is doing today, but in order to pull that off, i guess you'd have
> to have to do a configure test to see if build-id is active ?  if you
> leave the logic to runtime, you'd still need to include the datetime
> stamp in the object which would still make the build unreproducible.
> 
> this also doesn't really cover the quoted idea of marshalling the data
> between client & server :).
> -mike
> 

Hi all,

I've written a small program that prints out the Build IDs of all the objects 
that are dynamically linked to it, plus itself.

It works well, although I'm not a C expert so I don't know if it is portable 
enough. For example, I hard-code some >>2 <<2s in there, along with a uint8_t - 
I didn't see a corresponding ElfW(xxx) type in elf.h

Another downside is it needs to be linked against libdl, which I think is not 
the case currently with nscd. I'm not sure if this carries extra security risk 
or whatever.

An alternative would be to detect the build-id *at build time* and then 
monkey-patch it into the binary itself.

What do you all think? How shall I proceed?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
#define _GNU_SOURCE
#include 
#include 

int callback (struct dl_phdr_info *info, size_t size, void *data) {
  printf ("\nname: %s\n", info->dlpi_name);

  ElfW(Phdr) *phdr = (ElfW(Phdr) *) info->dlpi_phdr;
  for (ElfW(Half) i = 0; i < info->dlpi_phnum; i++) {
if (phdr->p_type == PT_NOTE) {
  ElfW(Addr) addr = info->dlpi_addr + info->dlpi_phdr[i].p_vaddr;
  ElfW(Addr) nend = addr + info->dlpi_phdr[i].p_memsz;
  //printf ("found NOTE segment at: %p to %p\n", addr, nend);

  while (addr < nend) {
	ElfW(Nhdr) *nhdr = (ElfW(Nhdr) *) addr;
	// According to the ELF spec, namesz and descsz do not include padding
	// but that's how they're laid out in memory; add the padding here.
	ElfW(Addr) nameoff = (((nhdr->n_namesz-1)>>2)+1)<<2;
	ElfW(Addr) descoff = (((nhdr->n_descsz-1)>>2)+1)<<2;

	if (nhdr->n_type == NT_GNU_BUILD_ID) {
	  const uint8_t *buf = (const uint8_t *) ((ElfW(Addr))(nhdr + 1) + nameoff);
	  printf("Build ID");
	  for (int j = 0; j < nhdr->n_descsz; j++)
	printf(":%02X", buf[j]);
	  printf("\n");
	}

	//printf("skipping section type %02X\n", nhdr->n_type);
	addr = (ElfW(Addr))(nhdr + 1) + nameoff + descoff;
  }
}

phdr += 1;
  }

  return 0;
}

int main() {
  dl_iterate_phdr(callback, NULL);
}

Bug#840329: taglib-extras: diff for NMU version 1.0.1-3.1

[Andrey Rahmatullin]

Control: tags 840329 + pending

Dear maintainer,

I've prepared an NMU for taglib-extras (versioned as 1.0.1-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
WBR, wRAR
diff -Nru taglib-extras-1.0.1/debian/changelog taglib-extras-1.0.1/debian/changelog
--- taglib-extras-1.0.1/debian/changelog	2010-11-14 20:59:01.0 +0500
+++ taglib-extras-1.0.1/debian/changelog	2016-11-04 22:47:26.0 +0500
@@ -1,3 +1,11 @@
+taglib-extras (1.0.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with taglib >= 1.10, patch from Stuart Prescott (Closes:
+#840329)
+
+ -- Andrey Rahmatullin   Fri, 04 Nov 2016 22:47:26 +0500
+
 taglib-extras (1.0.1-3) unstable; urgency=low
 
   * Remove DMUA field from debian/control. I'm a DD now.
diff -Nru taglib-extras-1.0.1/debian/patches/series taglib-extras-1.0.1/debian/patches/series
--- taglib-extras-1.0.1/debian/patches/series	1970-01-01 05:00:00.0 +0500
+++ taglib-extras-1.0.1/debian/patches/series	2016-11-04 22:47:07.0 +0500
@@ -0,0 +1 @@
+taglib-cmake-versions.patch
diff -Nru taglib-extras-1.0.1/debian/patches/taglib-cmake-versions.patch taglib-extras-1.0.1/debian/patches/taglib-cmake-versions.patch
--- taglib-extras-1.0.1/debian/patches/taglib-cmake-versions.patch	1970-01-01 05:00:00.0 +0500
+++ taglib-extras-1.0.1/debian/patches/taglib-cmake-versions.patch	2016-11-04 22:46:41.0 +0500
@@ -0,0 +1,30 @@
+Description: Fix version comparison for finding taglib
+
+Existing cmake code doesn't do the min version comparison correctly.
+
+(Closes: #840329)
+
+--- a/cmake/modules/FindTaglib.cmake
 b/cmake/modules/FindTaglib.cmake
+@@ -29,10 +29,10 @@
+ 
+   exec_program(${TAGLIBCONFIG_EXECUTABLE} ARGS --version RETURN_VALUE _return_VALUE OUTPUT_VARIABLE TAGLIB_VERSION)
+ 
+-  if(TAGLIB_VERSION STRLESS "${TAGLIB_MIN_VERSION}")
++  if(TAGLIB_VERSION VERSION_LESS "${TAGLIB_MIN_VERSION}")
+  message(STATUS "TagLib version not found: version searched :${TAGLIB_MIN_VERSION}, found ${TAGLIB_VERSION}")
+  set(TAGLIB_FOUND FALSE)
+-  else(TAGLIB_VERSION STRLESS "${TAGLIB_MIN_VERSION}")
++  else(TAGLIB_VERSION VERSION_LESS "${TAGLIB_MIN_VERSION}")
+ 
+  exec_program(${TAGLIBCONFIG_EXECUTABLE} ARGS --libs RETURN_VALUE _return_VALUE OUTPUT_VARIABLE TAGLIB_LIBRARIES)
+ 
+@@ -42,7 +42,7 @@
+ set(TAGLIB_FOUND TRUE)
+  endif(TAGLIB_LIBRARIES AND TAGLIB_CFLAGS)
+  string(REGEX REPLACE " *-I" ";" TAGLIB_INCLUDES "${TAGLIB_CFLAGS}")
+-  endif(TAGLIB_VERSION STRLESS "${TAGLIB_MIN_VERSION}") 
++  endif(TAGLIB_VERSION VERSION_LESS "${TAGLIB_MIN_VERSION}")
+   mark_as_advanced(TAGLIB_CFLAGS TAGLIB_LIBRARIES TAGLIB_INCLUDES)
+ 
+ else(TAGLIBCONFIG_EXECUTABLE)


signature.asc
Description: PGP signature