Bug#876159: setserial FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: setserial
Version: 2.17-50
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

setserial fails to cross build from source, because it configures for
the build architecture. Since the ./configure is so old, one shouldn't
pass --host, but export a suitable CC. After doing so, it cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru setserial-2.17/debian/changelog 
setserial-2.17/debian/changelog
--- setserial-2.17/debian/changelog 2017-01-22 15:39:00.0 +0100
+++ setserial-2.17/debian/changelog 2017-09-19 07:45:26.0 +0200
@@ -1,3 +1,10 @@
+setserial (2.17-50.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export a triplet-prefixed CC (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Sep 2017 07:45:26 +0200
+
 setserial (2.17-50) unstable; urgency=medium
 
   * ack NMU, thanks to Martin Pitt and Christian Hofstaedtler for
diff --minimal -Nru setserial-2.17/debian/rules setserial-2.17/debian/rules
--- setserial-2.17/debian/rules 2017-01-22 15:36:51.0 +0100
+++ setserial-2.17/debian/rules 2017-09-19 06:46:21.0 +0200
@@ -2,6 +2,10 @@
 # Copyright 1994,1995 by Ian Jackson, 1998 Christoph Lameter
 # debian/rules for setserial, by Gordon Russell.
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+export CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
 
 DESTDIR = $(CURDIR)/debian/setserial
 arch = $(shell dpkg-architecture -qDEB_BUILD_ARCH)

Bug#870618: NMU for freetype 2.8-0.3

[Hugh McMaster]

Hi Steve,

I haven't heard from you lately, so I'd like to do an NMU for freetype 2.8-0.3 
via RFS.

A diff with the package changes is attached.

Hugh


freetype_2.8-0.3-changes.diff
Description: freetype_2.8-0.3-changes.diff

Bug#876156: libcoap: Package would build fine on Jessie if debhelper dependency allowed, it

[Carsten Schoenert]

Hello Stuart,

On Tue, Sep 19, 2017 at 02:01:11PM +1000, Stuart Longland wrote:
... 
> I just tried building this package on Debian Jessie as most of our
> infrastructure still uses this release.  Out-of-the-box, it will not
> build due to the version of debhelper, however if you tell it to ignore
> this, it builds just fine.
> 
> This suggests the version of debhelper could be dropped back to what's
> available in Jessie and thus make it trivial for people to build this
> package for Debian Jessie systems without needing to tweak the Stretch
> version of the source package.

please use debhelper from jessie-backports as I don't want to switch
back the current versions of compat and debhelper to a older version
than 10.2. This was the intention by using 10.2.2~ as while working on
4.1.2 for Jessie debhelper was available with this version.

$ rmadison debhelper 
debhelper  | 9.20120909| oldoldstable   | source, all
debhelper  | 9.20150101| oldstable-kfreebsd | source, all
debhelper  | 9.20150101+deb8u2 | oldstable  | source, all
debhelper  | 10.2.5~bpo8+1 | jessie-backports   | source, all <
debhelper  | 10.2.5| stable | source, all
debhelper  | 10.8~bpo9+1   | stretch-backports  | source, all
debhelper  | 10.8  | testing| source, all
debhelper  | 10.8  | unstable   | source, all

Currently I've no plans to prepare a Jessie backported version of
libcoap, at least if not more people requesting this.

Regards
Carsten

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Alexander Wirt]

On Mon, 18 Sep 2017, Daniel Kahn Gillmor wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> pkg-gnupg-ma...@lists.alioth.debian.org currently mostly hosts bug
> reports, but it is also the maintainer address for the packages
> maintained by the GnuPG packaging team, and it hosts some discussion
> about packaging plans and questions, like the following:
This is one of the examples we will probably not accept, but we will discuss
that internally again.

Alex
 

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Control: tag -1 + patch

On Fri, 15 Sep 2017, Steve McIntyre wrote:
> >For Debian, I don't think that making such a difference makes sense.
> >We should:
> >- either always show the question with its default value of "none"
> >  (thus making sure that they have a chance to opt-in to this feature)
> >- or not show the question (priority "medium") but make it default
> >  to install unattended-upgrades so that they get updates by default but
> >  have a chance to disable that with preseeding
> >
> >Given the last discussion on -devel
> >(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
> >we should make a bold choice and do the latter.
> >
> >I'm going to submit a tested patch later on.
> 
> Sounds reasonable, yes.

Ok, so here's my set of patches. Relevant to this bug are the first and
the last one. The other commits are other random improvements that I merged
from Ubuntu that looked like useful.

I tested the attached patches on modified mini.iso where I force-injected
pkgsel and bootstrap-base (because I could not manage to get anna to
reload the modified templates if I installed the new pkgsel manually once
the installer was started up to the configure network step).

Reviews are welcome.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 07855172bf545b6c6e632b4f3c6e267b056d5862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 15 Sep 2017 11:29:00 +0200
Subject: [PATCH 1/7] Merge pkgsel/update-policy preseed from Ubuntu to offer
 to install unattended-upgrades.

---
 debian/changelog |  7 +++
 debian/pkgsel.templates  | 13 +
 pre-pkgsel.d/20update-policy | 41 +
 3 files changed, 61 insertions(+)
 create mode 100755 pre-pkgsel.d/20update-policy

diff --git a/debian/changelog b/debian/changelog
index d9934a7..5dd6dc7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pkgsel (0.46) UNRELEASED; urgency=medium
+
+  * Merge pkgsel/update-policy preseed from Ubuntu to offer to install
+unattended-upgrades.
+
+ -- Raphaël Hertzog   Fri, 15 Sep 2017 11:26:14 +0200
+
 pkgsel (0.45) unstable; urgency=medium
 
   * Export DEBIAN_TASKS_ONLY=1 when running tasksel in target, to make
diff --git a/debian/pkgsel.templates b/debian/pkgsel.templates
index 6ce4290..0b8fd54 100644
--- a/debian/pkgsel.templates
+++ b/debian/pkgsel.templates
@@ -48,3 +48,16 @@ Description: for internal use; can be preseeded
 Template: pkgsel/progress/fallback
 Type: text
 _Description: Running ${SCRIPT}...
+
+Template: pkgsel/update-policy
+Type: select
+Default: none
+Choices-C: none, unattended-upgrades
+__Choices: No automatic updates, Install security updates automatically
+_Description: How do you want to manage upgrades on this system?
+ Applying updates on a frequent basis is an important part of keeping your
+ system secure.
+ .
+ By default, updates need to be applied manually using package management
+ tools. Alternatively, you can choose to have this system automatically
+ download and install security updates.
diff --git a/pre-pkgsel.d/20update-policy b/pre-pkgsel.d/20update-policy
new file mode 100755
index 000..c3588da
--- /dev/null
+++ b/pre-pkgsel.d/20update-policy
@@ -0,0 +1,41 @@
+#!/bin/sh
+
+set -e
+. /usr/share/debconf/confmodule
+
+DISTRIB_ID=$(. /target/etc/os-release; echo $ID)
+DISTRIB_ID_LIKE=$(. /target/etc/os-release; echo $ID_LIKE)
+
+if [ "$DISTRIB_ID" = "ubuntu" ] || [ "$DISTRIB_ID_LIKE" = "ubuntu" ]; then
+	# Ubuntu hack to ask this at high priority on server or netboot
+	# installations, medium otherwise
+	if [ ! -d /cdrom/.disk ] || grep -iq server /cdrom/.disk/info; then
+		update_priority=high
+	else
+		update_priority=medium
+	fi
+else
+	# In Debian, we always ask the question
+	update_priority=high
+fi
+
+db_input "$update_priority" pkgsel/update-policy || true
+db_go || true
+db_get pkgsel/update-policy
+if [ "$RET" = none ]; then
+	# We might pull in unattended-upgrades, which defaults to doing security
+	# updates automatically. Seed it to have auto updates disabled so that if
+	# we *do* pull it in, it won't break stuff.
+	echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean false' | \
+		log-output -t pkgsel chroot /target debconf-set-selections || \
+		true
+elif [ "$RET" = unattended-upgrades ]; then
+	# unattended-upgrades defaults to true on installation if otherwise untouched.
+	apt-install unattended-upgrades || true
+elif [ "$RET" = landscape ]; then
+	# This is Ubuntu-specific but does no harm here
+	echo 'landscape-client landscape-client/register_system boolean true' | \
+		log-output -t pkgsel chroot /target debconf-set-selections || \
+		true
+	apt-install landscape-client || true
+fi
-- 
2.14.1

>From 391eb9457ec44eaa8d2a4603fcbf6c9c2a581821 Mon 

Bug#876132: freetype: Please upgrade to 2.8.1

[Hugh McMaster]

On Monday, 18 September 2017 at 23:35:20 +0200, Laurent Bigonville wrote:
> I've uploaded the new version to the DELAYED/10 queue, please test

I think we should hold this version for a while. It seems 2.8.1 is causing 
build problems and runtime crashes on Arch systems with Wine.

See, for example:
https://bugs.winehq.org/show_bug.cgi?id=43715
https://bugs.winehq.org/show_bug.cgi?id=43716

Bug#828741: Status

[Filip Pytloun]

I finished packaging of python-datrie:
https://anonscm.debian.org/git/python-modules/packages/python-datrie.git/tree/debian

Most difficult part was to separate bundled libdatrie to use Debian's
libdatrie-dev package for dependencies. This unfortunately needs
applying of following patch into libdatrie:
https://github.com/pytries/datrie/blob/master/trie_state_get_terminal_data.patch

Made required changes and waiting for libdatrie DM to accept my patch.


signature.asc
Description: PGP signature

Bug#828741: ITP: python-datrie -- Super-fast, efficiently stored Trie for Python

[Filip Pytloun]

On Mon, 27 Jun 2016 14:06:35 +0200 Filip Pytloun  wrote:
> Package: wnpp
> Version: 0.7.1
> Severity: wishlist
> Owner: Filip Pytloun 
> 
> * Package name: python-datrie
>   Version : 0.7.1
>   Upstream Author : Mikhail Korobov 
> * URL : https://github.com/kmike/datrie
> * License : LGPL-2.1
>   Programming Lang: Python
>   Description : Super-fast, efficiently stored Trie for Python
> 
>  trie variable is a dict-like object that can have unicode keys of certain
>  ranges and Python objects as values.
>  .
>  In addition to implementing the mapping interface, tries facilitate finding
>  the items for a given prefix, and vice versa, finding the items whose keys 
> are
>  prefixes of a given string. As a common special case, finding the
>  longest-prefix item is also supported.

Bug#828741: ITP: python-datrie -- Super-fast, efficiently stored Trie for Python

[Filip Pytloun]

On Mon, 27 Jun 2016 14:06:35 +0200 Filip Pytloun  wrote:
> Package: wnpp
> Version: 0.7.1
> Severity: wishlist
> Owner: Filip Pytloun 
> 
> * Package name: python-datrie
>   Version : 0.7.1
>   Upstream Author : Mikhail Korobov 
> * URL : https://github.com/kmike/datrie
> * License : LGPL-2.1
>   Programming Lang: Python
>   Description : Super-fast, efficiently stored Trie for Python
> 
>  trie variable is a dict-like object that can have unicode keys of certain
>  ranges and Python objects as values.
>  .
>  In addition to implementing the mapping interface, tries facilitate finding
>  the items for a given prefix, and vice versa, finding the items whose keys 
> are
>  prefixes of a given string. As a common special case, finding the
>  longest-prefix item is also supported.

Bug#828741: ITP: python-datrie -- Super-fast, efficiently stored Trie for Python

[Filip Pytloun]

On Mon, 27 Jun 2016 14:06:35 +0200 Filip Pytloun  wrote:
> Package: wnpp
> Version: 0.7.1
> Severity: wishlist
> Owner: Filip Pytloun 
> 
> * Package name: python-datrie
>   Version : 0.7.1
>   Upstream Author : Mikhail Korobov 
> * URL : https://github.com/kmike/datrie
> * License : LGPL-2.1
>   Programming Lang: Python
>   Description : Super-fast, efficiently stored Trie for Python
> 
>  trie variable is a dict-like object that can have unicode keys of certain
>  ranges and Python objects as values.
>  .
>  In addition to implementing the mapping interface, tries facilitate finding
>  the items for a given prefix, and vice versa, finding the items whose keys 
> are
>  prefixes of a given string. As a common special case, finding the
>  longest-prefix item is also supported.

Bug#828741: ITP: python-datrie -- Super-fast, efficiently stored Trie for Python

[Filip Pytloun]

On Mon, 27 Jun 2016 14:06:35 +0200 Filip Pytloun  wrote:
> Package: wnpp
> Version: 0.7.1
> Severity: wishlist
> Owner: Filip Pytloun 
> 
> * Package name: python-datrie
>   Version : 0.7.1
>   Upstream Author : Mikhail Korobov 
> * URL : https://github.com/kmike/datrie
> * License : LGPL-2.1
>   Programming Lang: Python
>   Description : Super-fast, efficiently stored Trie for Python
> 
>  trie variable is a dict-like object that can have unicode keys of certain
>  ranges and Python objects as values.
>  .
>  In addition to implementing the mapping interface, tries facilitate finding
>  the items for a given prefix, and vice versa, finding the items whose keys 
> are
>  prefixes of a given string. As a common special case, finding the
>  longest-prefix item is also supported.

Bug#828741: ITP: python-datrie -- Super-fast, efficiently stored Trie for Python

[Filip Pytloun]

On Mon, 27 Jun 2016 14:06:35 +0200 Filip Pytloun  wrote:
> Package: wnpp
> Version: 0.7.1
> Severity: wishlist
> Owner: Filip Pytloun 
> 
> * Package name: python-datrie
>   Version : 0.7.1
>   Upstream Author : Mikhail Korobov 
> * URL : https://github.com/kmike/datrie
> * License : LGPL-2.1
>   Programming Lang: Python
>   Description : Super-fast, efficiently stored Trie for Python
> 
>  trie variable is a dict-like object that can have unicode keys of certain
>  ranges and Python objects as values.
>  .
>  In addition to implementing the mapping interface, tries facilitate finding
>  the items for a given prefix, and vice versa, finding the items whose keys 
> are
>  prefixes of a given string. As a common special case, finding the
>  longest-prefix item is also supported.

Bug#828741: ITP: python-datrie -- Super-fast, efficiently stored Trie for Python

[Filip Pytloun]

On Mon, 27 Jun 2016 14:06:35 +0200 Filip Pytloun  wrote:
> Package: wnpp
> Version: 0.7.1
> Severity: wishlist
> Owner: Filip Pytloun 
> 
> * Package name: python-datrie
>   Version : 0.7.1
>   Upstream Author : Mikhail Korobov 
> * URL : https://github.com/kmike/datrie
> * License : LGPL-2.1
>   Programming Lang: Python
>   Description : Super-fast, efficiently stored Trie for Python
> 
>  trie variable is a dict-like object that can have unicode keys of certain
>  ranges and Python objects as values.
>  .
>  In addition to implementing the mapping interface, tries facilitate finding
>  the items for a given prefix, and vice versa, finding the items whose keys 
> are
>  prefixes of a given string. As a common special case, finding the
>  longest-prefix item is also supported.

Bug#876157: python-fuse: Inconsistent explanation between short and long descriptions

[Gunnar Wolf]

Package: python-fuse
Version: 2:0.2.1-14
Severity: minor
Tags: patch

Package: python-fuse
Version: 2:0.2.1-14
Severity: minor
Tags: patch

Package: python-fuse
Version: 2:0.2.1-14
Severity: minor
Tags: patch

Hiya,

The short description for this module reads:

Python bindings for FUSE (Filesystems in USErland)

While the long description starts as:

This is a Python interface to FUSE.
.
FUSE (Filesystem in USErspace) is (...)

AFAICT, the second one is the correct one. Here is the (most trivial)
inlined patch:

diff --git a/debian/control b/debian/control
index d6fbee6..8f27669 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ XB-Python-Version: ${python:Versions}
 Provides: ${python:Provides}
 Breaks: gmailfs (<= 0.7.3-4), wikipediafs (<= 0.3), python2.4-fuse (<< 2.5-3), 
python2.3-fuse (<< 2.5-3)
 Replaces: python2.4-fuse (<< 2.5-3), python2.3-fuse (<< 2.5-3)
-Description: Python bindings for FUSE (Filesystems in USErland)
+Description: Python bindings for FUSE (Filesystems in USErspace)
  This is a Python interface to FUSE.
  .
  FUSE (Filesystem in USErspace) is a simple interface for userspace


Thanks!

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

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

Versions of packages python-fuse depends on:
ii  fuse  2.9.7-1
ii  libc6 2.24-17
ii  libfuse2  2.9.7-1

python-fuse recommends no packages.

python-fuse suggests no packages.

-- no debconf information

Bug#876158: mirror submission for mirrors.shuosc.org

[Shanghai University Open Source Community]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.shuosc.org
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
CDImage-http: /debian-cd/
Archive-upstream: mirrors.kernel.org
CDImage-upstream: mirrors.kernel.org
Updates: four
Maintainer: Shanghai University Open Source Community 
Country: CN China
Location: Shanghai China
Sponsor: Shanghai University NITA Lab https://nita.shu.edu.cn
Comment: Shanghai University Information Department
 
 http://www.its.shu.edu.cn




Trace Url: http://mirrors.shuosc.org/debian/project/trace/
Trace Url: http://mirrors.shuosc.org/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.shuosc.org/debian/project/trace/mirrors.shuosc.org

Trace Url: http://mirrors.shuosc.org/debian-cd/project/trace/
Trace Url: http://mirrors.shuosc.org/debian-cd/project/trace/cdimage.debian.org
Trace Url: http://mirrors.shuosc.org/debian-cd/project/trace/mirrors.shuosc.org

Bug#876156: libcoap: Package would build fine on Jessie if debhelper dependency allowed, it

[Stuart Longland]

Package: libcoap
Version: 4.1.2-1
Severity: wishlist

Dear Maintainer,

I just tried building this package on Debian Jessie as most of our
infrastructure still uses this release.  Out-of-the-box, it will not
build due to the version of debhelper, however if you tell it to ignore
this, it builds just fine.

This suggests the version of debhelper could be dropped back to what's
available in Jessie and thus make it trivial for people to build this
package for Debian Jessie systems without needing to tweak the Stretch
version of the source package.

root@ac943b4e037b:/tmp/libcoap/libcoap-4.1.2# dpkg -l debhelper
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture  Description
+++--=-=-==
ii  debhelper9.20150101+deb8u2
all   helper programs for debian/rules
root@ac943b4e037b:/tmp/libcoap/libcoap-4.1.2# dpkg-buildpackage -us -uc -b
dpkg-buildpackage: source package libcoap
dpkg-buildpackage: source version 4.1.2-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Carsten Schoenert

dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build libcoap-4.1.2
dpkg-source: info: using options from
libcoap-4.1.2/debian/source/options: --extend-diff-ignore=^\.travis\.yml$
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 10.2.2~)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied;
aborting
dpkg-buildpackage: warning: (Use -d flag to override.)

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

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

Bug#876155: gnote: New upstream release 3.26.0

[Jeremy Bicha]

Source: gnote
Version: 3.22.1-1
Severity: wishlit

gnote 3.26.0 has been released. Much of GNOME 3.26 is already in
Debian Testing so it would be nice to have this update too.

https://git.gnome.org/browse/gnote/tree/NEWS

Thanks,
Jeremy Bicha

Bug#841733: Transition Opencv 3.1

[Nobuhiro Iwamatsu]

Hi,

Sorry, reply is too late.

2017-09-14 1:53 GMT+09:00 Emilio Pozuelo Monfort :
> On Sat, 15 Jul 2017 09:41:43 +0200 Emilio Pozuelo Monfort  
> wrote:
>> On 15/07/17 00:51, Mattia Rizzolo wrote:
>> > On Fri, Jul 14, 2017 at 11:16:23AM +0200, Mattia Rizzolo wrote:
>> >> But in the meantime OpenCV 3.2 went out, so we'd like to go for that.
>> >> It has been accepted into experimental a few days ago, and afaik nobody
>> >> test rebuilt things with it.
>> >
>> > Indeed my test rebuilds highlighted new failures…
>> >
>> > In particular of libkf5kface (already patched with what worked for 3.1),
>> > openimageio, ros-opencv-apps.  I haven't investigated them yet, but if
>> > anybody wants to try and fail/fix things where needed it would be nice.
>>
>> Could you at least report bugs with build logs? And make them block this one.
>
> What's the status of this?


The situation has not changed much. After the previous report, OpenCV
3.2 was released.
And libkf5kface can not be built. Also, the latest OpenCV is 3.3, and
we want to shift this to base.
Also, some packages can not be built for other reasons.

The following packages can be migrated with OpenCV 3.2:

cimg
actiona
auto-multiple-choice
eviacam
freecad
frei0r
gmic
limereg
mrpt
openalpr
opencfu
openimageio
os-autoinst
otb
ros-opencv-apps
ros-vision-opencv
saga
sikulix
siril
sitplus
visp
gst-plugins-bad1.0

The following packages have problems and block migration.

caffe
Not yet check
NOTE:  #875723

caffe-contrib
Not yet check
NOTE:  #875723

digikam
FTBFS / #841412
NOTE:  FTBFS on unstable #876154

libkf5kface
FTBFS / #841411
NOTE: With OCV 3.1  is OK, But this does not support OCV 3.2 or later.
https://bugs.kde.org/show_bug.cgi?id=377425
no rdeps: could be removed from testing

mldemos
FTBFS /  #861270
NOTE: no rdeps: could be removed from testing

nomacs
FTBFS
NOTE:  FTBFS on unstable  #876153

>
> Cheers,
> Emilio

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#876055: Environment variable handling for reproducible builds

[Vagrant Cascadian]

On 2017-09-18, Vagrant Cascadian wrote:
> On 2017-09-18, Russ Allbery wrote:
>> Daniel Kahn Gillmor  writes:
>>> On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote:

>>> Does everything in policy need to be rigorously testable?  or is it ok
>>> to have Policy state the desired outcome even if we don't know how (or
>>> don't have the resources) to test it fully today.
>>
>> I don't think everything has to be rigorously testable, but I do think
>> it's a useful canary.  If I can't test something, I start wondering
>> whether that means I have problems with my underlying assumptions.
>>
>> In particular, for (1), we have no comprehensive list of environment
>> variables that affect the behavior of tools, and that list would be
>> difficult to create.  Many pieces of software add their own environment
>> variables with little coordination, and many of those variables could
>> possibly affect tool output.
>
> There is a huge difference between variables that *might* affect the
> build as an unintended input that gets stored in a resulting packages in
> some manner, and variables that are designed to change the behavior of
> parts of the build toolchain.
>
> I consider unintended variables that affect the build output a bug, and
> variables designed and intended to change the behavior of the toolchain
> expected, reasonable behavior.

Ok, after discussing on IRC a bit, I figured it might be worth expanding
on that point a bit...


The envioronment variables (and other variations) used by the
reproducible builds test infrastructure:

  https://tests.reproducible-builds.org/debian/index_variations.html

I'll try and summarize the rationale for each of the variables used,
many of which have had actual impacts on the result of the builds:


CAPTURE_ENVIRONMENT, BUILDUSERID, BUILDUSERNAME

Some builds capture the entire environment, or most of the environment;
setting arbitrary environment variables can help detect this.

TZ

The timezone used can change the results of embedded timestamps.

LANG, LANGUAGE, LC_ALL

The locale and language settings definitely change the strings embedded
in some binaries, if tool output is translated.

PATH, USER, HOME

Some builds embed these.

DEB_BUILD_OPTIONS=parallel=N

The level of parallelism can change the build output, although other
values in DEB_BUILD_OPTIONS values might be reasonably expected to
change output (e.g. noautodbgsym).


None of the above variables should change the resulting built package,
with the possible exception of some other values of DEB_BUILD_OPTIONS.

On the other hand, I would expect variables such as CC, MAKE,
CROSS_COMPILE, CFLAGS, etc. to reasonably and likely change the result
of the built package. They are, in a sense, part of the build toolchain
environment.


Without generating comprehensive blacklists and/or whitelists, is it
plausible to come up with a policy description of the above two classes
of variables? Given the above lists, it seems relatively obvious to me
that there are basically two classes of variables, but I'm at a loss for
how to really describe it in policy.

You could give a reasonable test of:

  Is this variable intended to change the results of the binary, or is
  it changing the build as an unintended side-effect?

That does require reasoned interpretation, though. I envision such tests
being used in bug reports relating to reproducibility issues, on a
case-by-case basis.


It doesn't solve the testability issue on a policy level, but that could
possibly be addressed outside of policy through best practices for
reproducibility documentation.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#866638: geary: depends on libwebkitgtk-3.0-0 which is deprecated

[Jeremy Bicha]

Control: tags -1 +pending +patch

I am uploading an NMU to fix the 2 RC bugs for this package:
https://bugs.debian.org/866638
https://bugs.debian.org/873863

The NMU is a git snapshot from September 15 since there hasn't been a
new geary release since 0.11.3 last year. Several other distros have
also packaged git snapshots of geary because of the desire to
completely remove the unmaintained webkitgtk.

I am uploading to the DELAYED/5 queue. Please feel free to tell me if
I should delay it longer.

diff is posted below.

Thanks,
Jeremy Bicha

Index: debian/changelog
===
--- debian/changelog(revision 27304)
+++ debian/changelog(working copy)
@@ -1,3 +1,14 @@
+geary (0.12~20170915-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream git snapshot (Closes: #873863)
+  * Switch to webkit2gtk (Closes: #866638) (LP: #1588150)
+  * debian/control:
+- Build-depend on libenchant-dev
+- Bump minimum GTK+ to 3.14 and GLib to 2.42
+
+ -- Jeremy Bicha   Mon, 18 Sep 2017 23:01:28 -0400
+
 geary (0.11.3-1) unstable; urgency=medium

   * New upstream release.
Index: debian/control
===
--- debian/control(revision 27304)
+++ debian/control(working copy)
@@ -9,17 +9,18 @@
  gnome-doc-utils,
  intltool,
  libcanberra-dev (>= 0.28),
+ libenchant-dev (>= 1.6),
  libgcr-3-dev (>= 3.10.1),
  libgee-0.8-dev (>= 0.8.5),
  libgirepository1.0-dev (>= 1.32.0),
- libglib2.0-dev (>= 2.38.0),
+ libglib2.0-dev (>= 2.42.0),
  libgmime-2.6-dev (>= 2.6.14),
  libgnome-keyring-dev (>= 3.2.2),
- libgtk-3-dev (>= 3.12.0),
+ libgtk-3-dev (>= 3.14.0),
  libnotify-dev (>= 0.7.5),
  libsecret-1-dev (>= 0.11),
  libsqlite3-dev (>= 3.7.4),
- libwebkitgtk-3.0-dev (>= 2.3.0),
+ libwebkit2gtk-4.0-dev (>= 2.10),
  libxml2-dev (>= 2.7.8),
  valac (>= 0.22.1)
 Standards-Version: 3.9.8

Bug#876153: nomacs: FTBFS: dh_makeshlibs: failing due to earlier errors

[Nobuhiro Iwamatsu]

Package: nomacs
Version: 3.4.1+dfsg-10
Severity: serious
Tags: buster sid
Justification: FTBFS on amd64

Dear Maintainer,

nomacs FTBFS on latest sid environment.

---
   dh_makeshlibs -O--buildsystem=cmake -O--fail-missing
dpkg-gensymbols: warning: some new symbols appeared in the symbols
file: see diff output below
dpkg-gensymbols: warning: debian/libnomacscore3/DEBIAN/symbols doesn't
match completely debian/libnomacscore3.symbols
--- debian/libnomacscore3.symbols (libnomacscore3_3.4.1+dfsg-10_amd64)
+++ dpkg-gensymbols0XWFlb 2017-09-19 00:55:06.051976855 +
@@ -47,6 +47,8 @@
  (optional|c++)"QtSharedPointer::ExternalRefCountWithCustomDeleter::deleter(QtSharedPointer::ExternalRefCountData*)@Base"
3.2.0
  (c++)"QtSharedPointer::ExternalRefCountWithCustomDeleter::deleter(QtSharedPointer::ExternalRefCountData*)@Base"
3.2.0
  (c++)"QtSharedPointer::ExternalRefCountWithCustomDeleter::deleter(QtSharedPointer::ExternalRefCountData*)@Base"
3.2.0
+ _ZNK5QHashI7QString8QVariantE11equal_rangeERKS0_@Base 3.4.1+dfsg-10
+ 
_ZSt16__is_permutationIN5QHashI7QString8QVariantE14const_iteratorES4_N9__gnu_cxx5__ops19_Iter_equal_to_iterEEbT_S8_T0_T1_@Base
3.4.1+dfsg-10
  (c++)"nmc::DkFileFilterHandling::getExtensions(QString const&)
const@Base" 3.2.0
  (c++)"nmc::DkFileFilterHandling::getExtensions(QString const&,
QString&) const@Base" 3.2.0
  (c++)"nmc::DkFileFilterHandling::getIconID(QString const&) const@Base" 3.2.0
dpkg-gensymbols: warning: some new symbols appeared in the symbols
file: see diff output below
dpkg-gensymbols: warning: debian/libnomacsgui3/DEBIAN/symbols doesn't
match completely debian/libnomacsgui3.symbols
--- debian/libnomacsgui3.symbols (libnomacsgui3_3.4.1+dfsg-10_amd64)
+++ dpkg-gensymbols2R62XZ 2017-09-19 00:55:08.207968829 +
@@ -81,7 +81,7 @@
  (optional|c++)"QList::~QList()@Base" 3.2.0
  (optional|c++)"QList::QList(QList const&)@Base" 3.2.0
  (optional|c++)"QList::~QList()@Base" 3.2.0
- (optional|c++)"QList::detach_helper(int)@Base" 3.4.1
+#MISSING: 3.4.1+dfsg-10#
(optional|c++)"QList::detach_helper(int)@Base" 3.4.1
  (optional|c++)"QList::~QList()@Base" 3.2.0
  (optional|c++)"QList::append(QStandardItem*
const&)@Base" 3.2.0
  (optional|c++)"QList::detach_helper_grow(int, int)@Base" 3.2.0
..
---

Could you check this problem?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


nomacs_3.4.1+dfsg-10_amd64.build.gz
Description: GNU Zip compressed data

Bug#876152: RFS: luakit/2017.08.10-1

[Grégory DAVID]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "luakit"

 * Package name: luakit
   Version : 2017.08.10-1
   Upstream Author : Aidan Holm 
 * URL : http://www.luakit.org
 * License : GPL-3.0+
   Section : web

  It builds those binary packages:

luakit - fast and small web browser extensible by Lua, WebKit2 based

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

  https://mentors.debian.net/package/luakit


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

dget -x 
https://mentors.debian.net/debian/pool/main/l/luakit/luakit_2017.08.10-1.dsc

  More information about luakit can be obtained from http://www.luakit.org.

  Regards,
   Grégory DAVID 
   

Bug#876151: amdgpu.ko: AMD Radeon WX 5100 (Polaris 10) Driver fails to load on boot w/ ENOMEM (12) error - sw_init()

[BJ Dillon]

Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: important
File: amdgpu.ko

HP DL785 G5 with AMD Radeon Pro WX 5100 (Polaris 10). On boot AMDGPU driver 
fails to load with ENOMEM (12) error. This is with a fresh install of Debian 
9.1 (non-free) and installation of firmware-amd-graphics package.


relevant kernel messages: 

[   19.852255] amdgpu :41:00.0: firmware: direct-loading firmware 
amdgpu/polaris10_mc.bin
[   19.852496] [TTM] Zone  kernel: Available graphics memory: 264198634 kiB
[   19.852498] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   19.852501] [TTM] Initializing pool allocator
[   19.852514] [TTM] Initializing DMA pool allocator
[   19.852560] amdgpu :41:00.0: VRAM: 8192M 0x - 
0x0001 (8192M used)
[   19.852566] amdgpu :41:00.0: GTT: 258006M 0x0002 - 
0x0040FD67A7FF
[   19.852582] [drm] Detected VRAM RAM=8192M, BAR=256M
[   19.852585] [drm] RAM width 256bits GDDR5
[   19.852657] [drm] amdgpu: 8192M of VRAM memory ready
[   19.852660] [drm] amdgpu: 258006M of GTT memory ready.
[   19.852703] [drm] GART: num cpu pages 66049658, num gpu pages 66049658
[   19.852867] [drm:amdgpu_device_init [amdgpu]] *ERROR* sw_init of IP block 
 failed -12
[   19.852955] amdgpu :41:00.0: amdgpu_init failed
[   19.853021] amdgpu :41:00.0: Fatal error during GPU init
[   19.853084] [drm] amdgpu: finishing device.
[   19.854339] amdgpu: probe of :41:00.0 failed with error -12



 


-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=63c326c1-640b-4ed3-92d0-df384d3edabe ro quiet

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: ProLiant DL785 G5   
product_version: 
chassis_vendor: HP
chassis_version: 
bios_vendor: HP
bios_version: A15

** Loaded modules:
fuse
binfmt_misc
joydev
amdkfd
amd64_edac_mod
edac_mce_amd
amdgpu
edac_core
ttm
drm_kms_helper
drm
snd_hda_codec_hdmi
kvm
snd_hda_intel
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
evdev
i2c_algo_bit
mfd_core
soundcore
shpchp
serio_raw
irqbypass
ipmi_si
sg
hpilo
k10temp
button
pcspkr
ipmi_msghandler
hpwdt
acpi_cpufreq
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
ecb
glue_helper
lrw
gf128mul
ablk_helper
cryptd
aes_x86_64
mbcache
hid_logitech_hidpp
hid_logitech_dj
hid_generic
usbhid
hid
sr_mod
cdrom
hpsa
scsi_transport_sas
ata_generic
psmouse
ohci_pci
pata_serverworks
xhci_pci
ohci_hcd
ehci_pci
uhci_hcd
libata
xhci_hcd
cciss
ehci_hcd
myri10ge
dca
usbcore
scsi_mod
bnx2
i2c_piix4
usb_common

** Network interface configuration:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: ens2:  mtu 9000 qdisc mq state UP group 
default qlen 1000
link/ether 00:60:dd:46:ff:c6 brd ff:ff:ff:ff:ff:ff
3: enp2s3:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:c4:f3:78:8e brd ff:ff:ff:ff:ff:ff
inet 10.10.0.162/16 brd 10.10.255.255 scope global dynamic enp2s3
   valid_lft 85061sec preferred_lft 85061sec
inet6 fe80::21c:c4ff:fef3:788e/64 scope link 
   valid_lft forever preferred_lft forever
4: enp2s4:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:c4:f3:78:90 brd ff:ff:ff:ff:ff:ff

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
enp2s3: 123718328710   210 0  0 3   413352
2217000 0   0  0
enp2s4: 148255733990   410 0  0 0  448  
 7000 0   0  0
  ens2:   0   0000 0  0 0   174230 
991000 0   0  0
lo:  889116   10988000 0  0 0   889116   
10988000 0   0  0


** PCI devices:
00:04.0 System peripheral [0880]: Compaq Computer Corporation Integrated Lights 
Out Controller [0e11:b203] (rev 03)
Subsystem: Hewlett-Packard Company Integrated Lights Out Controller 
[103c:3305]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 

Bug#807787: wiki.debian.org: warnings from the rotate-logs script

[James Montgomery]

Paul, 

Thank you for the log sample! I have attached a patch that updates the
pattern matching for the moin event log processing for your review.

I do not believe the rotate-logs script is responsible for the malformed
entries you are seeing. It also appears the original author was seeing
the errors, too, as indicated by a specific else clause meant to disgard such
occurrences: 

163: print "Ignoring malformed log line #" .$fh_in->input_line_number() . ": 
$line\n";

This particular clause was not being triggered due to the original regex
being a bit too greedy resulting in malformed timestamps being passed to
gmtime(). 

The attached patch corrects the issue, but the script could use some
additional tidying up as it does have a few 'magic
numbers' scattered about which took some extra time for me to discern
their meaning. I didn't want to get too liberal with the modifications 
and end up in refactor territority when all that was asked was to make
the errors go away :) 

-- 
James Montgomery
>From 5db19f4426a99e4b9c52491df2cad23afee26129 Mon Sep 17 00:00:00 2001
From: James Montgomery 
Date: Mon, 18 Sep 2017 21:11:34 -0400
Subject: [PATCH] Update regex match

---
 bin/rotate-logs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/rotate-logs b/bin/rotate-logs
index 532e9a8..c171836 100755
--- a/bin/rotate-logs
+++ b/bin/rotate-logs
@@ -250,7 +250,7 @@ $gid = get_gid_by_name("wikiweb");
 chdir $moin_logdir or die "Can't cd to $moin_logdir: $!\n";
 
 rotate_log("edit-log", '^(\d+)\s+(\d+)\s+(\S+)\s+(\S)+\s+(\S+)', 'moin');
-rotate_log("event-log", '^(\d+)\s+(\S+)\s+(\S+)', 'moin');
+rotate_log("event-log", '^(\d{0,16})\s+(\S+)\s+(\S+)', 'moin');
 
 chdir $local_logdir or die "Can't cd to $local_logdir: $!\n";
 
-- 
2.14.1

Bug#875058: [mumble] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 18 de septiembre de 2017 05:37:03 -03 Chris Knadle wrote:
> Lisandro Damián Nicanor Pérez Meyer:
[snip]
> Hello again Lisandro. ;-)

Hi! :-)

> Mumble uses SSL (and has to) and the build logs look like the current
> version in Unstable is built against libssl1.1_1.1.0c-4:
> 
> https://buildd.debian.org/status/fetch.php?pkg=mumble=amd64=1.2.18-> 
> 1=1485106520=0
> 
> So that looks to me like mumble is built against OpenSSL 1.1, AFAIK.

It build-depends upon libssl-dev, so yes.

> There has been some discussion in the #mumble IRC channel on Freenode
> that Qt5 currently doesn't support OpenSSL 1.1,

Exactly as Qt4 does.

> but I did some digging
> and it looks like it does as of Qt 5.10.0 Alpha:
> 
> https://bugreports.qt.io/browse/QTBUG-52905

Right.

> There's a commit listed there for the fix, so I suppose it may be
> possible to backport a patch for Qt 5.7.

Qt 5.7 is only available in stable, so no, it won't get a backport.
Buster on the other hand will have Qt 5.10.

> And if all goes well, Qt 5.10 and mumble-1.3.x will both have stable
> releases in time to upload them to Unstable before the freeze for
> Buster. [Freeze sometime ~Jan 2019, I guess.]

I think either you or me are missing a point here. Right now both qt4 and qt5 
use OpenSSL 1.0. So if mumbles uses OpenSSL 1.1 then it means that it is not 
using Qt5's Network submodule, so it's not mixing OpenSSL versions (and if it 
is, it has been lucky enough to avoid crashes).

If this is the case then there is nothing sotpping mumble from being ported to 
Qt5.

Kinds regards, Lisandro.

-- 
The box said 'Requires Windows 95 or better'. So I installed Linux.
  Anonymous

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#876149: ust: FTBFS on m68k: lib_ring_buffer_nesting symbol has TLS prefix

[Aaron M. Ucko]

Source: ust
Version: 2.10.0-1
Severity: important
Justification: fails to build from source (but built successfully in the past)
User: debian-m...@lists.debian.org

Builds of ust for m68k (admittedly not a release architecture) have
started failing with symbols differences in both liblttng-ust0 and
liblttng-ust-ctl4:

+ __tls_access_lib_ring_buffer_nesting@Base 2.10.0-1
- lib_ring_buffer_nesting@Base 2.10.0

Could you please account for this architecture-specific prefix?

Thanks!

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

Bug#876148: ust: FTBFS w/GCJ (on hppa)

[Aaron M. Ucko]

Source: ust
Version: 2.9.1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

Builds of ust with GCJ (to which default-jdk necessarily still boils
down on hppa, admittedly not a release architecture) have been failing:

  CLASSPATH=.:./.${CLASSPATH:+":$CLASSPATH"} gcj -C -d . -source 1.6 -target 
1.6   org/lttng/ust/LTTngUst.java
  gcj: error: 1.6: No such file or directory
  gcj: error: 1.6: No such file or directory
  gcj: error: unrecognized command line option '-source'; did you mean 
'-fsource='?
  gcj: error: unrecognized command line option '-target'; did you mean 
'-ftarget='?
  Makefile:510: recipe for target 'classnoinst.stamp' failed
  make[4]: *** [classnoinst.stamp] Error 1

Could you please take a look?  If building with GCJ is infeasible,
please specifically require OpenJDK so that autobuilders for GCJ-only
architectures (i.e., hppa) don't bother trying to cover ust.

Thanks!

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

Bug#876147: camp: FTBFS on ppc64 and sparc64: FUNCTIONMAPPING/call error

[Aaron M. Ucko]

Source: camp
Version: 0.8.1-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powe...@lists.debian.org

Builds of camp 0.8 for ppc64 and sparc64 (both non-release
architectures, admittedly) have been failing with nearly identical errors.

ppc64: /<>/test/qt/functionmapping.cpp(97): error: in 
"FUNCTIONMAPPING/call": check metaclass->function("f4").call(object, 
camp::Args(1, 4, 15)).to() == 20 has failed [22 != 20]

sparc64: /<>/test/qt/functionmapping.cpp(97): error: in 
"FUNCTIONMAPPING/call": check metaclass->function("f4").call(object, 
camp::Args(1, 4, 15)).to() == 20 has failed [21 != 20]

Both are big-endian 64-bit architectures, but so is s390x, which
(perhaps by chance?) ran into no trouble on this front.

Could you please take a look?

Thanks!

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

Bug#876145:

[Peter Amstutz]

I left out the --system flag in my example.

Just to be clear:

pkg_A (requires pkg_B==1.0)
pkg_C (requires pkg_B>=1.0)

$ pip install --system pkg_A  # installs pkg_B==1.0
$ pip install --system pkg_C  # ignores pkg_B==1.0, installs pkg_B==2.0
$ pkg_A
pkg_resources.ContextualVersionConflict: (pkg_B 2.0
(/usr/local/lib/python2.7/dist-packages),
Requirement.parse('pkg_B==1.0'), set(['pkg_A']))

Because of --ignore-installed, pkg_C ignores the existing pkg_B (which
it is otherwise compatible with) and installs the latest pkg_B==2.0, as
a result this breaks pkg_A.

Bug#876146: the system freezes at startup, on the login screen tty before starting the graphical interface

[carlosnewmusic]

Package: kernel-common
Version: 13.018+nmu1
Severity: normal
Tags: upstream

https://pastebin.com/21vvnzxq
https://pastebin.com/ZKg8Yj6p



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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1), LANGUAGE=es_ES 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kernel-common depends on:
ii  ucf  3.0036

kernel-common recommends no packages.

Versions of packages kernel-common suggests:
ii  kernel-package  13.018+nmu1

-- no debconf information

Bug#876145: python-pip: pip install --system as non-root shouldn't default --ignore-installed

[Peter Amstutz]

Source: python-pip
Version: 9.0.1-2
Severity: normal

Dear Maintainer,

When running "pip install --system" as a non-root user, the change in
set_user_default.patch forces the --ignore-installed flag to be enabled.

This has the effect of breaking pip for use cases that install packages as non-
root but don't use --user or virtualenv.  When dependencies are shared among
multiple packages, the --ignore-installed option causes pip to blindly install
the latest version of each dependency requested by each package, even if a
compatible package version is already installed, and even if this breaks the
requirement spec of some other package.  This results in package version
conflicts.

For example:

pip install pkg_A (requires pkg_B==1.0)
pip install pkg_C (requires pkg_B>=1.0)

Because of --ignore-installed, pkg_C ignores the existing pkg_B (which it is
otherwise compatible with) and installs the latest pkg_B==2.0, as a result this
breaks pkg_A.

Here's the relevant logic in pip/commands/install.py:

default_user = True
if running_under_virtualenv():
default_user = False
if os.geteuid() == 0:
default_user = False

cmd_opts.add_option(
'-I', '--ignore-installed',
dest='ignore_installed',
action='store_true',
default=default_user,
help='Ignore the installed packages (reinstalling instead).')

My preferred fix would be that when the --system flag is set, it should retain
the default behavior of pip, and not interfere with the unrelated --ignore-
installed flag.

Thanks,
Peter



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

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

Bug#876144: lists.debian.org: Request for new mailing list: pkg-gnupg-maint

[Daniel Kahn Gillmor]

Package: lists.debian.org
Severity: wishlist

pkg-gnupg-ma...@lists.alioth.debian.org currently mostly hosts bug
reports, but it is also the maintainer address for the packages
maintained by the GnuPG packaging team, and it hosts some discussion
about packaging plans and questions, like the following:


https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-September/006023.html

https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-September/005961.html


It also occasionally hosts user support and discussions around
coordinating CVE fixes for different releases:

https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-August/005924.html

I'd like to ask for a pkg-gnupg-ma...@lists.debian.org mailing list to
replace the outgoing list on alioth.  or, if the listmasters prefer a
debian-foo naming convention: debian-gn...@lists.debian.org.

Short description:

Debian packaging for GnuPG and related tools.

Long Description:

This list discusses Debian packaging for GnuPG and related tools.
Members of the Debian GnuPG packaging team should subscribe, and
people with questions about packaging for GnuPG and related projects
in Debian are welcome to participate.

Category:  Developers

Subscription Policy: open

Post Policy: open

Web Archive: yes, please.


If other members of pkg-gnupg-maint could follow up on this bug to
state intent to participate, that would be great.

Regards,

 --dkg


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

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

Bug#847389: bash: /etc/skel/.bashrc should contain line "export GPG_TTY=$(tty)"

[Daniel Kahn Gillmor]

Control: forwarded 847389 https://dev.gnupg.org/T3412

On Sun 2017-09-17 19:01:06 +0300, Teemu Likonen wrote:
> Maybe you are right. I just based my suggestion on the gpg-agent manual
> which says "You should always add the following lines to your .bashrc
> [...]". The manual is then misleading and should be rewritten to be more
> specific about the issue.

agreed, i've just opened an upstream bug report about this, as linked
above.

--dkg



signature.asc
Description: PGP signature

Bug#876055: Environment variable handling for reproducible builds

[Vagrant Cascadian]

On 2017-09-18, Russ Allbery wrote:
> Daniel Kahn Gillmor  writes:
>> On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote:
>
>>> I personally lean towards 2, which is consistent with what's in Policy
>>> right now, but I can see definite merits in 3.  I believe the
>>> reproducible builds project is currently sort of doing 1, but I have a
>>> hard time seeing how to make that viable on the testing side.
>
>> Thanks for raising this question, Russ!

Indeed!


>> I'm not sure that we should let lack of exhaustive testing push us away
>> from (1).  (1) is in principle the right thing -- it's easy to make a
>> build reproducible if we tell people that they have to do exactly one
>> specific thing.  But we generally want people to be able to run
>> heterogenous systems, and not to force them into one particular
>> environment.
>
> Well... I would argue that the amount of time and effort that's gone into
> this project shows that it's not that easy to make a build reproducible
> even when telling people to do exactly one thing.  :)  But I get your
> point.

Much of the work has already been done by aspirational, principled
folks... :)


>> Does everything in policy need to be rigorously testable?  or is it ok
>> to have Policy state the desired outcome even if we don't know how (or
>> don't have the resources) to test it fully today.
>
> I don't think everything has to be rigorously testable, but I do think
> it's a useful canary.  If I can't test something, I start wondering
> whether that means I have problems with my underlying assumptions.
>
> In particular, for (1), we have no comprehensive list of environment
> variables that affect the behavior of tools, and that list would be
> difficult to create.  Many pieces of software add their own environment
> variables with little coordination, and many of those variables could
> possibly affect tool output.

There is a huge difference between variables that *might* affect the
build as an unintended input that gets stored in a resulting packages in
some manner, and variables that are designed to change the behavior of
parts of the build toolchain.

I consider unintended variables that affect the build output a bug, and
variables designed and intended to change the behavior of the toolchain
expected, reasonable behavior.


> I feel like the work for (1) and for (3) ends up being comparable; for (1)
> we have to maintain a blacklist, and for (3) we have to maintain a
> whitelist.  But (3) is testable, whereas (1) is inherently aspirational
> and will always have to be aspirational.  We're endlessly going to be
> discovering some other environment variable that changes tool output.

Well, there can be a testable, automatable standard, and a higher,
aspirational standard in parallel.

Which largely seems consistant with what's already in policy... but I'm
not sure it's appropriate to codify these whitelists or blacklists in
policy.


> I'm also unsure that (1) is even what we want to claim.  Do we really want
> to say that builds are always reproducible if you don't change this short
> list of environment variables, no matter whatever other environment
> variables you set?

I don't think we want to make absolute claims; reproducible builds is
about having greater confidence that the binaries are produced from the
source, not absolute confidence.

The ideal is to have as many builds as possible corroborated from a
diverse group of build machines, developers, third-parties,
sophisticated end-users, legal jurisdictions, etc.


> There's some appeal in this for the end user, but it
> feels very frustrating for the package maintainer.  At first glance, as a
> package maintainer, I'd think I'd have to maintain a huge blacklist of
> environment variables that I've discovered affect my toolchain somewhere,
> and explicitly unset them all in debian/rules.  This doesn't feel like a
> good use of anyone's time (and may actually *break* other,
> non-reproducibility-related things that people want to do with my
> package).

In practice, for the vast majority of packages in Debian, it is a
relatively small number of environment variables to get fairly solid
reproducibility coverage... at least from what we've seen so far.

The hard part is actually continuing to tease them out...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#876143: udisks2-btrfs: Dependency on libblockdev-btrfs should be libblockdev-btrfs2

[Axel Beckert]

Package: udisks2-btrfs
Version: 2.7.3-3

Dear Utopia maintainers,

udisks2-btrfs depends on libblockdev-btrfs which doesn't exist.

What exists is libblockdev-btrfs2, so I assume there is a "2" missing in
that dependency.

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

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

Bug#876142: openmpi needs updating to fix bug?

[Carlos Carvalho]

Package:libopenmpi2
Version: 2.1.1-6+b1

A mpi user here cannot run his program because of this error:

 Read -1, expected 60480, errno = 38

His program works in 2 other machines with [much] older versions of openmpi.
One of them runs Debian sid with libopenmpi1 version 1.6.5-11. The machine
where the error appears runs Debian sid with the latest version:

libopenmpi-dev2.1.1-6+b1
libopenmpi2   2.1.1-6+b1
openmpi-bin   2.1.1-6+b1

I found in https://github.com/open-mpi/ompi/issues/3821 that a patch commited
in July 11 may fix the issue. The changelog shows that the Debian version is
older.

Perhaps it'd be useful if you could include the fix above in a newer version of
the sid packages?

Bug#872960: Actualy...

[Tomasz Buchert]

severity -1 grave
thanks

... actually I can reproduce this even on x11. I also get:

[INFO 01:12:29.004106] [synapse-main:266] Starting up...
[INFO 01:12:29.097393] [synapse-main:208] Binding activation to space
[1]23236 segmentation fault  synapse


signature.asc
Description: PGP signature

Bug#872960: Re

[Tomasz Buchert]

As this is somewhat non-standard setup, I downgraded the severity to
"important".


signature.asc
Description: PGP signature

Bug#833695: [Popcon-developers] Bug#833695: Bug#833695: strange popcon data on web (getting worse)

[Bill Allombert]

On Mon, Sep 18, 2017 at 04:41:00PM +0200, Bill Allombert wrote:
> On Mon, Sep 18, 2017 at 02:29:53PM +0900, Osamu Aoki wrote:
> > For example:
> > Package: /mCTge2x   0 0 0 1
> > Package: /miv5p4ngaN05^Atkg-30/iLe/usro0400 0 0 0 1
> > Package: /ml/ccSe3d1emdyn03bCe5.-mt60 0 0 1
> > Package: /onninpxs3modeits  0 0 0 1
> > Package: /r3n4qLD9341s0OsMsl2l0160m00   0 0 0 1
> > Package: /r3n4qLD93Osk.jarrac5502e/gsa00 0 0 0 1
> > Package: /sa0 0 0 1
> > Package: /sbin/setcap   0 0 0 1
> > Package: /shinrmsgmaddrr0aatngs1xir/-0H0o9urWxm/d0a6 0 0 0 1
> 
> I have found and removed the file with this line.
> It looks like a valid submission that was corrupted in transit.
> I will try to improve the server code to discard that. 

I have found 48 others corrupted files. I removed them.
I have tweaked the server code as well.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#876055: Environment variable handling for reproducible builds

[Russ Allbery]

Daniel Kahn Gillmor  writes:
> On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote:

>> I personally lean towards 2, which is consistent with what's in Policy
>> right now, but I can see definite merits in 3.  I believe the
>> reproducible builds project is currently sort of doing 1, but I have a
>> hard time seeing how to make that viable on the testing side.

> Thanks for raising this question, Russ!

> I'm not sure that we should let lack of exhaustive testing push us away
> from (1).  (1) is in principle the right thing -- it's easy to make a
> build reproducible if we tell people that they have to do exactly one
> specific thing.  But we generally want people to be able to run
> heterogenous systems, and not to force them into one particular
> environment.

Well... I would argue that the amount of time and effort that's gone into
this project shows that it's not that easy to make a build reproducible
even when telling people to do exactly one thing.  :)  But I get your
point.

> Consider someone who wants to see more logging from a build, for
> example.  There could be an environment variable that encourages the
> toolchain to log more, but doesn't affect the binary objects created by
> the build.  By going with choices (2) or (3) we effectively dismiss even
> considering the reproducibility of those builds, which seems like a
> shame.

This is the case for (2), but not for (3).  Indeed, this is exactly the
distinction between (2) and (3).  It does mean that discovery of any new
such environment variable would require a change to our whitelist in
approach (3), so there would be some lag and the whitelist would become
long over time (with a corresponding testing load).  But (3) does try to
achieve that use case without trying to anticipate any possible
environment variable setting.  It lets us be reactive to newly-discovered
environment variables across which we want to stay reproducible.

> Does everything in policy need to be rigorously testable?  or is it ok
> to have Policy state the desired outcome even if we don't know how (or
> don't have the resources) to test it fully today.

I don't think everything has to be rigorously testable, but I do think
it's a useful canary.  If I can't test something, I start wondering
whether that means I have problems with my underlying assumptions.

In particular, for (1), we have no comprehensive list of environment
variables that affect the behavior of tools, and that list would be
difficult to create.  Many pieces of software add their own environment
variables with little coordination, and many of those variables could
possibly affect tool output.

I feel like the work for (1) and for (3) ends up being comparable; for (1)
we have to maintain a blacklist, and for (3) we have to maintain a
whitelist.  But (3) is testable, whereas (1) is inherently aspirational
and will always have to be aspirational.  We're endlessly going to be
discovering some other environment variable that changes tool output.

I'm also unsure that (1) is even what we want to claim.  Do we really want
to say that builds are always reproducible if you don't change this short
list of environment variables, no matter whatever other environment
variables you set?  There's some appeal in this for the end user, but it
feels very frustrating for the package maintainer.  At first glance, as a
package maintainer, I'd think I'd have to maintain a huge blacklist of
environment variables that I've discovered affect my toolchain somewhere,
and explicitly unset them all in debian/rules.  This doesn't feel like a
good use of anyone's time (and may actually *break* other,
non-reproducibility-related things that people want to do with my
package).

-- 
Russ Allbery (r...@debian.org)   

Bug#876141: linux-image-4.12.0-2-amd64: Touchpad not detected on Lenovo IdeaPad 320-15ABR

[Nik Nyby]

Package: src:linux
Version: 4.12.12-2
Severity: normal

Dear Maintainer,

My touchpad is not recognized on my Lenovo IdeaPad 320-15ABR. The
touchpad doesn't show up in `xinput --list` or `cat
/proc/bus/input/devices`.

I've recompiled the kernel with CONFIG_PINCTRL_AMD=y, and booted
with the i8042.nopnp param. When I do this, the touchpad is recognized
as Synaptics TM3336-001 in `xinput --list`. However, the touchpad stops
working soon after starting X. So there may be an upstream bug as well,
I'm not sure yet. I propose at least adding CONFIG_PINCTRL_AMD=y to the
Debian linux-image default kernel config, so users have a better chance
of booting with a detectable touchpad with this laptop.

-- Package-specific info:
** Version:
Linux version 4.12.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.4.0 20170906 (Debian 6.4.0-5) ) #1 SMP Debian 4.12.12-2 (2017-09-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.12.0-2-amd64 
root=UUID=f14407f6-7c28-4567-9130-41b6ac47ad8e ro quiet nomodeset i8042.nopnp

** Not tainted

** Kernel log:
[7.079157] sp5100_tco: failed to find MMIO address, giving up.
[7.111902] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[7.217461] sd 0:0:0:0: Attached scsi generic sg0 type 0
[7.217515] sr 1:0:0:0: Attached scsi generic sg1 type 5
[7.258232] ACPI: Video Device [VGA1] (multi-head: yes  rom: no  post: no)
[7.258549] acpi device:33: registered as cooling_device4
[7.258596] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input7
[7.300699] ACPI: Battery Slot [BAT0] (battery present)
[7.435300] input: Ideapad extra buttons as 
/devices/pci:00/:00:14.3/PNP0C09:00/VPC2004:00/input/input8
[7.449467] EFI Variables Facility v0.08 2004-May-17
[7.537288] pstore: using zlib compression
[7.553948] pstore: Registered efi as persistent store backend
[7.602667] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel 
modesetting.
[7.646820] snd_hda_intel :00:01.1: enabling device ( -> 0002)
[7.646996] snd_hda_intel :00:01.1: Force to non-snoop mode
[7.647021] snd_hda_intel :00:09.2: enabling device (0004 -> 0006)
[7.681269] snd_hda_codec_generic hdaudioC1D0: autoconfig for Generic: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[7.681272] snd_hda_codec_generic hdaudioC1D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.681274] snd_hda_codec_generic hdaudioC1D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[7.681280] snd_hda_codec_generic hdaudioC1D0:mono: mono_out=0x0
[7.681281] snd_hda_codec_generic hdaudioC1D0:inputs:
[7.681283] snd_hda_codec_generic hdaudioC1D0:  Mic=0x19
[7.681285] snd_hda_codec_generic hdaudioC1D0:  Internal Mic=0x12
[7.683581] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.1/sound/card0/input9
[7.687737] input: HD-Audio Generic Mic as 
/devices/pci:00/:00:09.2/sound/card1/input10
[7.687811] input: HD-Audio Generic Headphone as 
/devices/pci:00/:00:09.2/sound/card1/input11
[7.788486] media: Linux media interface: v0.10
[7.817251] Linux video capture interface: v2.00
[7.871991] Bluetooth: Core ver 2.22
[7.872086] NET: Registered protocol family 31
[7.872087] Bluetooth: HCI device and connection manager initialized
[7.872092] Bluetooth: HCI socket layer initialized
[7.872095] Bluetooth: L2CAP socket layer initialized
[7.872113] Bluetooth: SCO socket layer initialized
[7.931007] uvcvideo: Found UVC 1.00 device EasyCamera (174f:116a)
[7.932061] uvcvideo 1-1.2:1.0: Entity type for entity Extension 4 was not 
initialized!
[7.932064] uvcvideo 1-1.2:1.0: Entity type for entity Processing 2 was not 
initialized!
[7.932067] uvcvideo 1-1.2:1.0: Entity type for entity Camera 1 was not 
initialized!
[7.932174] input: EasyCamera as 
/devices/pci:00/:00:12.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input12
[7.932255] usbcore: registered new interface driver uvcvideo
[7.932256] USB Video Class driver (1.1.1)
[7.934856] usbcore: registered new interface driver btusb
[7.936729] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000a 
lmp_ver=06 lmp_subver=8821
[7.936732] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_config.bin
[7.937378] bluetooth hci0: firmware: failed to load 
rtl_bt/rtl8821a_config.bin (-2)
[7.937431] bluetooth hci0: Direct firmware load for 
rtl_bt/rtl8821a_config.bin failed with error -2
[7.937435] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821a_fw.bin
[7.949968] bluetooth hci0: firmware: direct-loading firmware 
rtl_bt/rtl8821a_fw.bin
[7.951758] Bluetooth: hci0: rom_version status=0 version=1
[7.951769] Bluetooth: cfg_sz 0, total size 17428
[8.466349] rtl8821ae :01:00.0: enabling device ( -> 0003)
[8.553252] rtl8821ae: Using firmware rtlwifi/rtl8821aefw_29.bin
[8.553258] rtl8821ae: Using firmware 

Bug#876140: strip-nondeterminism: log which handlers "strip-nd"s a file

[Mattia Rizzolo]

Package: libfile-stripnondeterminism-perl
Version: 0.038-1
Severity: wishlist

Since 0.030 strip-nd prints a log when fixing a file, like
|   dh_strip_nondeterminism
|Using 1505769410 as canonical time
|Normalizing debian/libtse3-dev/usr/lib/x86_64-linux-gnu/libtse3.a


I'd find it handy (even if it might be obvious for most cases) to print
the name of the handler that does the normalization.

-- 
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#876121: FTBFS: error: 'std::index_sequence' has not been declared

[Bernd Zeimetz]

Hi,

On 09/18/2017 08:25 PM, Oliver Kurth wrote:
> We see the same issue in our internal tests at VMware. The solution
> seems to be to set CXXFLAGS=-std=c++14 for the configure command:
> 
> 
> CXXFLAGS=-std=c++14 ./configure --without-kernel-modules

good catch, I was actually building with
CXXFLAGS='-std=gnu++11'
before because some (other?) build-dependencies failed to build before.

Building right now:
https://travis-ci.org/bzed/pkg-open-vm-tools

I'll test and upload it tomorrow or so if all changes work as expected.

Thanks,

Bernd

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

Bug#876055: Environment variable handling for reproducible builds

[Daniel Kahn Gillmor]

On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote:
> I personally lean towards 2, which is consistent with what's in Policy
> right now, but I can see definite merits in 3.  I believe the reproducible
> builds project is currently sort of doing 1, but I have a hard time seeing
> how to make that viable on the testing side.

Thanks for raising this question, Russ!

I'm not sure that we should let lack of exhaustive testing push us away
from (1).  (1) is in principle the right thing -- it's easy to make a
build reproducible if we tell people that they have to do exactly one
specific thing.  But we generally want people to be able to run
heterogenous systems, and not to force them into one particular
environment.

Consider someone who wants to see more logging from a build, for
example.  There could be an environment variable that encourages the
toolchain to log more, but doesn't affect the binary objects created by
the build.  By going with choices (2) or (3) we effectively dismiss even
considering the reproducibility of those builds, which seems like a
shame.

Does everything in policy need to be rigorously testable?  or is it ok
to have Policy state the desired outcome even if we don't know how (or
don't have the resources) to test it fully today.

I'd prefer for policy to be able to make strong advisory statements even
without us being able to test them mechanically.  This is already the
case for (for example) "preferred form of modification" -- it's partly
testable, but will never be 100% testable, and will always require
research and discussion and thinking for the corner cases.  Yet we
continue to aim for it.

Policy should be aiming high, not lowering the bar to meet what's
concretely testable.

  --dkg

Bug#876139: pcb-rnd user security patch

[Bdale Garbee]

Package: release.debian.org

The pcb-rnd upstream has released a patch that closes a hole
through which arbitrary code can be executed if a user opens a
maliciously crafted printed circuit board design file.

There is no known instance of this being exploited in the field, there
is no root escalation, and the probability of someone opening a random
malicious printed circuit board design file is low.  However, upstream
has provided a clean patch for version 1.1.4, so I think we should
update the package in stable. 

Discussion with the security team led to the determination that this
doesn't meet the bar for a DSA update via security.debian.org, but we
agree it would be good to fix via point release.

I will prepare and upload a new version 1.1.4-2 targeting the stable
distribution later today.

Bdale

Bug#876138: ostree: FTBFS as root (with unusual umask?): "-00664 1 0 4 /baz/cow" doesn't match regexp '-00644 1 0'"

[Simon McVittie]

Package: ostree
Version: 2017.11-1
Severity: normal

ostree fails to build from source on debomatic:

http://debomatic-amd64.debian.net/distribution#experimental/ostree/2017.11-1/buildlog
(as of "Build started Monday, 18 September 2017 15:06 - finished
Monday, 18 September 2017 15:28" - I am not aware of a more permanent
URL for that specific log)

This appears to be because debomatic runs sbuild as root, so
tests/test-basic-root.sh runs and fails (it's normally skipped). The
failure cause seems to be

> + assert_file_has_content ls.txt '-00644 1 0'
...
> + ls -al ls.txt
> -rw-rw-r-- 1 root root 27 Sep 18 14:09 ls.txt
> + sed -e 's/^/# /'
> # -00664 1 0  4 /baz/cow
...
> File 'ls.txt' doesn't match regexp '-00644 1 0'

which seems to be because that test blindly assumes umask 022:

> echo moo > baz/cow
[there is no chmod here]

This is a FTBFS, but I don't consider it to be release-critical,
because building as root is a weird thing to do. I've opened
debomatic issue .

Regards,
smcv

Bug#875487: Debian mirror debian.noc.ntua.gr: not updating, broken ssh-push

[Peter Palfrader]

On Tue, 19 Sep 2017, Athanasios Douitsis wrote:

> Hello again,
> 
> After several runs, I can see everything runs without complaints. But I
> still see red in
> https://mirror-master.debian.org/status/mirror-status.html. Can I ask
> for a little help, will it go green on its own or do I need to do
> something extra?

It only just wrote its own tracefile, so I think it's green now.

https://mirror-master.debian.org/status/mirror-info/debian.noc.ntua.gr.html

Cheers :)
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#875487: Debian mirror debian.noc.ntua.gr: not updating, broken ssh-push

[Athanasios Douitsis]

On Mon, Sep 18, 2017 at 09:37:28PM +0300, Athanasios Douitsis wrote:

> On Mon, Sep 18, 2017 at 03:24:36PM +, Peter Palfrader wrote:
> 
> > On Mon, 18 Sep 2017, Athanasios Douitsis wrote:
> > 
> > > On Sat, Sep 16, 2017 at 09:06:03AM +, Peter Palfrader wrote:
> > > 
> > > > Please let us know if you intent to fix this.
> > > > 
> > > > We will have to remove this mirror from our list unless this gets
> > > > resolved soon.
> > > 
> > > Hello,
> > > 
> > > Disk space problems, my deepest apologies for not responding earlier.
> > > Emptying up some space, running ftpsync by hand and we should be okay
> > 
> > While you're at it, maybe upgrade your ftpsync version to a more recent
> > one?
> 
> Just did, running once more.
> 
> > 
> > http://ftp.debian.org/debian/project/ftpsync/
> > 
> > (Also, given that you were out for a bit, you might run into the
> > --max-delete limit used by default.  If so, you'll have to run ftpsync a
> > few times.)
> 
> Noted, I'll be sure to run by hand a couple of times more. I can see the
> limit error you are referring to in the emails I'm getting from ftpsync.
> 
> Many thanks,
> Athanasios

Hello again,

After several runs, I can see everything runs without complaints. But I
still see red in
https://mirror-master.debian.org/status/mirror-status.html. Can I ask
for a little help, will it go green on its own or do I need to do
something extra?

Kind regards,
Athanasios

> 
> > 
> > -- 
> > |  .''`.   ** Debian **
> >   Peter Palfrader   | : :' :  The  universal
> >  https://www.palfrader.org/ | `. `'  Operating System
> > |   `-https://www.debian.org/
> > 
> 
> -- 
> Athanasios Douitsis
> National Technical University of Athens NOC
> e: aduit...@noc.ntua.gr | t: +302107722409
> 

-- 
Athanasios Douitsis
National Technical University of Athens NOC
e: aduit...@noc.ntua.gr | t: +302107722409

Bug#876132: freetype: Please upgrade to 2.8.1

[Laurent Bigonville]

I've uploaded the new version to the DELAYED/10 queue, please test

Bug#876137: bzip2: Please build udeb package

[Laurent Bigonville]

Source: bzip2
Version: 1.0.6-8.1
Severity: wishlist

Hi,

It would be nice to build an udeb package.

At least one package (freetype) could benefit of it as freetype can
optionally link against bzip to used bzipped compressed fonts.

Regrads,

Laurent Bigonville

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

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

-- no debconf information

Bug#854837: closed by Andreas Tille <ti...@debian.org> (Bug#854837: fixed in dicompyler 0.4.2-4)

[Vojtech Kulvait]

2017-09-18 22:49 GMT+02:00 Vojtech Kulvait :

> HI all,
> Andreas is correct that I was reverting changes in previous patches
> including mine, the reason was that initially I did not have fully patched
> tree. Now I am working on series of patches that will be clearer. Just let
> me to do this in a few days. I also agree to go through stretch-backports
> even if I consider this very conservative policy when current package in
> stretch is nonfunctional.
>
> One thing which I come through when making dicompyler work is that it
> uses wxmpl.py file that is outdated. I think It would by wise to substitute
> it by the new release of that file from https://github.com/NOAA-
> ORR-ERD/wxmpl
> What bothers me is the license. This file is released under MIT license,
> which should be OK. However even if the old file state
> # See the file "LICENSE" for information on usage and redistribution
> # of this file, and for a DISCLAIMER OF ALL WARRANTIES.
> the LICENSE file is not part of the dicompyler sources. So the question is
> how to give credit to wxmpl upstream developer. In this case I am into
> changing source tree and adding at least the https://github.com/NOAA-
> ORR-ERD/wxmpl/blob/master/LICENSE.txt file there.
>
The license file is present and state usage of that part of software.
Therefore everything is OK.

>
> Best,
> Vojtech.
>
> Hi Vojtech,
>> [please keep the bug in CC to make our discussion public.  There is no
>>  point in discussing this privately.]
>>
>> On Mon, Sep 18, 2017 at 03:41:06PM +0200, Vojtech Kulvait wrote:
>> > I have successfully checked out the source from git as kulvait-guest. I
>> > have also created my gpg keys, I am sending you my public key.
>>
>> Fine. There is no need to send me the public key.  Just push it to the
>> PGP mirrors and try to get some signatures from people you are meeting
>> face to face.
>>
>> > Build system really produces the directory egginfo.
>>
>> Yes, it is produced.  But there is no harm done since pybuild is removing
>> it again inside the build process.
>>
>> > I don't know how to get
>> > rid of this in the resulting package. However to spare git repository,
>> it
>> > is wise to create build directory outside source directory and call
>> bulding
>> > routines using
>> > gbp buildpackage --git-export-dir=../dicompyler_builddir
>> > Using that git directory will not be affected. I think previously
>> someone
>> > called gbp buildpackage and then committed changes due to build to the
>> git
>> > repository.
>>
>> Probably not - it was part of the upstream branch in Git.  Anyway, I
>> think we have settled with this issue now since it is not there any
>> more.
>>
>> > Thank you very much for the patch you sent into git. There were however
>> two
>> > additional things to fix. First it was wrong indentation
>>
>> Hmmm, according the wrong identantion this was introduced in your own
>> previous patch.  I've fixed it there in another commit.  However, are
>> you really sure you want to revert the previosly introduced matplotlib
>> compatibility conditionals?  What is wrong in
>>
>>  if matplotlib.__version__ > '1.2':
>>  grid = mpl_Path(contour).contains_points(dosegridpoints)
>>  else:
>>  grid = nx.points_inside_poly(dosegridpoints, contour)
>
>
>> which was introduced in patch enable_later_versions_of_matplotlib.patch
>> and reverted by you later?  Probably we should rather fix it in the
>> initial patch and not do patch reversals later.  This will lead to
>> confusion.
>
>
>> > and second it was
>> > incompatibility with pillow >= 3.0.0. I fixed this and added the new
>> patch
>> > (01.patch). Now it is possible to explore RT data. With the new patch,
>> the
>> > package is finally functional and I suggest propagating current change
>> into
>> > stretch.
>>
>> We can not simply move this to stretch since this is now released.  We
>> can upload to unstable for now and once it is error free there we can
>> upload to stretch-backports.
>>
>> > I have not made changes to changelog since I don't know how. If I
>> increase
>> > release number and add the following to changelog
>> > dicompyler (0.4.2.0-2) UNRELEASED; urgency=high
>> >
>> >   * Works with pillow >=3.0.0 addressing changes due to commit
>> > https://github.com/python-pillow/Pillow/commit/71c95c8e5f3bb
>> a1845444a246d04646825e6bab3
>> > .
>> >   * Indentation fix
>> >
>> >  -- Vojtěch Kulvait   Mon, Sep 18 15:21:26 CEST 2017
>> > It complains that
>> > W: dicompyler source: changelog-should-mention-nmu
>> > W: dicompyler source: source-nmu-has-incorrect-version-number 0.4.2.0-2
>>
>> That's because you are not yet mentioned in debian/control as Uploader.
>> Feel free to add yourself there!
>> Alternatively add a line
>>
>>   * Team upload
>>
>> to silence lintian.
>>
>> > W: dicompyler source: newer-standards-version 4.1.0 (current is 3.9.8)
>>
>> Feel free to ignore this (or better use lintian from unstable).
>>
>> > W: dicompyler: 

Bug#876136: [boomaga] Can't open file from .cache folder

[Gmail]

Package: boomaga
Version: 0.7.1-1+b4
Severity: grave

--- Please enter the report below this line. ---
Hi, boomaga is completly unusable due bug in upstream, see 
https://github.com/Boomaga/boomaga/issues/50




--- System information. ---
Architecture: 
Kernel:   Linux 4.12.0-1-amd64

Debian Release: buster/sid
  900 testing www.deb-multimedia.org 
  900 testing packages.x2go.org 
  900 testing http.debian.net 
  500 stretch download.docker.com 
  500 stable  people.debian.org 
  500 stable  dl.google.com 
  500 jessie  deb.playonlinux.com 
  500 all liveusb.info 

--- Package information. ---
Depends   (Version) | Installed
===-+-
cups| 2.2.4-6
libc6 (>= 2.14) | 
libcups2 (>= 1.4.0) | 
libgcc1  (>= 1:3.0) | 
libpoppler-cpp0v5   (>= 0.46.0) | 
libpoppler68(>= 0.57.0) | 
libqt5core5a(>= 5.9.0~beta) | 
libqt5dbus5  (>= 5.0.2) | 
libqt5gui5   (>= 5.8.0) | 
libqt5printsupport5  (>= 5.0.2) | 
libqt5widgets5   (>= 5.7.0) | 
libsnappy1v5| 
libstdc++6 (>= 5.2) | 


Package's Recommends field is empty.

Package's Suggests field is empty.





-- 
Regards,
Andrey Spitsyn

Bug#875729: libvmime: still FTBFS on Hurd due missed getThreadId implementation

[Carsten Schoenert]

Control: tags -1 pending

Hello Aaron,

On Thu, Sep 14, 2017 at 08:32:00AM -0400, Aaron M. Ucko wrote:
> "Aaron M. Ucko"  writes:
> 
> > Oops.  Perhaps I should have replied via Thunderbird. ;-)
> > Here's the patch for real now.
> 
> Please note that I did not update the patch header to reflect my
> additions, just ran quilt refresh.

no worries, looks good! I made a test build on exodar and the build went
successful, thanks for the updated patch.

Maybe we do a new upload of libvmime in the near future. I want to first
take a closer look at the build issues of kopanocore om kFreeBSD* before.

Regards
Carsten

Bug#873241: cockpit: failing autopkgtests related to phantomjs

[Martin Pitt]

Hello Jeremy,

Jeremy Bicha [2017-08-25 13:13 -0400]:
> cockpit's autopkgtests are failing on Ubuntu 17.10 "artful" now.
> 
> http://autopkgtest.ubuntu.com/packages/c/cockpit/artful/amd64
> 
> Error: PhantomJS or driver broken
> 
> Notably, Qt 5.9 migrated to artful several hours ago and it looks like
> phantomjs uses the Qt WebKit engine.

Just as a sign of life: I'm aware of this, but unfortunately this does not
reproduce locally in a standard autopkgtest artful VM at all. I. e. this looks
like some really subtle breakage, and I don't currently have an idea how to fix
that. But I keep it on my radar.

Martin

Bug#737796: may be use the newly proposed License-grant field

[Tobias Frost]

On Mon, Sep 18, 2017 at 02:15:54PM +0200, Dominique Dumont wrote:
> Hi
> 
> Since the licence text shown in the original report mention "At the 
> discretion 
> of the user of this library,  this software may be licensed under the terms 
> of 
> ..." , I'm wondering if this would better fit in the new License-Grant field 
> [1].
> 
> Thoughts ?

I like this new feature and would be in favour making it real.

-- 
tobi

 
> All the best
> 
> [1] https://bugs.debian.org/786470
> -- 
>  https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
> http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org
> 

Bug#854837: closed by Andreas Tille <ti...@debian.org> (Bug#854837: fixed in dicompyler 0.4.2-4)

[Vojtech Kulvait]

HI all,
Andreas is correct that I was reverting changes in previous patches
including mine, the reason was that initially I did not have fully patched
tree. Now I am working on series of patches that will be clearer. Just let
me to do this in a few days. I also agree to go through stretch-backports
even if I consider this very conservative policy when current package in
stretch is nonfunctional.

One thing which I come through when making dicompyler work is that it
uses wxmpl.py file that is outdated. I think It would by wise to substitute
it by the new release of that file from
https://github.com/NOAA-ORR-ERD/wxmpl
What bothers me is the license. This file is released under MIT license,
which should be OK. However even if the old file state
# See the file "LICENSE" for information on usage and redistribution
# of this file, and for a DISCLAIMER OF ALL WARRANTIES.
the LICENSE file is not part of the dicompyler sources. So the question is
how to give credit to wxmpl upstream developer. In this case I am into
changing source tree and adding at least the
https://github.com/NOAA-ORR-ERD/wxmpl/blob/master/LICENSE.txt file there.

Best,
Vojtech.

Hi Vojtech,
> [please keep the bug in CC to make our discussion public.  There is no
>  point in discussing this privately.]
>
> On Mon, Sep 18, 2017 at 03:41:06PM +0200, Vojtech Kulvait wrote:
> > I have successfully checked out the source from git as kulvait-guest. I
> > have also created my gpg keys, I am sending you my public key.
>
> Fine. There is no need to send me the public key.  Just push it to the
> PGP mirrors and try to get some signatures from people you are meeting
> face to face.
>
> > Build system really produces the directory egginfo.
>
> Yes, it is produced.  But there is no harm done since pybuild is removing
> it again inside the build process.
>
> > I don't know how to get
> > rid of this in the resulting package. However to spare git repository, it
> > is wise to create build directory outside source directory and call
> bulding
> > routines using
> > gbp buildpackage --git-export-dir=../dicompyler_builddir
> > Using that git directory will not be affected. I think previously someone
> > called gbp buildpackage and then committed changes due to build to the
> git
> > repository.
>
> Probably not - it was part of the upstream branch in Git.  Anyway, I
> think we have settled with this issue now since it is not there any
> more.
>
> > Thank you very much for the patch you sent into git. There were however
> two
> > additional things to fix. First it was wrong indentation
>
> Hmmm, according the wrong identantion this was introduced in your own
> previous patch.  I've fixed it there in another commit.  However, are
> you really sure you want to revert the previosly introduced matplotlib
> compatibility conditionals?  What is wrong in
>
>  if matplotlib.__version__ > '1.2':
>  grid = mpl_Path(contour).contains_points(dosegridpoints)
>  else:
>  grid = nx.points_inside_poly(dosegridpoints, contour)


> which was introduced in patch enable_later_versions_of_matplotlib.patch
> and reverted by you later?  Probably we should rather fix it in the
> initial patch and not do patch reversals later.  This will lead to
> confusion.


> > and second it was
> > incompatibility with pillow >= 3.0.0. I fixed this and added the new
> patch
> > (01.patch). Now it is possible to explore RT data. With the new patch,
> the
> > package is finally functional and I suggest propagating current change
> into
> > stretch.
>
> We can not simply move this to stretch since this is now released.  We
> can upload to unstable for now and once it is error free there we can
> upload to stretch-backports.
>
> > I have not made changes to changelog since I don't know how. If I
> increase
> > release number and add the following to changelog
> > dicompyler (0.4.2.0-2) UNRELEASED; urgency=high
> >
> >   * Works with pillow >=3.0.0 addressing changes due to commit
> > https://github.com/python-pillow/Pillow/commit/
> 71c95c8e5f3bba1845444a246d04646825e6bab3
> > .
> >   * Indentation fix
> >
> >  -- Vojtěch Kulvait   Mon, Sep 18 15:21:26 CEST 2017
> > It complains that
> > W: dicompyler source: changelog-should-mention-nmu
> > W: dicompyler source: source-nmu-has-incorrect-version-number 0.4.2.0-2
>
> That's because you are not yet mentioned in debian/control as Uploader.
> Feel free to add yourself there!
> Alternatively add a line
>
>   * Team upload
>
> to silence lintian.
>
> > W: dicompyler source: newer-standards-version 4.1.0 (current is 3.9.8)
>
> Feel free to ignore this (or better use lintian from unstable).
>
> > W: dicompyler: syntax-error-in-debian-changelog line 6 "badly formatted
> > trailer line"
> > W: dicompyler: syntax-error-in-debian-changelog line 9 "found start of
> > entry where expected more change data or trailer"
> > W: dicompyler: debian-changelog-line-too-long line 3
>
> That's due to your indentation mistake.  There is 

Bug#876135: RM: moodle -- RoQA; outdated, open security issues

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove moodle. It was blocked out of stable for a long time, #807317
hasn't seen any followup on the call for help and the version which is now
in unstable is no longer supported with security updates (only 3.x is).

Cheers,
Moritz

Bug#876133: linux-image-4.13.0-trunk-amd64: bluez doesn't work with HSP/HFP on Intel Bluetooth [8087:07dc]

[Jakobus Schürz]

Package: src:linux
Version: 4.13.1-1~exp1
Severity: normal

Dear Maintainer,

on my Laptop with a Intel AC7260 BT combi-card with WIFI and Bluetooth, 
bluetooth profile HSP/HFP is not working correct.
A2DP works fine, but when i change profile with pulseaudio, the following 
floods my journal

Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:transport_set_state() State changed 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B/fd0: TRANSPORT_STATE_ACTIVE -> 
TRANSPORT_STATE_SUSPENDING
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/avdtp.c:avdtp_ref() 0x56333f010090: ref=3
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/a2dp.c:setup_ref() 0x56333eff67b0: ref=1
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/transport.c:transport_set_state() State changed 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B/fd0: TRANSPORT_STATE_ACTIVE -> 
TRANSPORT_STATE_SUSPENDING
Sep 18 22:10:29 aldebaran bluetoothd[11984]: profiles/audio/avdtp.c:avdtp_ref() 
0x56333f010090: ref=3
Sep 18 22:10:29 aldebaran bluetoothd[11984]: profiles/audio/a2dp.c:setup_ref() 
0x56333eff67b0: ref=1
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:media_request_create() Request created: 
method=Release id=7
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:media_owner_add() Owner :1.3276 Request Release
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/transport.c:media_request_create() Request created: 
method=Release id=7
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/transport.c:media_owner_add() Owner :1.3276 Request Release
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/avdtp.c:session_cb()
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/avdtp.c:avdtp_parse_resp() SUSPEND request succeeded
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed: STREAMING -> 
OPEN
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/sink.c:sink_set_state() State changed 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B: SINK_STATE_PLAYING -> 
SINK_STATE_CONNECTED
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:transport_update_playing() 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B/fd0 State=TRANSPORT_STATE_SUSPENDING 
Playing=0
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/a2dp.c:suspend_cfm() Source 0x56333eff41c0: Suspend_Cfm
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:media_request_reply() Request Release Reply Success
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:media_owner_remove() Owner :1.3276 Request Release
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/a2dp.c:a2dp_sep_unlock() SEP 0x56333eff41c0 unlocked
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:transport_set_state() State changed 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B/fd0: TRANSPORT_STATE_SUSPENDING -> 
TRANSPORT_STATE_IDLE
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:media_transport_remove_owner() Transport 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B/fd0 Owner :1.3276
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/transport.c:media_owner_free() Owner :1.3276
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/a2dp.c:setup_unref() 0x56333eff67b0: ref=0
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/a2dp.c:setup_free() 0x56333eff67b0
Sep 18 22:10:29 aldebaran bluetoothd[11984]: bluetoothd[11984]: 
profiles/audio/avdtp.c:avdtp_unref() 0x56333f010090: ref=2
Sep 18 22:10:29 aldebaran bluetoothd[11984]: profiles/audio/avdtp.c:session_cb()
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/avdtp.c:avdtp_parse_resp() SUSPEND request succeeded
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed: STREAMING -> 
OPEN
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/sink.c:sink_set_state() State changed 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B: SINK_STATE_PLAYING -> 
SINK_STATE_CONNECTED
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/transport.c:transport_update_playing() 
/org/bluez/hci0/dev_E8_07_BF_01_97_1B/fd0 State=TRANSPORT_STATE_SUSPENDING 
Playing=0
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/a2dp.c:suspend_cfm() Source 0x56333eff41c0: Suspend_Cfm
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 
profiles/audio/transport.c:media_request_reply() Request Release Reply Success
Sep 18 22:10:29 aldebaran bluetoothd[11984]: 

Bug#851502: Still see this bug

[Nis Martensen]

control: tags 851502 unreproducible moreinfo

> I would like to request severity raised to serious.

Michael, it seems not many people can actually reproduce the bug. I've
tried on stretch and current sid, and reportbug works just fine for me.

Sandro has already pointed out that reportbug requires python 3.5 or
higher and won't work with python 3.4. You are the first who is seeing
the problem even with python 3.5. Can you offer more information?

Bug#119911: still worked in

[Andy Mender]

On Thu, 14 Jan 2016 18:14:24 -0430 PICCORO McKAY Lenz <
mckaygerh...@gmail.com> wrote:
> hi, this is a semi-automated menssage to the ITP issue to not close..
>
> i currently have workin in this package and others, now in few days
> i'll have the finish package, after some test using the g-d-p from git
> with the recently added marathon rules
>
> --
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
>

Hello,

I recently browsed the Debian repositories and noticed that neither
alephone nor marathon packages are available. I had some luck with building
Aleph One from source, but not all functionalities are provided by regular
and -dev packages in the Debian repos. I briefly skimmed through previous
messages to this bug/feature report and noticed not much has changed since
2000.

Is there anyone still doing anything with Aleph One on Debian or is it safe
to assume I can go ahead and try to package it?

Best regards,
Andy

Bug#875606: Debian mirror ftp-nyc.osuosl.org, ftp-chi.osuosl.org: does not sync correctly 4 times a day

[Lance Albertson via RT]

On Mon Sep 18 09:16:15 2017, 875...@bugs.debian.org wrote:
> tracetimestamp is how we monitor mirrors having run.  It's all we know.
> 
> Also, it's just -chi and -nyc.
> 
> compare
> https://mirror-master.debian.org/status/mirror-info/ftp-osl.osuosl.org.html to
> https://mirror-master.debian.org/status/mirror-info/ftp- nyc.osuosl.org.html
> or https://mirror-master.debian.org/status/mirror-info/ftp-chi.osuosl.org.html
> that'll show you the mirror age over time

I'm not sure what's causing this however they seem to be in sync as of right
now. We've added nagios monitoring for the trace files on each host so we can
hopefully have better insight into the issue. Please let us know if we start
lagging behind again but I will do my best to check your mirror status site in
the coming days.

Thanks-

-- 
Lance Albertson
Director
Oregon State University | Open Source Lab 

Bug#875797: fixed up pkging is available from http://github.com/yarikoptic/wrapt

[Yaroslav Halchenko]

On Thu, 14 Sep 2017, Yaroslav Halchenko wrote:


> On Thu, 14 Sep 2017, Yaroslav Halchenko wrote:
> > I pushed branch debian/pike with all needed changes to my "fork" of
> > upstream (since you package on top of it) to
> > http://github.com/yarikoptic/wrapt
> > Please consider adopting ;)

> > Trying to build now 

> may be not that "easy" :-( :
> https://github.com/GrahamDumpleton/wrapt/issues/107

nah -- it is all easy and dandy -- needed a fixup within debian/rules.
Done now and pushed.

If there would be no objections, I will NMU to 3-day delayed tomorrow.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Lisandro Damián Nicanor Pérez Meyer]

On 18 September 2017 at 16:57, Helmut Grohne  wrote:
> Source: qtbase-opensource-src
> Version: 5.9.1+dfsg-9
> Severity: wishlist
> User: helm...@debian.org
> Usertags: rebootstrap
>
> qtbase-opensource-src fails to cross build from source, because it uses
> the build architecture compiler and stuff.
>
> I looked a bit and it seems one should pass something else for -platform
> for cross compilation. It seems to search directories below mkspecs/ and
> for arm64 and armel there are particular directories available. We only
> need to come up with the right platform_arg (see patch attached).
>
> After doing so, the build fails to run its own qmake. That's kinda
> expected. It seems that the remedy is passing -external-hostbindir and
> it expects to find a qmake binary in that directory. With a
> self-dependency, we can use the build architecture qmake and the build
> goes a lot further until it bumps into #794103:

The only way I could accept that if we could build-depend on a
specific version (the same version we are trying to compile).

Helmut told me that's not possible, and I know from experience that
having a window opened to build qt with an oder qmake it's calling for
big troubles.

Another possible way to do it is by bootstrapping qmake if build != host.

Bug#876132: freetype: Please upgrade to 2.8.1

[Laurent Bigonville]

Source: freetype
Version: 2.8-0.2
Severity: wishlist

Hi,

2.8.1 has been released and according to the website it provides:

FreeType 2.8.1 has been released. This is mainly a maintenance release
with one important change: By default, FreeType now offers high quality
LCD-optimized output without resorting to ClearType techniques of
resolution tripling and filtering. In this method, called Harmony, each
color channel is generated separately after shifting the glyph outline,
capitalizing on the fact that the color grids on LCD panels are shifted
by a third of a pixel. This output is indistinguishable from ClearType
with a light 3-tap filter.

Other changes: https://sourceforge.net/projects/freetype/files/freetype2/2.8.1/

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

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

Bug#876131: qtbase-opensource-src FTCBFS: uses the build architecture toolchain

[Helmut Grohne]

Source: qtbase-opensource-src
Version: 5.9.1+dfsg-9
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap

qtbase-opensource-src fails to cross build from source, because it uses
the build architecture compiler and stuff.

I looked a bit and it seems one should pass something else for -platform
for cross compilation. It seems to search directories below mkspecs/ and
for arm64 and armel there are particular directories available. We only
need to come up with the right platform_arg (see patch attached).

After doing so, the build fails to run its own qmake. That's kinda
expected. It seems that the remedy is passing -external-hostbindir and
it expects to find a qmake binary in that directory. With a
self-dependency, we can use the build architecture qmake and the build
goes a lot further until it bumps into #794103:

> make[2]: Entering directory 
> '/<>/qtbase-opensource-src-5.9.1+dfsg/config.tests/unix/psql'
> aarch64-linux-gnu-g++ -c -g -O2 
> -fdebug-prefix-map=/<>/qtbase-opensource-src-5.9.1+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -O2 -Wall -W -fPIC  -I. 
> -I/<>/qtbase-opensource-src-5.9.1+dfsg/mkspecs/linux-aarch64-gnu-g++
>  -o psql.o psql.cpp
> psql.cpp:40:10: fatal error: libpq-fe.h: No such file or directory
>  #include "libpq-fe.h"
>   ^~~~
> compilation terminated.
> Makefile:171: recipe for target 'psql.o' failed
> make[2]: *** [psql.o] Error 1
> make[2]: Leaving directory 
> '/<>/qtbase-opensource-src-5.9.1+dfsg/config.tests/unix/psql'

Still, that's a lot more than the initial attempt. Please have a look at
the patch and use the bits that look reasonable. Improve the others. ;)

Helmut
diff --minimal -Nru qtbase-opensource-src-5.9.1+dfsg/debian/changelog 
qtbase-opensource-src-5.9.1+dfsg/debian/changelog
--- qtbase-opensource-src-5.9.1+dfsg/debian/changelog   2017-08-20 
18:13:27.0 +0200
+++ qtbase-opensource-src-5.9.1+dfsg/debian/changelog   2017-09-18 
21:16:40.0 +0200
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.9.1+dfsg-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Partially fix FTCBFS.
+
+ -- Helmut Grohne   Mon, 18 Sep 2017 21:16:40 +0200
+
 qtbase-opensource-src (5.9.1+dfsg-9) unstable; urgency=medium
 
   [ Lisandro Damián Nicanor Pérez Meyer ]
diff --minimal -Nru qtbase-opensource-src-5.9.1+dfsg/debian/control 
qtbase-opensource-src-5.9.1+dfsg/debian/control
--- qtbase-opensource-src-5.9.1+dfsg/debian/control 2017-08-20 
18:13:27.0 +0200
+++ qtbase-opensource-src-5.9.1+dfsg/debian/control 2017-09-18 
21:16:40.0 +0200
@@ -62,6 +62,7 @@
libxrender-dev,
pkg-kde-tools (>= 0.15.17~),
publicsuffix,
+   qt5-qmake:native ,
unixodbc-dev,
zlib1g-dev
 Build-Depends-Indep: libqt5sql5-sqlite (>= 5.8.0+dfsg~) ,
diff --minimal -Nru qtbase-opensource-src-5.9.1+dfsg/debian/rules 
qtbase-opensource-src-5.9.1+dfsg/debian/rules
--- qtbase-opensource-src-5.9.1+dfsg/debian/rules   2017-08-20 
18:13:27.0 +0200
+++ qtbase-opensource-src-5.9.1+dfsg/debian/rules   2017-09-18 
21:16:40.0 +0200
@@ -3,11 +3,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1

-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
-DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
-DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
-DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
+include /usr/share/dpkg/architecture.mk

 export PATH := $(PATH):$(shell pwd)/bin
 export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags 
--get CPPFLAGS) $(shell getconf LFS_CFLAGS)
@@ -61,6 +57,12 @@
 else
$(error Unknown qmake mkspec for $(DEB_HOST_ARCH_OS))
 endif
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+mkspec_osmap_kfreebsd = gnukfreebsd
+platform_arg = $(or 
$(mkspec_osmap_$(DEB_HOST_ARCH_OS)),$(DEB_HOST_ARCH_OS))-$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_LIBC)$(filter-out
 base,$(DEB_HOST_ARCH_ABI))-g++
+extra_configure_opts += -external-hostbindir 
/usr/lib/$(DEB_BUILD_MULTIARCH)/qt5/bin
+endif
+

 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))

Bug#876130: libcamp-dev: fails to upgrade from 'stable' to 'sid' - trying to overwrite /usr/include/camp/args.hpp

[Andreas Beckmann]

Package: libcamp-dev
Version: 0.8.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Selecting previously unselected package libcamp-dev:amd64.
  Preparing to unpack .../libcamp-dev_0.8.1-1_amd64.deb ...
  Unpacking libcamp-dev:amd64 (0.8.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libcamp-dev_0.8.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/include/camp/args.hpp', which is also in package 
libcamp0.7-dev 0.7.1.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libcamp-dev_0.8.1-1_amd64.deb


cheers,

Andreas


libcamp0.7-dev=0.7.1.3-1_libcamp-dev=0.8.1-1.log.gz
Description: application/gzip

Bug#876072: llvm-toolchain-4.0: Please backport rL298624 needed for rustc 1.19 on armhf

[Sylvestre Ledru]

For the record, the patch was already applied to 3.9 :/

sorry about that!

S


Le 18/09/2017 à 10:04, Ximin Luo a écrit :

Source: llvm-toolchain-4.0
Version: 1:4.0.1-1
Severity: important
Tags: patch upstream

Dear Maintainer,

rustc 1.19 armhf tests fail (I tried on asachi, buildds are slow atm) due to

https://bugs.llvm.org/show_bug.cgi?id=32379
https://github.com/rust-lang/rust/issues/40593

This is already fixed upstream, please backport:

https://reviews.llvm.org/rL298624

Raw diff: https://reviews.llvm.org/D31265?download=true applies cleanly with
offset to the Debian package, you just need to `quilt refresh` it.

X

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

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

___
Pkg-llvm-team mailing list
pkg-llvm-t...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#876129: libij-java: fails to upgrade from 'testing' - trying to overwrite /usr/share/java/ij.jar

[Andreas Beckmann]

Package: libij-java
Version: 1.51p+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package libij-java.
  Preparing to unpack .../10-libij-java_1.51p+dfsg-1_all.deb ...
  Unpacking libij-java (1.51p+dfsg-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-4W4asG/10-libij-java_1.51p+dfsg-1_all.deb (--unpack):
   trying to overwrite '/usr/share/java/ij.jar', which is also in package 
imagej 1.51i+dfsg-2
  Selecting previously unselected package gconf-gsettings-backend:amd64.
  Preparing to unpack .../11-gconf-gsettings-backend_3.2.6-4+b1_amd64.deb ...
  Unpacking gconf-gsettings-backend:amd64 (3.2.6-4+b1) ...
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-4W4asG/10-libij-java_1.51p+dfsg-1_all.deb


cheers,

Andreas


imagej=1.51i+dfsg-2_libij-java=1.51p+dfsg-1.log.gz
Description: application/gzip

Bug#876128: manpages-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/man/man4/console_ioctl.4.gz

[Andreas Beckmann]

Package: manpages-dev
Version: 4.13-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Selecting previously unselected package manpages-dev.
  Preparing to unpack .../manpages-dev_4.13-2_all.deb ...
  Unpacking manpages-dev (4.13-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-dev_4.13-2_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man4/console_ioctl.4.gz', which is also 
in package manpages 4.12-2
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-dev_4.13-2_all.deb


cheers,

Andreas


manpages=4.12-2_manpages-dev=4.13-2.log.gz
Description: application/gzip

Bug#876127: kpat: crash on ctrl+shift+n

[treaki]

Package: kpat
Version: 4:4.13.1-1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
i was in a quite narrow window (about 700 pixel high and 280 pixel with), 
finished a klondike game, pressed ctrl+shift+n and wanted to start a yukon 
game, than it crashed

ill attach the report of the kde crash wizard 

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

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

Versions of packages kpat depends on:
ii  kde-runtime 4:4.14.2-2
ii  kdegames-card-data  4:4.14.2-1
ii  libc6   2.19-18+deb8u7
ii  libkdecore5 4:4.14.2-5+deb8u1
ii  libkdegames6abi14:4.14.2-1
ii  libkdeui5   4:4.14.2-5+deb8u1
ii  libkio5 4:4.14.2-5+deb8u1
ii  libknewstuff3-4 4:4.14.2-5+deb8u1
ii  libqt4-svg  4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml  4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libstdc++6  4.9.2-10

Versions of packages kpat recommends:
ii  khelpcenter4  4:4.14.2-2

kpat suggests no packages.

-- debconf-show failed
Application: kpat (3.6)
KDE Platform Version: 4.14.2
Qt Version: 4.8.6
Operating System: Linux 3.16.0-4-amd64 x86_64
Distribution: Debian GNU/Linux 8.7 (jessie)

-- Information about the crash:


The crash does not seem to be reproducible.

-- Backtrace:
Application: KPatience (kpat), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f5ebb046edc in KSharedDataCache::find(QString const&, QByteArray*) 
const () from /usr/lib/libkdecore.so.5
#7  0x7f5ebb8037c5 in KImageCache::findPixmap(QString const&, QPixmap*) 
const () from /usr/lib/libkdeui.so.5
#8  0x00458c17 in ?? ()
#9  0x00458df0 in KAbstractCardDeck::cardPixmap(unsigned int, bool) ()
#10 0x0045b8e2 in KCard::paint(QPainter*, QStyleOptionGraphicsItem 
const*, QWidget*) ()
#11 0x7f5eba40ba91 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x7f5eba40c8c7 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x7f5eba40cfe0 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x7f5eba42c17f in QGraphicsView::paintEvent(QPaintEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#15 0x7f5eb9e3f748 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#16 0x7f5eba20183e in QFrame::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x7f5eba42ae81 in QGraphicsView::viewportEvent(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#18 0x7f5ebaa9b886 in 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () 
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#19 0x7f5eb9dec46c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#20 0x7f5eb9df2fa8 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#21 0x7f5ebb79a1aa in KApplication::notify(QObject*, QEvent*) () from 
/usr/lib/libkdeui.so.5
#22 0x7f5ebaa9b71d in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#23 0x7f5eb9e39e1d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#24 0x7f5eb9e3a8e5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#25 0x7f5eb9e3998a in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#26 0x7f5eb9e3a8e5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#27 0x7f5eb9e3998a in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#28 0x7f5eba00b855 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#29 0x7f5eb9e2e560 in QWidgetPrivate::syncBackingStore() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#30 0x7f5eb9e3f818 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#31 0x7f5eba21bb23 in QMainWindow::event(QEvent*) () from 

Bug#876126: toilet FTCBFS: sets PKG_CONFIG_LIBDIR=/dev/null

[Helmut Grohne]

Source: toilet
Version: 0.3-1.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

toilet fails to cross build from source, because the upstream configure
initializes PKG_CONFIG_LIBDIR to "/dev/null" when cross building is
detected. That breaks Debian's pkg-config-cross-wrapper and thus caca.pc
is not found. After removing the setting, toilet cross builds
successfully. Please consider applying the attached patch.

Helmut
From: Helmut Grohne 
Subject: remove PKG_CONFIG_LIBDIR override

The pkg-config cross wrappers will do nothing when PKG_CONFIG_LIBDIR is set. By
setting it to /dev/null, it will not find any package. Leaving it unset is what
we need.

Index: toilet-0.3/configure.ac
===
--- toilet-0.3.orig/configure.ac
+++ toilet-0.3/configure.ac
@@ -18,12 +18,6 @@
 AC_EGREP_CPP(yes, foo)
 PKG_PROG_PKG_CONFIG()
 
-dnl Don't let pkg-config fuck our cross-compilation environment
-m4_pattern_allow([^PKG_CONFIG_LIBDIR$])
-if test "$build" != "$host" -a "${PKG_CONFIG_LIBDIR}" = ""; then
-  export PKG_CONFIG_LIBDIR=/dev/null
-fi
-
 AC_CHECK_HEADERS(sys/ioctl.h)
 
 AC_CACHE_CHECK([for TIOCGWINSZ],

Bug#876071: [Pkg-libvirt-maintainers] Bug#876071: Bug#876071: libvirt-daemon-system: Mount namespace and AppArmor confinement are incompatible => breaks networking

[Guido Günther]

Hi,
On Mon, Sep 18, 2017 at 11:13:02AM +0200, intrigeri wrote:
> Hi,
> 
> Guido Günther:
> > control: forwarded -1 
> > https://www.redhat.com/archives/libvir-list/2017-September/msg00457.html
> 
> > I saw the same on Friday and used the patch reference above (which
> > basically does the same, you were on cc: ;)…
> 
> Oops, sorry! Email sent to my +libvirt@ email address lands into
> a folder dedicated to libvir-l...@redhat.com, that I admit I read only
> from time to time given the amount of traffic :/

…and I missed to add Acked-By for your ACKs since I didn't read the ML
first. Sorry.

> > Should that make a difference? Did you check if the vm profile did get
> > recreated correclt?
> 
> My bad again: adding attach_disconnected is enough once I delete the
> VM profile to force it to be updated. (But by the way, off-topic:
> shouldn't this happen automatically when the template is updated?)

In my naive world I would expect the profile to be deleted on VM
shutdown. virt-aa-helper even has a -D option and I enabled (this instead
of only unloading the profile) with the current upload.
Cheers,
 -- Guido

> 
> At least this bug documents the problem for Debian users :)
> 
> Thanks!
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#876125: haskell-x509-validation: unsatisfiable B-D: libghc-x509-dev (< 1.7) but 1.7.2-1+b1 is to be installed

[Andreas Beckmann]

Source: haskell-x509-validation
Version: 1.6.5-2
Severity: serious
Tags: sid buster
Justification: fails to build from source (but built successfully in the past)

haskell-x509-validation cannot be built in sid any longer since a newer
version of haskell-x509 was uploaded.


Andreas

Bug#870909: RFS: cxlflash/4.3.2493-1 [ITP] -- IBM Data Engine for NoSQL Software Libraries

[Rodrigo]

Hi,


The latest version of this package fix the issues pointed in the 
previous comment, as well as other points made in mentors.debian.


Here is the link to the .dsc -> 
https://mentors.debian.net/debian/pool/main/c/cxlflash/cxlflash_4.3.2554-1.dsc



Thanks,
Rodrigo R. Galvao

Bug#876102: udev: boot fails x86 32-bit debian 9 w/ kernel 4.9.50

[Michael Biebl]

Am 18.09.2017 um 15:29 schrieb William Herrin:
> Package: udev
> Version: 232-25+deb9u1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> upgrade from debian 8 custom kernel 3.14.79 to debian 9 custom kernel 4.9.50
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> apt-get dist-upgrade. dpkg -i kernel. reboot.
> 
>* What was the outcome of this action?
> boot failed; filesystems other than root not mounted. Drop to emergency shell.
> 
>* What outcome did you expect instead?
> boot succeeded
> 
> details: udev created the basic hard disk devices (/dev/vd*) but did not
> create the /dev/disk and /dev/block directory trees and did not mount the
> the /home filesystem from /dev/vdc1 or activate the swap from /dev/vdb1 
> even if the /dev/vd device was explicitly referenced in /etc/fstab.
> 
> 
> This only happened on my sole remaining 32 bit VM. I did not experience the
> problem on any of the x86_64 servers I upgraded.
> 
> I did not experience the problem when booting debian 9 under kernel 3.14.79.
> 
> The problem happened with both the x86 and x86_64 compiles of kernel 4.9.50
> when booting the 32-bit linux install. The same kernel 4.9.50 x86_64 image
> booted successfully on other servers running debian 9 x86_64.
> 

Is the problem reproducible with a Debian provided kernel?




signature.asc
Description: OpenPGP digital signature

Bug#876124: expeyes-web: fails to install: expeyes-web.postinst: cannot create /etc/apache2/sites-available/apache-expeyes-vhost.conf: Directory nonexistent

[Andreas Beckmann]

Package: expeyes-web
Version: 4.2.1+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package expeyes-web.
  (Reading database ... 
(Reading database ... 11364 files and directories currently installed.)
  Preparing to unpack .../expeyes-web_4.2.1+dfsg-2_all.deb ...
  Unpacking expeyes-web (4.2.1+dfsg-2) ...
  Setting up expeyes-web (4.2.1+dfsg-2) ...
  Installing a virtual server for Apache2
  /var/lib/dpkg/info/expeyes-web.postinst: 43: 
/var/lib/dpkg/info/expeyes-web.postinst: cannot create 
/etc/apache2/sites-available/apache-expeyes-vhost.conf: Directory nonexistent
  dpkg: error processing package expeyes-web (--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   expeyes-web


cheers,

Andreas


expeyes-web_4.2.1+dfsg-2.log.gz
Description: application/gzip

Bug#792101: gitea ITS NOT GOGS alias or clone

[PICCORO McKAY Lenz]

Debian packaging pretend to made a simple gogs virtual package provided by
gitea..

the gitea package roadmap pretend to separate from gogs, and are complety
different..

gogs are focused on simplicity, no new features and only security fixeds
gitea are focused on new features and changes too many ..

the gitea package can be a pain to mantain in debian...

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#870906: ITP: pynmea2 - pynmea2 is a python library for the NMEA 0183 protocol

[Herbert Fortes]

Hi Joachim Langenbach,

> Hi Herbert,
> 
> I managed to upload the version 1.9.0 and (hopefully) fixed your hints. May 
> you 
> have a look at it?
> 

I will look at it tomorrow morning.



Regards,
Herbert
 

Bug#780606: a way to going to package

[PICCORO McKAY Lenz]

the insane amout of dependences make the work of this package a hard made..

but a way to do its:

1) makde a package that only use the downloaded sources that ship all
depends
2) in the way the depends get packaged in debian, so make it depends on gogs

the other way its that do not make usage of thos depends pacakges that
change too many in the time!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#876123: libpcap0.8-dev: `pcap-config --libs` output starting with a space may cause FTBFS

[Lukas Schwaighofer]

Package: libpcap0.8-dev
Version: 1.8.1-4
Severity: important
X-Debbugs-CC: pkg-security-t...@lists.alioth.debian.org


Dear libpcap maintainer,

the fix for Bug#760370 [1] has caused the output of
pcap-config --libs
to start with a space.  This appears to be a problem for applications
using the output of that directly with cmake.  At least for
openvas-libraries (manged by the pkg-security-team I've put in CC), the
change results in a FTBFS [2] with cmake reporting:

  Target "openvas_misc_shared" links to item " -lpcap" which has
  leading or trailing whitespace.  This is now an error according to
  policy CMP0004.

While we can fix this for the openvas-libraries package, this may
affect other projects using libpcap and cmake as well.

Thanks
Lukas

[1] https://bugs.debian.org/760370
[2] https://bugs.debian.org/876093

Bug#777291: gpm systemd service

[Axel Beckert]

Hi Andreas,

Andreas Henriksson wrote:
> > > The Debian version contains a home-grown config file parsing
> > > feature. This should rather be implemented by the daemon itself (if
> > > needed, or the config file deprecated).
> > 
> > I tend to disagree here. The config parsing feature could be
> > implemented as patch against upstream to easier keep up with upstream
> > changes.
> 
> Not sure if we disagree or agree really. To clarify:
> I don't think the config file parsing should be implemented
> in the init script itself.

I understood you. And IMHO we disagree — at least unless config file
parsing is added upstream to the daemon.

But given that gpm is upstream more or less in maintenance mode, I
have doubts that this will happen anytime soon.

To be sure I've asked upstream and here's his reply:

| hmm - is that person willing to implement it cleanly?
|
| In general, I am very happy if someone updates the code upstream and
| if it is clean code - the more welcome it is

But at least I won't implement that myself. And I don't want to get
rid of the config file either, at least not until there's a good
replacement for it.

So we indeed agree that having the config file parsing inside the
daemon would be nice. But we disagree on the alternative, because from
my point of view deprecating the config file is not an option.

> If you prefer carrying the implementation as a patch to the daemon,
> well that's your call.

No, I meant a patch against the upstream init.d script to not have to
check upstream's init.d script for changes upon every new upstream
release. (Which is the current case.)

But thinking about it, you're right that this config file parser will
also also be needed for .service file. So if we really want a .service
file for gpm in Debian (and no patch for config file parsing inside
the daemon is submitted), we need a wrapper script around the daemon
which then can be used by the init script and the .service file to
avoid code duplication. We though should be able to base that wrapper
script on the current debian init.d script.

And yes, once that works out (and maybe some slight patching of
upstream's init.d script), I'll send that upstream. But I won't send
incomplete or untested stuff to upstream.

> (I see the old maintenance style was to not collaborate with upstream in
> favour of wasting time on rebasing large patch-sets, but was naively
> hoping that would change with the new maintenance.

JFTR: I know the current upstream developer in real-life for many
years and we even occassionally meet for lunch or so. (Without such a
good contact to upstream, I probably wouldn't have adopted this
package.)

> > > The gpm daemon is one of those long-standing things which likely
> > > contains alot of legacy code. It would be nice if the attack surface
> > > could be limited by applying some of the systemd security features
> > > to the service as a future further improvement. eg. Protect*,
> > > Private*, *Privileges, *Capabilit*, etc. See:
> > > https://www.freedesktop.org/software/systemd/man/systemd.exec.html
> > 
> > I strongly disagree here and surely won't propagate that. From my
> > point of view KISS is the far better security concept than adding
> > systemd bloat.
> 
> Security is bloat?

No, security is important. systemd and especially linking against its
libraries is bloat. It adds additional complexity and more complexity
in most cases means _more_ attack surface and hence less security.

We though can discuss about using Linux capabilities and setcap in the
maintainer scripts if that helps to run gpm under a non-privileged
user — usually with a fallback to run setuid.

I'll probably also need to check if gpm works at all on non-linux
architectures. At least FreeBSD has its own gpm-alike functionality
already built-in, so there's probably no or at least less need for gpm
on Debian GNU/kFreeBSD. Not sure about GNU/Hurd. Samuel probably can
tell.

Samuel: Does GNU/Hurd has mouse support on the console? Or does gpm
work there?

Any systemd feature which is only an option or so in a .service file,
.tmpfiles file, etc. and which doesn't imply changes which make gpm
non-working under other init systems present in Debian (sysv, openrc,
etc.), are of course fine, too.

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

Bug#875487: Debian mirror debian.noc.ntua.gr: not updating, broken ssh-push

[Athanasios Douitsis]

On Mon, Sep 18, 2017 at 03:24:36PM +, Peter Palfrader wrote:

> On Mon, 18 Sep 2017, Athanasios Douitsis wrote:
> 
> > On Sat, Sep 16, 2017 at 09:06:03AM +, Peter Palfrader wrote:
> > 
> > > Please let us know if you intent to fix this.
> > > 
> > > We will have to remove this mirror from our list unless this gets
> > > resolved soon.
> > 
> > Hello,
> > 
> > Disk space problems, my deepest apologies for not responding earlier.
> > Emptying up some space, running ftpsync by hand and we should be okay
> 
> While you're at it, maybe upgrade your ftpsync version to a more recent
> one?

Just did, running once more.

> 
> http://ftp.debian.org/debian/project/ftpsync/
> 
> (Also, given that you were out for a bit, you might run into the
> --max-delete limit used by default.  If so, you'll have to run ftpsync a
> few times.)

Noted, I'll be sure to run by hand a couple of times more. I can see the
limit error you are referring to in the emails I'm getting from ftpsync.

Many thanks,
Athanasios

> 
> -- 
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
> 

-- 
Athanasios Douitsis
National Technical University of Athens NOC
e: aduit...@noc.ntua.gr | t: +302107722409

Bug#876121: FTBFS: error: 'std::index_sequence' has not been declared

[Oliver Kurth]

We see the same issue in our internal tests at VMware. The solution seems to be 
to set CXXFLAGS=-std=c++14 for the configure command:


CXXFLAGS=-std=c++14 ./configure --without-kernel-modules


I need to find a way to put this into the configure script itself. I wonder how 
other packages are handling this issue?


Oliver

Bug#868786: shogun FTBFS on arm64 with libeigen3-dev 3.3.4-2

[Anton Gladky]

Hi Graham,

thanks, feel free to upload.

Regards

Anton


2017-09-18 20:15 GMT+02:00 Graham Inggs :
> Control: reassign -1 src:eigen3 3.3.4-1
> Control: affects -1 src:shogun
> Control tags -1 + fixed-upstream patch
>
> Hi Anton
>
> This turned out to be fixed in Eigen upstream (patch attached).
>
> Let me know if I should go ahead with a team upload.
>
> Regards
> Graham

Bug#868786: shogun FTBFS on arm64 with libeigen3-dev 3.3.4-2

[Graham Inggs]

Control: reassign -1 src:eigen3 3.3.4-1
Control: affects -1 src:shogun
Control tags -1 + fixed-upstream patch

Hi Anton

This turned out to be fixed in Eigen upstream (patch attached).

Let me know if I should go ahead with a team upload.

Regards
Graham
Description: Fix compilation of Jacobi rotations with ARM NEON
 some specializations of internal::conj_helper were missing.
Bug: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1436
Bug-Debian: https://bugs.debian.org/868786
Origin: upstream, https://bitbucket.org/eigen/eigen/commits/d781c1de9834/
Author: Gael Guennebaud 
Last-Update: 2017-06-15
--- a/Eigen/Core
+++ b/Eigen/Core
@@ -352,6 +352,7 @@
 #include "src/Core/MathFunctions.h"
 #include "src/Core/GenericPacketMath.h"
 #include "src/Core/MathFunctionsImpl.h"
+#include "src/Core/arch/Default/ConjHelper.h"
 
 #if defined EIGEN_VECTORIZE_AVX512
   #include "src/Core/arch/SSE/PacketMath.h"
--- a/Eigen/src/Core/arch/AVX/Complex.h
+++ b/Eigen/src/Core/arch/AVX/Complex.h
@@ -204,23 +204,7 @@
   }
 };
 
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet4cf pmadd(const Packet8f& x, const Packet4cf& y, const Packet4cf& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet4cf pmul(const Packet8f& x, const Packet4cf& y) const
-  { return Packet4cf(Eigen::internal::pmul(x, y.v)); }
-};
-
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet4cf pmadd(const Packet4cf& x, const Packet8f& y, const Packet4cf& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet4cf pmul(const Packet4cf& x, const Packet8f& y) const
-  { return Packet4cf(Eigen::internal::pmul(x.v, y)); }
-};
+EIGEN_MAKE_CONJ_HELPER_CPLX_REAL(Packet4cf,Packet8f)
 
 template<> EIGEN_STRONG_INLINE Packet4cf pdiv(const Packet4cf& a, const Packet4cf& b)
 {
@@ -400,23 +384,7 @@
   }
 };
 
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet2cd pmadd(const Packet4d& x, const Packet2cd& y, const Packet2cd& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet2cd pmul(const Packet4d& x, const Packet2cd& y) const
-  { return Packet2cd(Eigen::internal::pmul(x, y.v)); }
-};
-
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet2cd pmadd(const Packet2cd& x, const Packet4d& y, const Packet2cd& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet2cd pmul(const Packet2cd& x, const Packet4d& y) const
-  { return Packet2cd(Eigen::internal::pmul(x.v, y)); }
-};
+EIGEN_MAKE_CONJ_HELPER_CPLX_REAL(Packet2cd,Packet4d)
 
 template<> EIGEN_STRONG_INLINE Packet2cd pdiv(const Packet2cd& a, const Packet2cd& b)
 {
--- a/Eigen/src/Core/arch/AltiVec/Complex.h
+++ b/Eigen/src/Core/arch/AltiVec/Complex.h
@@ -224,23 +224,7 @@
   }
 };
 
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet2cf pmadd(const Packet4f& x, const Packet2cf& y, const Packet2cf& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet2cf pmul(const Packet4f& x, const Packet2cf& y) const
-  { return Packet2cf(internal::pmul(x, y.v)); }
-};
-
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet2cf pmadd(const Packet2cf& x, const Packet4f& y, const Packet2cf& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet2cf pmul(const Packet2cf& x, const Packet4f& y) const
-  { return Packet2cf(internal::pmul(x.v, y)); }
-};
+EIGEN_MAKE_CONJ_HELPER_CPLX_REAL(Packet2cf,Packet4f)
 
 template<> EIGEN_STRONG_INLINE Packet2cf pdiv(const Packet2cf& a, const Packet2cf& b)
 {
@@ -416,23 +400,8 @@
 return pconj(internal::pmul(a, b));
   }
 };
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet1cd pmadd(const Packet2d& x, const Packet1cd& y, const Packet1cd& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet1cd pmul(const Packet2d& x, const Packet1cd& y) const
-  { return Packet1cd(internal::pmul(x, y.v)); }
-};
 
-template<> struct conj_helper
-{
-  EIGEN_STRONG_INLINE Packet1cd pmadd(const Packet1cd& x, const Packet2d& y, const Packet1cd& c) const
-  { return padd(c, pmul(x,y)); }
-
-  EIGEN_STRONG_INLINE Packet1cd pmul(const Packet1cd& x, const Packet2d& y) const
-  { return Packet1cd(internal::pmul(x.v, y)); }
-};
+EIGEN_MAKE_CONJ_HELPER_CPLX_REAL(Packet1cd,Packet2d)
 
 template<> EIGEN_STRONG_INLINE Packet1cd pdiv(const Packet1cd& a, const Packet1cd& b)
 {
--- /dev/null
+++ b/Eigen/src/Core/arch/Default/ConjHelper.h
@@ -0,0 +1,29 @@
+
+// This file is part of Eigen, a lightweight C++ template library
+// for linear algebra.
+//
+// Copyright (C) 2017 Gael Guennebaud 
+//
+// This Source Code Form is subject to the terms of the Mozilla
+// Public License v. 2.0. If a copy of the MPL was not 

Bug#876122: spam accumulating in debian-embedded archive

[ydirson]

Package: lists.debian.org

The last 5 months of debian-embedded archive is essentially spam.
At least some of them are rejected by my ISP's MTA with a 500, and that
causes reports from the list server that mails to me are bouncing, which
is quite uncomfortable :)

Bug#868258: Patches or pull request before updating to 4.13

[Nicholas D Steeves]

Hi Dimitri,

List of patches against 4.12-1 is at the bottom.  Please apply them
before merging 4.13.  In particular this is essential for 0001.  While
I don't use Ubuntu, let's prioritize getting this package into great
shape before 18.04's final merge from Debian!

> > >> > M 0002-Ignore-.pc-the-quilt-state-tracking-dir.patch
> > >> >   * I read that this is supposed to be standard in dgit repos
> > >>
> > >> True, but upstream tarball ships .gitignore, and i'd rather not patch
> > >> upstream .gitignore =/
> > >
> > > In that case, lets submit the patch upstream?  I'd be happy to, if
> > > you're busy
> >
> > possibly.
> 
> Should I submit this patch upstream or wait for you to?

I have not yet submitted this one upstream.

> > >> > I 0006-Exclude-non-free-RFC-BCP78-files-affects-test-suite.patch
> > >>
> > As i read it is this. The whole RFC is subject to BCP 79, which states
> > that a subset of the document - the code component, is only subject to
> > BSD license as long as both the BSD license and the IETF copyright is
> > included. The whole text of RFC does not follow the copyright, only
> > the the code component which is only under the bsd as documented in
> > the sha.h.
[...]
> 
> Thank you.  If I don't hear back from you by Aug 9th I'll ask
> debian-legal for their analysis.  As it stands the presently not excluded
> tests/sha-stuff needs to be added to debian/copyright, and it might also
> be a good idea to add a README.copyright explaining how this
> licensing functions.

You were right!  Patch accepted upstream:
https://github.com/kdave/btrfs-progs/commit/fc567cfda15fbe7ca04aeb623f4682a7ac089348

If you prefer to pull from a git remote, pull from the
proposed-pre-4.13-1 branch of https://github.com/sten0/btrfs-progs.git

[I]mportant, [N]ormal, [O]tional
I 0001-Remove-orphaned-files-that-no-longer-exist-upstream.patch
* These look like they will cause problems if not removed :-/
O 0002-Move-all-binaries-back-to-sbin-Closes-786893.patch
* Given that /sbin is for administrator programs and /bin for user
  ones, /bin suggests these programs are for regular users.  Without
  this patch I believe you will start to receive bug reports like the
  following -> tldr users can create subvols but cannot remove
  them...or even list them.
  https://mail-archive.com/linux-btrfs@vger.kernel.org/msg67879.html
  https://mail-archive.com/linux-btrfs@vger.kernel.org/msg67912.html
I 0003-Add-copyright-for-tests-sha.h-tests-sha224-256.c-tes.patch
* It's a custom 3-clause Simplified BSD, and from what I've read
  about best practises it's best to chose something that doesn't
  mention BSD when it's a custom license.  Instead of 3-clause, I
  chose TLP-4, because that's the authoritative source document
  for 2011 IETF copyright.
 -> https://trustee.ietf.org/license-info/IETF-TLP-4.htm
N 0004-Drop-dh-autoreconf-from-build-depends-because-it-s-a.patch
N 0005-Fix-two-lintian-W-debian-changelog-line-too-long.patch

Other comments:

btrfs-progs-4.13 (Closes: #875384)
Please consider changing the maintainer address to your Ubuntu one, or
maybe just adding it.
Standards-version should be bumped.
  * 4.1.0 recommends autopkgtest is the biggest change.  Before
buster's soft freeze I hope to investigate how to run these as
root in a VM on Debian'sbuild infrastructure.
Lintian W uses-implicit-await-trigger for activate update-initramfs
  * I lack the experience to be able to responsibly suggest a fix for
this.

Cheers,
Nicholas
From 5d2cdec42bde64b94678eae51b57f795dfe918c1 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Sun, 17 Sep 2017 18:27:35 -0400
Subject: [PATCH 1/5] Remove orphaned files that no longer exist upstream

---
 config.h.in |  135 
 config/config.guess | 1431 
 config/config.sub   | 1813 ---
 config/install-sh   |  501 --
 4 files changed, 3880 deletions(-)
 delete mode 100644 config.h.in
 delete mode 100755 config/config.guess
 delete mode 100755 config/config.sub
 delete mode 100755 config/install-sh

diff --git a/config.h.in b/config.h.in
deleted file mode 100644
index 42167c0a..
--- a/config.h.in
+++ /dev/null
@@ -1,135 +0,0 @@
-/* config.h.in.  Generated from configure.ac by autoheader.  */
-
-/* Define if building universal (internal helper macro) */
-#undef AC_APPLE_UNIVERSAL_BUILD
-
-/* disable backtrace stuff in kerncompat.h */
-#undef BTRFS_DISABLE_BACKTRACE
-
-/* Define to 1 if you have the `backtrace' function. */
-#undef HAVE_BACKTRACE
-
-/* Define to 1 if you have the `backtrace_symbols_fd' function. */
-#undef HAVE_BACKTRACE_SYMBOLS_FD
-
-/* Define to 1 if you have the  header file. */
-#undef HAVE_EXECINFO_H
-
-/* Define to 1 if you have the  header file. */
-#undef HAVE_INTTYPES_H
-
-/* Define to 1 if you have the  header file. */
-#undef HAVE_MEMORY_H
-
-/* E2fsprogs does 

Bug#876093: openvas-libraries FTBFS on amd64: override_dh_auto_configure failed

[Gianfranco Costamagna]

>is due to Debian specific changes to the pcap-config tool.  This
>starting space in the output might also break other projects using
>libpcap and cmake.
>
>What do you think?  If you want I can take care of filing that bug.


yes please, I think this is worth a bug

G.

Bug#805451: Bugs/Reporting: please document for each pseudo-header in which addr...@bugs.debian.org it can be used

[Tim Landscheidt]

Kind of related: I find the "Mail servers' reference card"
at https://www.debian.org/Bugs/server-refcard not helpful at
all.  I expect a reference card to briefly describe each
command that is used in day-to-day operations; instead, the
Debian Bugs one just lists (all?) commands and their synop-
sis, but /not/ what they do, neither does the list of "bug
submission and followup addresses".

I find myself constantly cycling through three or four pages
on debian.org and browsing through source code to (in the
end) /guess/ what I need to do to achieve something.

Bug#876121: FTBFS: error: 'std::index_sequence' has not been declared

[Rene Engelhard]

Hi,

On Mon, Sep 18, 2017 at 07:12:42PM +0200, Bernd Zeimetz wrote:
> On 2017-09-18 18:30, Rene Engelhard wrote:
> >Source: open-vm-tools
> >From my buildlog(trying to build oath-toolkit with xmlsec 1.2.25
> 
> 
> uh, what has oath-toolkit to do with open-vm-tools?

Cut'n'waste.

> Also as far as I can see the bug is not in open-vm-tools:
> 
> 
> >/usr/include/glibmm-2.4/glibmm/variant.h: In member function
> >'std::tuple<_Tps ...> Glib::Variant >::get()
> >const':
> >/usr/include/glibmm-2.4/glibmm/variant.h:2095:45: error:
> >'index_sequence_for' is not a member of 'std'
> >   detail::assign_tuple(variants, data,
> >std::index_sequence_for{});
> > ^~
> >/usr/include/glibmm-2.4/glibmm/variant.h:2095:69: error: expected
> >primary-expression before '...' token
> >   detail::assign_tuple(variants, data,
> >std::index_sequence_for{});
> 
> 
> /usr/include/glibmm-2.4/glibmm/variant.h is clearly not shipped here.

Hmm, true. Just copied the error messages without even looking. But
open-vm-tools still FTBFSes, even if  the actual bug in was in gtkmm.

Feel free to reassign (or better clone) as appropriate.

Regards,

Rene

Bug#873717: Acknowledgement (collectd: FTBFS with libsigrok4)

[Jonathan McDowell]

Control: forwarded 873717 https://github.com/collectd/collectd/issues/1574
Control: tags 873717 + patch

I've produced a compile-tested patch and associated it with the upstream
bug report. As I lack any analog sigrok hardware I'm unable to test it
myself. However I'm going to upload the new sigrok packages over the
next few days which will lead to collectd being FTBFS in unstable.

J.

-- 
Web [  I just Fedexed my soul to hell. I'm *real* clever.  ]
site: http:// [  ]   Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24

Bug#876121: FTBFS: error: 'std::index_sequence' has not been declared

[Rene Engelhard]

On Mon, Sep 18, 2017 at 07:31:49PM +0200, Rene Engelhard wrote:
> Hi,
> 
> On Mon, Sep 18, 2017 at 07:12:42PM +0200, Bernd Zeimetz wrote:
> > On 2017-09-18 18:30, Rene Engelhard wrote:
> > >Source: open-vm-tools
> > >From my buildlog(trying to build oath-toolkit with xmlsec 1.2.25
> > 
> > 
> > uh, what has oath-toolkit to do with open-vm-tools?
> 
> Cut'n'waste.
> 
> > Also as far as I can see the bug is not in open-vm-tools:
> > 
> > 
> > >/usr/include/glibmm-2.4/glibmm/variant.h: In member function
> > >'std::tuple<_Tps ...> Glib::Variant >::get()
> > >const':
> > >/usr/include/glibmm-2.4/glibmm/variant.h:2095:45: error:
> > >'index_sequence_for' is not a member of 'std'
> > >   detail::assign_tuple(variants, data,
> > >std::index_sequence_for{});
> > > ^~
> > >/usr/include/glibmm-2.4/glibmm/variant.h:2095:69: error: expected
> > >primary-expression before '...' token
> > >   detail::assign_tuple(variants, data,
> > >std::index_sequence_for{});
> > 
> > 
> > /usr/include/glibmm-2.4/glibmm/variant.h is clearly not shipped here.
> 
> Hmm, true. Just copied the error messages without even looking. But
> open-vm-tools still FTBFSes, even if  the actual bug in was in gtkmm.
> 
> Feel free to reassign (or better clone) as appropriate.

Interestingly other stuff using glibmm *does* build...

Regards,
 
Rene

Bug#876087: xscreensaver: source-less and unlicensed code at hacks/images/m6502/dmsc.asm

[Jamie Zawinski]

Oh FFS, the pedantry of you people knows no bounds. It's not even a *real 
emulator*.

Did you even try emailing him?

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#854701: python-asyncssh: FTBFS randomly (failing tests)

[Vincent Bernat]

 ❦  7 mars 2017 14:04 +0100, Santiago Vila  :

> To double-check, I just build this package today 100 times and it
> failed 72 times.

Could you try again with 1.11.0-1 in unstable? I am unable to get any
failure, but wasn't able to get them in the first place.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#876093: openvas-libraries FTBFS on amd64: override_dh_auto_configure failed

[Lukas Schwaighofer]

Hi,

while I'm not against introducing the patch, in my opinion we should
file a bug against libpcap0.8-dev instead (or at least in addition).
The starting space in the output of
pcap-config --libs
is due to Debian specific changes to the pcap-config tool.  This
starting space in the output might also break other projects using
libpcap and cmake.

What do you think?  If you want I can take care of filing that bug.

Regards
Lukas

Bug#876121: FTBFS: error: 'std::index_sequence' has not been declared

[Bernd Zeimetz]

severity 876121 important
thanks

Hi,

On 2017-09-18 18:30, Rene Engelhard wrote:

Source: open-vm-tools
From my buildlog(trying to build oath-toolkit with xmlsec 1.2.25



uh, what has oath-toolkit to do with open-vm-tools?

Also as far as I can see the bug is not in open-vm-tools:



/usr/include/glibmm-2.4/glibmm/variant.h: In member function
'std::tuple<_Tps ...> Glib::Variant >::get()
const':
/usr/include/glibmm-2.4/glibmm/variant.h:2095:45: error:
'index_sequence_for' is not a member of 'std'
   detail::assign_tuple(variants, data, 
std::index_sequence_for{});

 ^~
/usr/include/glibmm-2.4/glibmm/variant.h:2095:69: error: expected
primary-expression before '...' token
   detail::assign_tuple(variants, data, 
std::index_sequence_for{});



/usr/include/glibmm-2.4/glibmm/variant.h is clearly not shipped here.


Thanks,

Bernd

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

Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

[Breno Leitao]

On Sat, 9 Sep 2017 20:20:03 -0300 Roberto Oliveira
> > In that case please override this warning and write a comment describing
> > the reason.
> Fixed.
> 
> > libopagent1 should be Section: libs.
> Fixed.

Thanks Roberto.

wRar, do you still any concern about this package?

Bug#863266: bug 863266 is forwarded to https://bugzilla.redhat.com/show_bug.cgi?id=1432684

[Guido Günther]

Hi,
On Mon, Sep 18, 2017 at 10:15:33AM +0200, Marc Haber wrote:
> On Fri, Sep 15, 2017 at 12:18:12PM +0200, Guido Günther wrote:
> > Let's reassign to the kernel then.
> > 
> > Dear kernel maintainers. The symptom is that libvirt fails to detect
> > ports already in use for spice. See
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1432684#c17
> > 
> > for a simple testcase not involving libvirt at all. I'll post the
> > summary (by Cole Robinson) here:
> 
> Patches on http://www.spinics.net/lists/netdev/msg454644.html and
> onwards, four pieces, all needed. I verified that they fix the issue on
> Debian stable with a vanilla 4.13.2 kernel.

Thanks for testing and following up on this. Hopefully we'll see this in
the Debian kernels soon.
Cheers,
 -- Guido

Bug#868689: Pending fixes for bugs in the libhttp-daemon-ssl-perl package

[pkg-perl-maintainers]

tag 868689 + pending
thanks

Some bugs in the libhttp-daemon-ssl-perl package are closed in
revision 1b2edac896b2f893479741b18b6b07a1f02c6f2d in branch 'master'
by Mike Gabriel

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libhttp-daemon-ssl-perl.git/commit/?id=1b2edac

Commit message:

debian/control: Move package under the umbrella of the Debian Perl Group 
with myself under Uploaders: field. (Closes: #868689).

Bug#870906: ITP: pynmea2 - pynmea2 is a python library for the NMEA 0183 protocol

[Joachim Langenbach]

Hi Herbert,

I managed to upload the version 1.9.0 and (hopefully) fixed your hints. May you 
have a look at it?

Regards,

Joachim 

P.s.: The mentors url is https://mentors.debian.net/package/pynmea2

Am Dienstag 05 September 2017, 17:14:22 schrieb Herbert Fortes:
> Hi Joachim Langenbach,
> 
> I was checking the Debian package you did. And
> I will try to help you.
> 
> First, there is a new version of pynmea2 - 1.9.0.
> The version on mentors is 1.8.0.
> 
> Debhelper should be 10, not 9.
> 
> Standards-Version is out-of-date
> 
> Why debian/pynmea2-doc.* files? They are not
> been used.
> 
> The package does not build two times in a row.
> Please clean *egg-info/SOURCES.txt
> 
> I liked not build Python 2 version. The file
> 'debian/rules' can have some '#' lines removed.
> 
> Please, put version '1.9.0' on mentors and let
> me known when you are ready.
> 
> 
> 
> Regards,
> Herbert


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