Bug#840193: liferea: Notification icon doesn't work for hide.

[Sven Hartge]

On Sun, 9 Oct 2016 20:51:01 +0200 Paul Gevers  wrote:
> On 09-10-16 15:42, Christian Marillat wrote:

>> The notification icon works for show but don't for hide.

> Could you try to explain better what you mean? I am not sure I
> understand. You mean the icon in the menu bar, or the notifications? I
> guess you mean that if you click on the icon, liferea doesn't hide, but
> when liferea is hidden, is does pop up liferea?

I see the same, hidden liferea pops up by clicking the icon, but hiding
liferea by clicking it again does not work.

I am running XFCE4 here.

Grüße,
Sven.

Bug#835148: gcc-6: please enable PIE hardening flags by default on amd64 ppc64el and s390x

[Niels Thykier]

On Tue, 23 Aug 2016 00:25:30 +0200 Balint Reczey
 wrote:
> Package: gcc-6
> Version: 6.1.1-12
> Severity: wishlist
> Tags: patch
> 
> Dear Matthias,
> 
> As a continuation of the discussions [1][2] on debian-devel I'm
> attaching the simple patch that implements enabling the PIE
> hardening flags for a subset of the architectures.
> 
> I'm open to changing the subset, it matches the set selected in Ubuntu
> as a start, but porters may have different preferences [2].
> 
> I'm continuing with a full archive rebuild to see the amount of packages
> to be updated for the change in the default flags.
> 
> The same patch applies to gcc-5, too, if it does not get removed
> from the archive before the patch is accepted for gcc-6.
> 
> Cheers,
> Balint
> 
> [1] https://lists.debian.org/debian-devel/2016/05/msg00228.html
> [2] https://lists.debian.org/debian-devel/2016/08/msg00324.html
> 

Hi,

As per [1], please enable PIE by default on the following architectures:


 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mips64el
 * mipsel
 * ppc64el
 * s390x

All of these architectures (except amd64+i386 with porter waivers) had
at least 2 porters supporting PIE.

Thanks,
~Niels

[1]
https://lists.debian.org/<2c67a60f-2bbb-2f4e-2ad3-cd9978fb5...@thykier.net>

Bug#258096: Po

[pkha...@mail.com]

 

Hi,

 

Please find attached order.
Kindly quote and send Invoice.
Thank You!
Best Regards.

PO.pdf
Description: Adobe PDF document
<>

Bug#840263: ITP: tendermint-go-clist -- goroutine-safe linked-list implementation

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: tendermint-go-clist
  Version : Git snapshot
  Upstream Author : Tendermint
* URL : https://github.com/tendermint/go-clist
* License : Apache-2.0
  Programming Lang: Golang
  Description : goroutine-safe linked-list implementation

 The purpose of CList is to provide a goroutine-safe linked-list.
 This list can be traversed concurrently by any number of goroutines.
 However, removed CElements cannot be added back.
 .
 This package is a dependency of the Tendermint core.

Bug#817493: hebcal: Removal of debhelper compat 4

[Paulo Henrique de Lima Santana]

Hi Shaya,

I had help from a DD to upload this NMU below with 10 days delay.

   * Non-maintainer upload.
   * Updated DH to level 10. (Closes: #817493)
   * debian/control:
   - Bumped Standards-Version to 3.9.8.
   - Added Homepage field.
   * debian/watch: created.

If you agree, we can cancel this upload and package again trying to 
solve these lintians below:


W: hebcal source: dh-clean-k-is-deprecated
I: hebcal source: missing-debian-source-format
P: hebcal source: direct-changes-in-diff-but-no-patch-system holidays.c
W: hebcal source: debian-rules-ignores-make-clean-error line 50
W: hebcal source: debian-rules-missing-recommended-target build-indep
W: hebcal source: debian-rules-missing-recommended-target build-arch
P: hebcal source: no-dep5-copyright
P: hebcal source: debian-watch-may-check-gpg-signature
I: hebcal: hardening-no-fortify-functions usr/bin/hebcal
I: hebcal: spelling-error-in-binary usr/bin/hebcal Ouput Output
I: hebcal: hardening-no-bindnow usr/bin/hebcal
I: hebcal: hardening-no-pie usr/bin/hebcal
P: hebcal: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
W: hebcal: copyright-without-copyright-notice
W: hebcal: description-synopsis-starts-with-article
I: hebcal: spelling-error-in-manpage usr/share/man/man1/hebcal.1.gz 
preceeds precedes


And update the software to version 4.4

Best regards,

On Sat, 8 Oct 2016 17:29:08 -0700 Shaya Potter  wrote:
> thank you, I have built some updates with newer versions, but haven't 
been

> in good contact with my former uploader to get them updated in Debian.
>
> On Sat, Oct 8, 2016 at 8:08 AM, Paulo Henrique de Lima Santana <
> p...@softwarelivre.org> wrote:
>
> > Hi,
> >
> > Today I did a NMU to solve this bug.
> >
> > Regards,
> >
> > --
> > Paulo Henrique de Lima Santana (phls)
> > Membro da Comunidade Curitiba Livre
> > Fone: +55 (41) 9198-1897
> > Site: http://www.phls.com.br
> > GNU/Linux user: 228719 GPG ID: 0443C450
> >

--
Paulo Henrique de Lima Santana (phls)
Membro da Comunidade Curitiba Livre
Fone: +55 (41) 9198-1897
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Bug#840262: please support bootstrapping without python

[Helmut Grohne]

Source: audit
Version: 1:2.6.7-1
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

audit is part of the essential build closure, because it is needed by
libsemanage, which is needed by shadow, which builds login, which is
essential. Building Python before audit seems impossible, so it seems
that we need a way to build audit without Python support. The attached
patch does just that by introducing a  build profile. It does
not distinguish between different Python versions and simply deactivates
all of them when given. Can you apply the patch?

Helmut
diff --minimal -Nru audit-2.6.7/debian/changelog audit-2.6.7/debian/changelog
--- audit-2.6.7/debian/changelog2016-09-27 22:44:56.0 +0200
+++ audit-2.6.7/debian/changelog2016-10-10 06:57:04.0 +0200
@@ -1,3 +1,10 @@
+audit (1:2.6.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for the nopython build profile (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 10 Oct 2016 06:56:51 +0200
+
 audit (1:2.6.7-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru audit-2.6.7/debian/control audit-2.6.7/debian/control
--- audit-2.6.7/debian/control  2016-09-27 22:44:56.0 +0200
+++ audit-2.6.7/debian/control  2016-10-10 06:56:22.0 +0200
@@ -4,7 +4,7 @@
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
dh-systemd (>= 1.4),
-   dh-python,
+   dh-python ,
 #   dh-golang,
dpkg-dev (>= 1.16.1~),
intltool,
@@ -15,8 +15,8 @@
libldap2-dev,
libprelude-dev,
libwrap0-dev,
-   python-all-dev (>= 2.6.6-3~),
-   python3-all-dev,
+   python-all-dev (>= 2.6.6-3~) ,
+   python3-all-dev ,
swig
 Build-Depends-Indep: golang-go
 Standards-Version: 3.9.8
@@ -109,6 +109,7 @@
 Architecture: linux-any
 Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
 Provides: ${python:Provides}
+Build-Profiles: 
 Description: Python bindings for security auditing
  The package contains the Python bindings for libaudit and libauparse, which
  are used to monitor systems for security related events. Python can be used to
@@ -119,6 +120,7 @@
 Architecture: linux-any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Provides: ${python3:Provides}
+Build-Profiles: 
 Description: Python3 bindings for security auditing
  The package contains the Python3 bindings for libaudit and libauparse, which
  are used to monitor systems for security related events. Python can be used to
diff --minimal -Nru audit-2.6.7/debian/rules audit-2.6.7/debian/rules
--- audit-2.6.7/debian/rules2016-09-27 22:44:56.0 +0200
+++ audit-2.6.7/debian/rules2016-10-10 06:56:22.0 +0200
@@ -1,14 +1,15 @@
 #!/usr/bin/make -f
-include /usr/share/python/python.mk
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
-
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+include /usr/share/dpkg/architecture.mk
 
 LDFLAGS += -Wl,--as-needed
+DH_ADDONS = --with autoreconf --with systemd
+CONFIGURE_FLAGS =
 
+ifeq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
+include /usr/share/python/python.mk
 # For building bindings/swig/ and bindings/python/ for all Python version, 
these directories are cloned and build in addition to the main library
 PYDEFAULTVER := $(shell pyversions --default --version)

 PYVERS := $(shell pyversions --requested --version debian/control) 

@@ -16,6 +17,11 @@
 PY3DEFAULTVER := $(shell py3versions --default --version)
 PY3VERS := $(shell py3versions --requested --version debian/control)
 PY3VERS := $(filter-out $(PY3DEFAULTVER), $(PY3VERS))
+CONFIGURE_FLAGS += --with-python --with-python3
+DH_ADDONS += --with python2 --with python3
+else
+CONFIGURE_FLAGS += --without-python --without-python3
+endif
 
 ifeq ($(DEB_HOST_ARCH),alpha)
   EXTRA_ARCH_TABLE := --with-alpha
@@ -25,7 +31,7 @@
 endif
 
 %:
-   dh $@ --builddirectory=debian/build --buildsystem=autoconf --with 
autoreconf --with python2 --with python3 --with systemd #--with golang
+   dh $@ --builddirectory=debian/build --buildsystem=autoconf $(DH_ADDONS)
 
 override_dh_auto_configure: debian/config-python-stamp 
$(PYVERS:%=debian/config-python%-stamp) 
$(PY3VERS:%=debian/config-python3-%-stamp)
 debian/config-python-stamp:
@@ -41,8 +47,7 @@
--with-prelude \
--with-libwrap \
--with-libcap-ng \
-   --with-python \
-   --with-python3 \
+   $(CONFIGURE_FLAGS) \
--with-arm 

Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]

[Dmitry Bogatov]

[2016-10-04 18:22] gustavo panizzo 
>
> I'm looking for an sponsor of my package uptimed,
> I want to adopt this package after it was orphaned by the previous
> maintainer #830765
>
> I want to upload to experimental to check if it builds reproducibly in all 
> Debian architectures.
> Be aware that I'll request another upload latter for unstable.
> [...]
> this is the changelog

Could you please add option to run it in foreground? Runit init
system, which I package exect services to be foreground processes.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.

Bug#840261: RFS: runit/2.1.2-9

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: runit
  Version : 2.1.2-9
  Upstream Author : Gerrit Pape 
* Url : http://smarden.org/runit/
* Licenses: BSD-3-clause
  Section : admin

It builds those binary packages:

  * runit
  * runit-systemd
  * runit-sysv
  * getty-run
  * runit-init

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

http://mentors.debian.net/package/runit

Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-9.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://anonscm.debian.org/cgit/users/kaction-guest/runit.git

More information about runit can be obtained from
http://smarden.org/runit/

Changes since last upload:

  * Make runit-init depends getty-run, otherwise user can end up with
system with no means to login.
  * Add sysvinit-compatible scripts (reboot, shutdown), which are expected
by graphical interface to perform these actions.
  * Add sysvinit-compatible script runlevel. While it does not perform
anything useful, invoke-rc.d expects it's presence.
  * Remove unused source linitian overrides, since package builds with compat 9

Regards,
  Dmitry Bogatov

Bug#840260: glibc: please support the tilegx architecture

[Helmut Grohne]

Source: glibc
Version: 2.24-3
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Aurelien,

Can you add support for the tilegx architecture to glibc? dpkg knows
about the architecture since 1.18.8 and gcc-6 has some preliminary
support already. The patch is quite small. Beyond adding it to
libc6_archs, care needs to be taken to use arch-specific linux headers
from /usr/include//arch. After applying the patch,
debian/control must be regeneratd (not included in the patch). Can you
maintain the diff?

Helmut
diff --minimal -Nru glibc-2.24/debian/changelog glibc-2.24/debian/changelog
--- glibc-2.24/debian/changelog 2016-09-17 20:00:44.0 +0200
+++ glibc-2.24/debian/changelog 2016-10-10 06:36:11.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.24-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support tilegx. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 10 Oct 2016 06:36:01 +0200
+
 glibc (2.24-3) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff --minimal -Nru glibc-2.24/debian/rules.d/control.mk 
glibc-2.24/debian/rules.d/control.mk
--- glibc-2.24/debian/rules.d/control.mk2016-09-04 01:26:39.0 
+0200
+++ glibc-2.24/debian/rules.d/control.mk2016-10-10 06:35:57.0 
+0200
@@ -1,7 +1,7 @@
 libc_packages := libc6 libc6.1 libc0.1 libc0.3
 libc0_1_archs := kfreebsd-amd64 kfreebsd-i386
 libc0_3_archs := hurd-i386
-libc6_archs   := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 
mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 
s390x sh4 x32
+libc6_archs   := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 
mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 
s390x sh4 tilegx x32
 libc6_1_archs := alpha
 
 control_deps := $(wildcard debian/control.in/*) $(addprefix 
debian/control.in/, $(libc_packages))
diff --minimal -Nru glibc-2.24/debian/sysdeps/linux.mk 
glibc-2.24/debian/sysdeps/linux.mk
--- glibc-2.24/debian/sysdeps/linux.mk  2016-09-04 01:26:39.0 +0200
+++ glibc-2.24/debian/sysdeps/linux.mk  2016-10-10 06:35:21.0 +0200
@@ -39,6 +39,11 @@
else \
ln -s $(LINUX_HEADERS)/asm debian/include ; \
fi
+   if [ -d "$(LINUX_ARCH_HEADERS)/arch" ]; then \
+   ln -s $(LINUX_ARCH_HEADERS)/arch debian/include ; \
+   else \
+   ln -s $(LINUX_HEADERS)/arch debian/include ; \
+   fi
ln -s $(LINUX_HEADERS)/asm-generic debian/include
ln -s $(LINUX_HEADERS)/linux debian/include
 

Bug#840257: ITP: mali-driver -- Mali GPU binary drivers, URL

[Lima]

>   URL : 
> http://malideveloper.arm.com/develop-for-mali/features/mali-t6xx-gpu-use
> r-space-drivers/

For your convience
URL : 
http://malideveloper.arm.com/develop-for-mali/features/mali-t6xx-gpu-user-space-drivers/

 From Lima with love

Bug#802658: libesmtp: Should support TLS 1.1+

[Salvatore Bonaccorso]

Hi Jememy,

Since almost now a year I try to get that patch forwarded and I have
it locally running without problems. I do not get a reply from
upstream author.

Are you in contact with upstream/have an alternative contact address?

The freeze for Debian stretch is approaching in meanwhile really fast.

Regards,
Salvatore

Bug#840259: lprng-doc: Please change build dependency from jade to openjade

[Neil Roeth]

Package: lprng-doc
Severity: normal

The package lprng-doc build depends on the binary package jade.  Jade is
obsolete and will be removed from Debian; its replacement is openjade.
Please replace the build dependency on jade with openjade.  No other
changes are needed because the configure scripts look for openjade as
well as jade and use whichever is available.

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

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

-- 
Neil Roeth

Bug#840258: mark gnupg2 Multi-Arch: foreign

[Helmut Grohne]

Source: gnupg2
Version: 2.1.15-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gpa src:gpgme1.0 src:libzypp src:pygpgme

gnupg2 was turned into a transitional package pointing to gnupg. The
original gnupg2 and the present gnupg package are marked Multi-Arch:
foreign, but gnupg2 is not. Thus packages that Build-Depends on the
transitional name (listed above) currently have unsatisfiable cross
Build-Depends. Can you add the relevant control stanzas? Patch attached.


Helmut
diff --minimal -Nru gnupg2-2.1.15/debian/changelog 
gnupg2-2.1.15/debian/changelog
--- gnupg2-2.1.15/debian/changelog  2016-09-14 23:08:58.0 +0200
+++ gnupg2-2.1.15/debian/changelog  2016-10-10 06:09:35.0 +0200
@@ -1,3 +1,11 @@
+gnupg2 (2.1.15-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark gnupg-l10n, gnupg2, gpgv-win32 and gpgv2 Multi-Arch: foreign
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 10 Oct 2016 06:07:54 +0200
+
 gnupg2 (2.1.15-3) unstable; urgency=medium
 
   * Use upstream fix to avoid touching homedir during test suite
diff --minimal -Nru gnupg2-2.1.15/debian/control gnupg2-2.1.15/debian/control
--- gnupg2-2.1.15/debian/control2016-09-14 23:08:58.0 +0200
+++ gnupg2-2.1.15/debian/control2016-10-10 06:07:52.0 +0200
@@ -149,6 +149,7 @@
 Architecture: all
 Section: oldlibs
 Priority: extra
+Multi-Arch: foreign
 Depends:
  gnupg (>= ${source:Version}),
  ${misc:Depends},
@@ -190,6 +191,7 @@
 Section: oldlibs
 Priority: extra
 Architecture: all
+Multi-Arch: foreign
 Depends:
  gpgv (>= ${source:Version}),
  ${misc:Depends},
@@ -253,6 +255,7 @@
 Package: gpgv-win32
 Architecture: all
 Priority: extra
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
 Suggests:
@@ -271,6 +274,7 @@
 Package: gnupg-l10n
 Architecture: all
 Priority: extra
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
 Enhances:

Bug#822658: gnome-todo: Segmentation fault

[Jason Crain]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=772672
Control: tags -1 + patch

On Tue, Apr 26, 2016 at 03:40:48PM +0700, Trần Ngọc Quân wrote:
> On 26/04/2016 15:23, Emilio Pozuelo Monfort wrote:
> > Please install libglib2.0-0-dbg and libgtk-3-0-dbg. Also install
> > gnome-todo-dbgsym from
> > http://debug.mirrors.debian.org/debian-debug/pool/main/g/gnome-todo/gnome-todo-dbgsym_3.20.0-1_amd64.deb
> I'm using 32-bit system. I install gnome-todo-dbgsym_3.20.0-1_i386.deb
> > Then get a new backtrace.
> See the attachment.

I managed to reproduce this in a i386 chroot, and the backtrace looks
pretty much like yours.  It probably looks like that because it's in the
middle of a bunch of varargs functions.

The problem is that in a g_object_new call, the "xalign" property is
being passed an int when it should be a float/double.  x86-64 gets away
with it, I think due to alignment, but i386 gets the types and
parameters mismatched and crashes from trying to treat a TRUE as a
string.

Attached patch fixes it.  Forwarded upstream.
>From 095ddfb6cae4fdc36f70e237c3d4a6917688cf30 Mon Sep 17 00:00:00 2001
From: Jason Crain 
Date: Sun, 9 Oct 2016 19:42:02 -0500
Subject: [PATCH] panel-scheduled: pass xalign as float

Pass the "xalign" property to g_object_new as a float instead of an int
so it matches the property definition.  Passing it as an int crashes
i386 machines.

https://bugzilla.gnome.org/show_bug.cgi?id=772672
---
 plugins/eds/gtd-panel-scheduled.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/eds/gtd-panel-scheduled.c b/plugins/eds/gtd-panel-scheduled.c
index ffbc7cb..ddde78f 100644
--- a/plugins/eds/gtd-panel-scheduled.c
+++ b/plugins/eds/gtd-panel-scheduled.c
@@ -127,7 +127,7 @@ create_label (const gchar *text,
 "margin-left", 12,
 "margin-bottom", 6,
 "margin-top", first_header ? 6 : 18,
-"xalign", 0,
+"xalign", 0.0,
 "hexpand", TRUE,
 NULL);
 
-- 
2.9.3

Bug#837164: ipmitool lan print does not report ipv6 addresses

[Jörg Frings-Fürst]

Hello,

I have upload the version 1.8.18-1 to unstable. 

Please can you test this version?

Many Thanks

CU
Jörg
 

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#840257: ITP: mali-driver -- Mali GPU binary drivers

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

  Package name: mali-driver
  Version : 0.1
  Upstream Author : ARM Limited
  URL : 
http://malideveloper.arm.com/develop-for-mali/features/mali-t6xx-gpu-use
r-space-drivers/
  License : ARM Proprietary
  Programming Lang: Binaries
  Description : Mali GPU binary drivers

This binary driver provides support for ARM mali graphics hardware.
It includes a dkms kernel interface module that allows a driver to
work with multiple kernel versions, and variants for fbdev, x11 and
wayland usage on Mali-4xx, -Txxx and -Gxx hardware are included.

Opengl (eg1, gles1&2), and opencl are supported.

A recent change in the Mali proprietary licence has made these drivers
redistributable, without a clickthrough, specifically so that
distributions can make them available.

Linaro is providing time for getting the packaging done.

Bug#840256: scons-doc: Please remove build dependency on jade

[Neil Roeth]

Package: scons-doc
Severity: normal

The package scons-doc build depends on the binary package jade.  Jade is
obsolete and will be removed from Debian, so please remove the build
dependency.  It appears that scons-doc doesn't actually use jade
directly, so that build dependency does not need to be replaced with
anything.

Thanks.

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

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

-- 
Neil Roeth

Bug#791944: My workaround

[Theppitak Karoonboonyanan]

Hi,

I've suffered from this problem for almost a year, I guess.
Thanks to the clue I got from this bug report, I've come up with
a quick hack for my own machine: by telling sendsigs to omit
systemd-udevd when killing processes:

--- /etc/init.d/udev.orig2016-10-10 09:40:47.937302585 +0700
+++ /etc/init.d/udev2016-10-10 09:42:59.701304680 +0700
@@ -203,6 +203,14 @@
 else
 log_action_end_msg 0 'timeout'
 fi
+
+# Omit systemd-udevd on halt to allow cryptsetup to do the close
+UDEVD_PID=$(pidof $DAEMON)
+if [ ! -z "$UDEVD_PID" ]; then
+OMITDIR=/run/sendsigs.omit.d
+mkdir -p $OMITDIR
+echo $UDEVD_PID > $OMITDIR/udev
+fi
 ;;

 stop)

With this patch to /etc/init.d/udev, my machine (using sysvinit)
shuts down successfully again.

Is the fix reasonable for udev?

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
--- /etc/init.d/udev.orig   2016-10-10 09:40:47.937302585 +0700
+++ /etc/init.d/udev2016-10-10 09:42:59.701304680 +0700
@@ -203,6 +203,14 @@
 else
log_action_end_msg 0 'timeout'
 fi
+
+# Omit systemd-udevd on halt to allow cryptsetup to do the close
+UDEVD_PID=$(pidof $DAEMON)
+if [ ! -z "$UDEVD_PID" ]; then
+OMITDIR=/run/sendsigs.omit.d
+mkdir -p $OMITDIR
+echo $UDEVD_PID > $OMITDIR/udev
+fi
 ;;
 
 stop)

Bug#840255: tiny-initramfs: please use iucode-tool to generate early-initramfs for Intel

[Henrique de Moraes Holschuh]

Package: tiny-initramfs
Version: 0.1-1
Severity: minor

Plase use iucode_tool to generate the early initramfs for Intel
microcode.  Not only this can create a smaller initramfs when coupled
with iucode_tool's "--scan-system" functionality, it also tweaks the
cpio header of the early-initramfs segment containing the intel
microcode update data to ensure the start of the microcode data payload
will be 16-byte aligned.

This is not just a wishlist bug because it actually avoids an
architectural rule violation during early Intel microcode updates (yes,
the kernel code is broken.  no, current Core-based Intel processors
don't appear to care... but very old 32-bit-only processors might, and
future processors *are* allowed to care).

You can concatenate early-initramfs segments together and it just works,
so you could prepend the one created by iucode-tool to the one created
by mktirfs for AMD microcode (and ACPI table overrides / DT overrides,
if it supports those).

-- 
  Henrique Holschuh

Bug#840254: thunar: freeze when mounting USB drive

[Ben Caradoc-Davies]

Downgrading libthunarx-2-0, thunar, thunar-data, and thunar-dbg to 
1.6.10-2 restores the ability to mount and unmount USB devices.


Kind regards,

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

Bug#840254: thunar: freeze when mounting USB drive

[Ben Caradoc-Davies]

Package: thunar
Version: 1.6.10-3
Severity: normal

Dear Maintainer,

thunar displays an unmounted ext4 USB thumb drive. Clicking on it causes the
progress icon to be displayed but thunar then freezes and must be killed via
window manager or command line. The device is successfully mounted. Running
thunar in gdb provides no information.

I will now try downgrading to 1.6.10-2, which did not show this failure.

Kind regards,
Ben.



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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-3
ii  libcairo2   1.14.6-1+b1
ii  libdbus-1-3 1.10.10-1
ii  libdbus-glib-1-20.108-1
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.0-2
ii  libgtk2.0-0 2.24.31-1
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-1+b1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.40.3-2
ii  libsm6  2:1.2.2-1+b1
ii  libthunarx-2-0  1.6.10-3
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2
ii  libxfconf-0-2   4.12.0-3
ii  shared-mime-info1.7-1
ii  thunar-data 1.6.10-3

Versions of packages thunar recommends:
ii  dbus-x11 1.10.10-1
ii  gvfs 1.30.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpangoft2-1.0-01.40.3-2
ii  thunar-volman0.8.1-2
ii  tumbler  0.1.31-2+b3
ii  xdg-user-dirs0.15-2
ii  xfce4-panel  4.12.0-4

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#835377: moreinfo

[Martín Ferrari]

tags 835377 + moreinfo
thanks

Hi,

What you are describing sounds related to
https://github.com/golang/go/issues/6654 and
https://github.com/golang/build/commit/bd6b12a04d05260cd28f207ee1d9663a77cf4c24

But I am not sure what is failing for you. If I run go doc without
GOROOT or GOPATH set, it finds correctly the standard library packages:


$ go doc os.open
func Open(name string) (*File, error)
Open opens the named file for reading. If successful, methods on the
returned file can be used for reading; the associated file
descriptor has
mode O_RDONLY. If there is an error, it will be of type *PathError.


And if I set GOPATH, I can see docs for any arbitrary installed go package:


$ GOPATH=/usr/share/gocode go doc
github.com/prometheus/client_golang/prometheus
package prometheus // import
"github.com/prometheus/client_golang/prometheus"

Package prometheus provides metrics primitives to instrument code for
monitoring. It also offers a registry for metrics. Sub-packages allow to
[...]

-- 
Martín Ferrari (Tincho)

Bug#840253: ITP: openqa: automated test tool to test the whole installation process of an OS

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: openqa
  Version : 4.3
  Upstream Author : SUSE Linux GmbH
* URL : http://open.qa/
https://github.com/os-autoinst/openQA
* License : GPL-2+
  Programming Lang: Perl /
  Description : automated test tool to test the whole installation process 
of an OS

  openQA is a testing framework that allows you to test GUI applications 
 on one hand and bootloader and kernel on the other. In both cases, it is
 difficult to script tests and verify the output. Output can be a popup 
 window or it can be an error in early boot even before init is executed.

 Therefore openQA runs virtual machines and closely monitors their state
 and runs tests on them.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#840249: want dput --no-lintian option

[Ben Finney]

On Mon, 2016-10-10 01:26 +0100, Ian Jackson
 wrote:

> tl/dr: Please provide
>  1. Command line option --no-lintian to override run_lintian in config
>  2. Convenient way to discover whether run_lintian is set in dput config

Would an acceptable option:

* Provide an alternate ‘dput’ configuration at run time

satisfy? A tool that needs to use ‘dput’ non-interactively could specify
the configuration to use, and thereby avoid whatever customisations the
general configuration file has.

-- 
 \
  `\
_o__) Ben Finney 

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Hideki Yamane]

Hi,

 More SUSE btrfs setup information is 
 
https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_snapper_setup.html


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#840252: nvidia-driver: Right shift key inserts enter after installing nvidia-driver

[jsb]

Package: nvidia-driver
Version: 367.44-2
Severity: important

Dear Maintainer,
After installing the proprietary nvidia-driver the right shift key on my
Lenovo P50 will insert an enter after printing whatever character is
being capitalized. This does not seem to be an issue when using the
nouveau driver. The bug is present starting when I am entering my
password to log into Debian. I have tried apt-get remove --purge
nvidia*, which seems to remedy the bug.

-- Package-specific info:
uname -a:
Linux jsb 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux

/proc/version:
Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.7.5-1 (2016-09-26)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  367.44  Wed Aug 17 22:24:07 PDT 
2016
GCC version:  gcc version 5.4.1 20160803 (Debian 5.4.1-1) 

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107GLM [Quadro 
M2000M] [10de:13b0] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Lenovo GM107GLM [Quadro M2000M] [17aa:2230]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.00] Console: colour VGA+ 80x25
[1.273982] vgaarb: setting as boot device: PCI::01:00.0
[1.273984] vgaarb: device added: 
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[1.273984] vgaarb: loaded
[1.273985] vgaarb: bridge control possible :01:00.0
[1.915114] Linux agpgart interface v0.103
[   18.102372] nvidia: module license 'NVIDIA' taints kernel.
[   18.106830] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[   18.134556] vgaarb: device changed decodes: 
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[   18.134624] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 246
[   18.134638] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  367.44  Wed Aug 
17 22:24:07 PDT 2016
[   18.139027] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  367.44  Wed Aug 17 21:54:40 PDT 2016
[   18.167596] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver
[   18.185332] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[   18.670644] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13
[   18.670686] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input14
[   18.670739] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input15
[   25.427530] nvidia-modeset: Allocated GPU:0 
(GPU-4001dcf5-bb1e-f3ba-87b5-ba3d6184264e) @ PCI::01:00.0

Device node permissions:
crw-rw+ 1 root video 226,   0 Oct  9 20:24 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Oct  9 20:24 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 Oct  9 20:25 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 Oct  9 20:25 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Oct  9 20:25 /dev/nvidiactl
video:x:44:jsbadmin

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1299 Oct  9 20:22 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Oct  9 20:19 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Oct  9 20:19 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Oct  9 20:19 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Oct  9 20:19 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   50 Oct  9 20:19 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Oct  9 20:19 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   47 Oct  9 20:19 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Oct  9 20:19 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   51 Oct  9 20:19 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Oct  9 20:19 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Oct  9 20:19 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 

Bug#839461: Pending fixes for bugs in the golang-github-mattn-go-sqlite3 package

[pkg-go-maintainers]

tag 839461 + pending
thanks

Some bugs in the golang-github-mattn-go-sqlite3 package are closed in
revision 2b49250251e22dff74b7aaa5f138b28819743b9a in branch 'master'
by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-mattn-go-sqlite3.git/commit/?id=2b49250

Commit message:

debian/control: Add tzdata as dependency. Closes: #839461

Bug#840251: fast-export to git produces unimportable dump

[Osamu Aoki]

Package: fossil
Version: 1:1.35-1.1
Severity: normal

The #693570 should have been fixed in upstream but there seems to exist
another bug.

How to reproduce this bug.
 $ fossil clone https://www.fossil-scm.org/ fossil.fsl
  ...
 $ ls -l fossil.fsl
-rw-r--r-- 1 * * 37855232 Oct 10 08:50 fossil.fsl
 $ git init fossil
 $ cd fossil
 $ fossil export --git ../fossil.fsl | git fast-import
fatal: Unsupported command: def.txt
fast-import: dumping crash report to .git/fast_import_crash_11901
 $ cd ..
 $ fossil export --git fossil.fsl >fossil.export
 $ vim fossil.export

(Slow to start but I see following by searching "/def\.txt" at 99% point)

commit refs/heads/test_ticket_d17d6e5b17
mark :37455
committer jan.nijtmans  1353531216 +
data 82
Just commit some weird filenames, even one with a newline in it, to test the 
code.
from :37577
M 100644 :1050 :abc
M 100644 :37588 abc
def.txt
M 100644 :1050 str"i"ng.h
M 100644 :1050 str[ing.txt
M 100644 :1050 xyz<5.x

Looks like fossil bug. :-)  So I couldn't export to git repo with the
newer fossil.

By removing def.txt line with vim, this seems to be worked around and
nicely imported.  I tried as follows:
$ rm -rf fossil
$ git init fossil
$ cd fossil
$ git fast-import <../fossil.export
error: Multiple updates for ref 'refs/tags/json_add_tag_test' not allowed.
git-fast-import statistics:
-
Alloc'd objects:  55000
Total objects:50520 (  2996 duplicates  )
  blobs  :19491 ( 0 duplicates  15079 deltas of  
18632 attempts)
  trees  :21041 (  2996 duplicates  18791 deltas of  
19186 attempts)
  commits: 9915 ( 0 duplicates  0 deltas of 
 0 attempts)
  tags   :   73 ( 0 duplicates  0 deltas of 
 0 attempts)
Total branches: 556 (   982 loads )
  marks:1048576 ( 29406 unique)
  atoms:935
Memory total:  4813 KiB
   pools:  2235 KiB
 objects:  2578 KiB
-
pack_report: getpagesize()=   4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit  = 8589934592
pack_report: pack_used_ctr=   6619
pack_report: pack_mmap_calls  =   1726
pack_report: pack_open_windows=  1 /  1
pack_report: pack_mapped  =  115842226 /  115842226
-
$ git checkout trunk

 (voila! I have imported tree)

So manually editing export produces a good enough data to be imported
to git with branch name preserved.  The main one is "trunk".

But it's not perfect one for refs/tags/json_add_tag_test

So at least one minor bug needs to be addressed.

What is the best way to report this to upstream?

Osamu

=
Side story: I could import from fossil repo to a debian packaging repo
made by:
 $ gbp import-dscs --debsnap --pristine-tar fossil
 $ cd fossil
 $ git fast-import <../fossil.export
With --import-mark and --export-mark, we may be able to make synced
upstream trunk and debian package repo.

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

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

Versions of packages fossil depends on:
ii  libc6   2.23-5
ii  libfuse22.9.7-1
ii  libsqlite3-03.14.2-1
ii  libssl1.0.2 1.0.2h-1
ii  libtcl8.6 [libtcl]  8.6.6+dfsg-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

fossil recommends no packages.

Versions of packages fossil suggests:
ii  gnupg   1.4.20-6
ii  gnupg2  2.1.11-7

-- no debconf information

Bug#840250: ftp-master API: Want way to query for (one or more) .origs

[Ian Jackson]

Package: ftp.debian.org
Control: block 829116 by -1

dgit would like to automatically compute, accurately, whether to
include .orig tarball(s) in uploads.  (Currently this is done by
delegating to the heuristic in dpkg-genchanges, based on the Debian
revision.)

To do this dgit would like to be able to specify a filename (or
perhaps several) and find out whether the file is present, and if so
what its hash is.

I think the dsc_in_suite query is not right because the .orig may have
already been uploaded, but simply in another suite (and dgit ought not
to search all suites).

At the point where dgit is making this decision dgit knows the
complete .orig filename, the full package version number (including
any epoch), and the intended destination suite.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service

[Ferenc Wágner]

"S. Banerian"  writes:

> On 10/07/2016 02:04 PM, Ferenc Wágner wrote:
> 
>>> Manually trying to start /usr/sbin/shibd -f -F never produces the
>>> /run/shibboleth/shibd.sock nor any other files in that dir.
>> 
>> This is really disturbing.  You don't except the above command to give
>> back your prompt, right?  
>
> correct.
>
>> Could you please make sure shibd isn't running
>> then show me the output of
>> 
>> # sudo -u _shibd strace shibd -f -F
>
> the output is rather long...
> I shall attach.

Thanks.  Does it hang there indefinitely, with no further output for
minutes?  Does shibd still consume significant CPU according to top?
What are its memory figures?  Isn't your computer swapping heavily?  Can
you provide a full GDB backtrace (after installing
shibboleth-sp2-utils-dbgsym; please yell if you need precise
instructions).

> Note: prior to the upgrade, shibboleth was working.

Which version of shibboleth was working for you?
Can you share your shibboleth2.xml?

> We did note that sometimes shibd was more well-behaved when starting
> from shell than via systemctl.

Could you please make this more precise?  How did it misbehave when
started by systemctl?
-- 
Thanks,
Feri

Bug#840249: want dput --no-lintian option

[Ian Jackson]

Package: dput
Version: 0.9.6.4
Control: block 827879 by -1

tl/dr: Please provide
 1. Command line option --no-lintian to override run_lintian in config
 2. Convenient way to discover whether run_lintian is set in dput config

Explanation:

dgit uses dput to do actual uploads.  (This is useful because it means
dgit does not need to replicate dput's configuration about upload
queues, and also because it can sometimes mean that a partially-failed
push/upload can be finished off.)

dput can be configured to run lintian on every upload.  lintian
sometimes exits nonzero due to problems with the package.

In the context of dgit this is not very helpful, because dput is run
after the relevant git tags have been signed and pushed to the dgit
git server.  So the upload might fail halfway through: see #827879.

dgit would like to disable this part of dput's functionality.
However, dput does not honour a --no-lintian option to override the
config file.

Furthermore, if this option is specified, then I think it would be
best if dgit actually honoured it, but at the right stage of the push.
dgit could run dput --check-only, or could run lintian itself.  But
this should be done only if dput is configured with run_lintian,
because the rest of dput's checks just duplicate things dgit does
anyway.

So dgit would like to know whether dput is configured to run lintian.

Failing the above, how horrible would it be for dgit to put a stunt
no-op lintian on PATH, when running dput ?

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#840248: debian-installer: Add btrfs subvolume setting for snapshot

[Hideki Yamane]

package: debian-installer
severity: wishlist

 It's enhancement proposal, not bug report. Now Debian system cannot use
 whole btrfs power, but we can improve it.

 debian-installer can format disk with btrfs now, but it is NOT appropriate
 setting with btrfs. We can just format partion with btrfs but cannot create
 btrfs "subvolume" at that time.

 Subvolume is a bit special idea, you can slice one btrfs partion to some 
 subvolume and can set quota for each subvolume, also mount directory and
 get snapshot for each.

 So, I'll propose debian-installer to add btrfs subvolume setting menu or
 add subvolume setting like SUSE by default.

 For detail, see Btrfs Wiki page
 https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-subvolume


 Well, for exapmle, openSUSE's installer (YaST2?) creates defalut partition
 as btrfs and below subvolumes by default.
--
@/boot/grub2/i386-pc
@/boot/grub2/x86_64-efi
@/home
@/opt
@/tmp
@/usr/local
@/var/crash
@/var/lib/libvirt/images (option "no copy on write")
@/var/lib/mailman
@/var/lib/mariadb (option "no copy on write")
@/var/lib/mysql (option "no copy on write")
@/var/lib/named
@/var/lib/pgsql (option "no copy on write")
@/var/log
@/var/opt
@/var/spool
@/var/tmp

 and default / subvolume.
--

 - Snapshotting is targeted to default / subvolume and whole system except
   above subvolumes. Separating some directories are very important for btrfs
   snapshot. It makes easy to rollback to previous snapshot image without any
   losing data.
  
 - And, "no copy on write" mount option is important for DB systems 
   for performance.

 - I'm not sure why they separate /boot/grub2/i386-pc and x86_64-efi

 If it is hard to add creating subvolume menu, just follow SUSE's decision
 is worse.


 Some people says "btrfs is not stable", but SUSE and Oracle support it as
 commercial support. Some features like RAID5,6 is not stable as it says(*),
 but upstream developer Chris Mason says "Aging" state in Facebook(*). So
 it's worse to treat btrfs as sane choice and release its power as possible,
 IMO.
 

 *) https://btrfs.wiki.kernel.org/index.php/Status
 *) https://youtu.be/W3QRWUfBua8?t=17m51s


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#711702: s/deprecated/no longer working/

[Adam Borowski]

Since findutils 4.5.12-1 this usage doesn't work at all anymore.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#801435: dgit: avoiding/fixing "Source-only uploads to NEW are not allowed"

[Ian Jackson]

Control: retitle -1 Want to spot "entirely NEW source-only upload to Debian"

As I wrote in my initial response:

> By definition a source-only upload doesn't involve dgit seeing the
> binary packages.  I'm not even sure that it is possible to determine
> which binary packages ought to be produced without doing the actual
> build.  So this would be tricky.  (But how does the dak tell: does it
> process debian/control?)

But:

> [It] would be possible for dgit to see that the package is entirely
> new (which I think it is in your case) and to know to reject a
> source-only upload in that case.

I think this is the only really actionable work item in this bug
report. Retitling it accordingly.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#840245: RM: boost1.58 -- ROM; Superceeded and no longer builds with GCC 6

[Mattia Rizzolo]

control: tag -1 moreinfo

On Sun, Oct 09, 2016 at 05:00:06PM -0500, Steve M. Robbins wrote:
> Thanks,

well, not that easily, there are quite big list of rdeps that needs
taking care of.

Thanks for the bug though, now I've get something where I can put
"blocks" (will do tomorrow, I've already have a list somewhere) :)

dak rm -Rn boost-1.58:

Checking reverse dependencies...
# Broken Depends:
ball: ballview [amd64 mips64el mipsel]
  libball1.4 [amd64 mips64el mipsel]
  libballview1.4 [amd64 mips64el mipsel]
  python-ball [amd64 mips64el mipsel]
  python-ballview [amd64 mips64el mipsel]
bitcoin: bitcoin-qt [armel]
 bitcoin-tx [armel]
 bitcoind [armel]
choreonoid: choreonoid-plugins-base [armel armhf hurd-i386]
libcnoid1 [armel armhf hurd-i386]
cpp-netlib: libcppnetlib0 [amd64 arm64 hurd-i386 kfreebsd-amd64 kfreebsd-i386 
mips64el s390x]
cupt: cupt [hurd-i386]
dspdfviewer: dspdfviewer [kfreebsd-amd64 kfreebsd-i386]
gpsshogi: gpsshogi [amd64 i386]
hhvm: hhvm [amd64]
icinga2: icinga2-bin [armhf]
 icinga2-ido-mysql [armhf]
 icinga2-ido-pgsql [armhf]
 icinga2-studio [armhf]
 libicinga2 [armhf]
kcollectd: kcollectd
libavg: python-libavg [amd64 arm64 armel armhf i386 mips mips64el mipsel 
powerpc ppc64el s390x]
libbitcoin: libbitcoin-dev [arm64 armel armhf kfreebsd-amd64 mips mipsel 
powerpc ppc64el s390x]
libosl: libosl1v5 [amd64 i386]
libphonenumber: libgeocoding7 [kfreebsd-amd64 kfreebsd-i386]
libphonenumber7 [kfreebsd-amd64 kfreebsd-i386]
lightspark: lightspark-common [powerpc]
limereg: limereg [kfreebsd-amd64 kfreebsd-i386 mipsel]
litecoin: litecoin-qt [amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 mips64el mipsel ppc64el]
  litecoind [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 
mips64el mipsel ppc64el]
mapnik: libmapnik3.0 [kfreebsd-amd64]
mapnik-utils [kfreebsd-amd64]
molds: molds [kfreebsd-amd64 kfreebsd-i386]
mongodb: mongodb-clients [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
 mongodb-server [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
mupen64plus-video-glide64mk2: mupen64plus-video-glide64mk2 [kfreebsd-amd64 
kfreebsd-i386]
opensurgsim: libopensurgsim [arm64 armel armhf powerpc]
pdns: pdns-server [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
  pdns-tools [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
pdns-recursor: pdns-recursor [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
pion: libpion-5.0
  libpion-dev
  libpion-plugins
pulseview: pulseview [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
ppc64el s390x]
pyviennacl: python-pyviennacl
python3-pyviennacl
qpid-cpp: libqpidcommon2 [armel armhf mips s390x]
  qpidd [armel armhf mips s390x]
rdkit: librdkit1 [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
   python-rdkit [amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
sfcgal: libsfcgal1 [hurd-i386]
tome/non-free: tome [amd64]
undertaker: undertaker [kfreebsd-amd64 kfreebsd-i386]
utopia-documents: utopia-documents [amd64 arm64 i386 mips mips64el mipsel 
powerpc ppc64el s390x]
uwsgi: uwsgi-mongodb-plugins [amd64 armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386]
vowpal-wabbit: libvw0
   vowpal-wabbit
witty: libwt38 [armel]
   libwtdbo38 [armel]
   libwtdbopostgres38 [armel]
   libwtdbosqlite38 [armel]
   libwtext38 [armel]
   libwtfcgi38 [armel]
   libwthttp38 [armel]
   libwttest8 [armel]
   witty-examples [armel]
woo: python-woo [kfreebsd-i386]
 python3-woo [kfreebsd-i386]
yade: libyade [kfreebsd-i386]
  python-yade [kfreebsd-i386]

Dependency problem found.


-- 
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#840247: libtowitoko2 is brocken after kernelupdate.

[fuchur]

Package: libtowitoko2 
Version: 2.0.7-9

After this changes in the Kernel:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79eb238c76782a59d51adf8a3dd7f6444245b475

the Towitoko Chipdrive Reader on device /dev/ttySX can't use any more.
You can test it with pcscd and geldkard from libchipcard-tools.
libtowitoko2 crash or show "No readers available"
if the kernel ist > 3.16. 

Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility

[Axel Beckert]

Hi Jeroen,

Jeroen Massar wrote:
> >> Then finally Call Your ISP for Native IPv6.
> > 
> > I already did. The answer so far was "We don't need that yet." :-(
> > They seem to think that owning enough IPv4 address suffices and maybe
> > also that there's no customer demand (yet).
> 
> As your ISP apparently is UPC Cablecom,

I should have been more verbose, sorry.

Yes, at home in Zurich I have UPC (no more "Cablecom") and I'm very
well aware that UPC offers DS-Lite and tries to move more and more
users to it without even asking. They also tried that with my
connection, but it was said to have failed. (See below for some more
details.)

But in Zurich, I have choice, and our house recently got FTTH. Hence I
want to move away from UPC anyways (e.g. because they're blocking some
outgoing ports), but I haven't decided yet to which ISP offering
proper _static_ IPv6 on fiber I'll switch. Probably Fiber7 by Init7
which also already provides the SixXS PoP I'm using now, so I have an
idea of how their IPv6 connectivity is about. But iWay is also
thinking about offering static IPv6 on Fiber, so that would be another
choice.

It's though totally different at my parents' home in the countryside
in Germany.

As of now they don't even have DSL -- too far away from the telephone
switch box. We're already glad that they got UMTS instead of just GPRS
like two years ago -- but with the usual penalty that there are no
real mobile flat rates in Germany. (They are still allowed to call
mobile data connections "flat rate" even if they're throttled after
some given amount of traffic. It's different rules with landlines.
Crazy laws, that.)

But they'll get FTTH in spring, too -- unfortunately not with Open
Access like in Zurich (I've asked the mayor of their municipality as
well as the owner of the fiber about that), so they have no real
choice with the ISP for a while. The only one offering FTTH
connectivity there is Unitymedia (as carrier as well as ISP). And
despite Unitymedia also belongs to Liberty Global, they said to me
during a public question and answer table organised by the local
government that they don't offer IPv6 and don't plan to do so in the
near future either. :-(

> which is part of the European Cable Monopoly that is Liberty Global
> you should be aware that they are providing DS-Lite to all their new
> customers,

According to Unitymedia it's different there as with UPC in
Switzerland and not all local Liberty Global owned ISPs are the same.
I explicitly asked, too, if they offer DS-Lite like UPC in Switzerland
does and they denied.

So I'd actually be happy if you know more than those local
representatives of Unitymedia (and hence of Liberty Global) and that
they're actually offering IPv6 connectivity. Because in that case I
indeed would no more need any tunneled IPv6 connectivity in the near
future. (And in that case my interest in keeping aiccu properly
maintained in Debian would indeed also decline.) I though can't tell
from my own experience before spring.

> and have been silently switching every cheap account to it to all
> around Europe.

They tried that at my home in Zurich, too, but it seems to have failed
for reasons unknown to me, so they switched me back. At least that's
what I was told in an UPC shop when I fetched a new modem because the
old one broke.

> That their helpdesk does not know what they actually provide, just
> shows that you asked the wrong people.

I really hope that you're right with that point, despite you expected
me to refer to UPC in Switzerland and not to Unitymedia in Germany
there. :-)

> > Another issue is choice: At some locations, especially those with
> > fiber, you don't have a choice wrt. to ISPs, otherwise changing the
> > ISP towards one with native IPv6 connectivity is also an option.
> 
> Sounds you have a monopoly problem.

Correct. At my parents home, that's the case. Hoping for the German
government (or RegTP or however that office is called now) to
recognize Unitymedia as monopolist and requiring them to provide Open
Access to their fiber. At least that's what they mentioned that they
expect to happen somewhen in the future anyways. But they won't give
access to their fiber to other companies unless the government
requires them to do so. (The mayor of my parents' municipality though
expects that this happens rather sooner than later. I actually have no
idea how often such things happen in Germany.)

> > And in general: Just one person asking doesn't make them provide IPv6
> > instantly. It needs enough people to nag them to realise the demand.
> 
> How often did you really call?

"Call" as in using the telephone you mean? Never. *g* But kidding
aside. I asked twice so far:

First I asked in the chat on their website when I first heard that my
parents might get FTTH from them. But the sales rep at other end of
the line didn't even know what I was talking about and asked someone
else first -- not sure if that was just another sales guy. So the
answer there was 

Bug#840246: RFP: krita -- Krita is a professional FREE and open source painting program.

[Gregor Riepl]

Package: wnpp
Severity: wishlist

* Package name: krita
  Version : 3.0
  Upstream Author : Boudewijn Rempt  and others
* URL : https://krita.org
* License : GPL2+, LGPL2+
  Programming Lang: C++
  Description : Krita is a professional FREE and open source painting
program.

Krita was recently moved to its own project and is no longer part of the
Calligra suite.
As such, I think it warrants having its own package and not depend on (parts
of) Calligra. The package situation in stretch and sid (krita-gemini being a
transitional package, calligra-gemini being broken) is kind of contrary to this
fact. Stable still carries the package krita as part of Calligra.

Krita is a very good painting program, even being used by professional and
semi-professional artists on various platforms. Having the current stable
version (3.0) in Debian would be a very valuable addition.

Bug#840245: RM: boost1.58 -- ROM; Superceeded and no longer builds with GCC 6

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal


Thanks,
-Steve

Bug#840244: audacious: Skip instead of seek

[Cristian Rigamonti]

Package: audacious
Version: 3.7.2-1~bpo8+1
Severity: important

Using the left/right cursor keys, or the mouse on the progress bar, makes 
audacity skip to the next
song, instead of seeking in the current song. This happens both with the gtk 
and the winamp interface.


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

Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages audacious depends on:
ii  audacious-plugins3.7.2-2~bpo8+1
ii  dbus 1.6.2-2
ii  dbus-x11 1.6.2-2
ii  gtk2-engines-pixbuf  2.24.31-1
ii  libaudcore3  3.7.2-1~bpo8+1
ii  libc62.19-9
ii  libgcc1  1:4.9.2-10
ii  libglib2.0-0 2.50.0-1
ii  libstdc++6   4.9.2-10

Versions of packages audacious recommends:
ii  unzip  6.0-8

audacious suggests no packages.

-- no debconf information

Bug#840243: calligra-gemini does not launch due to missing QtQuick components

[Gregor Riepl]

Package: calligra-gemini
Version: 1:2.9.11+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

calligra-gemini will not launch due to the following error:

"The Calligra Qt Quick components were not found. This means your installation
is broken."

On the console, the following error message is printed:

file:///usr/share/kde4/apps/calligragemini/calligragemini.qml:22:1: module
"org.calligra.CalligraComponents" is not installed
 import org.calligra.CalligraComponents 0.1 as Calligra

It does not matter if calligra-gemini is installed separately or as part of the
whole calligra suite.

Please make sure these componentes are part of calligra-libs or whichever
package they belong.

Thank you!



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

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

Versions of packages calligra-gemini depends on:
ii  calligra-gemini-data  1:2.9.11+dfsg-2
ii  calligra-libs 1:2.9.11+dfsg-2
ii  calligrastage 1:2.9.11+dfsg-2
ii  calligrawords 1:2.9.11+dfsg-2
ii  kde-runtime   4:16.08.0-1
ii  libc6 2.24-3
ii  libkdecore5   4:4.14.23-1
ii  libkdeui5 4:4.14.23-1
ii  libqt4-declarative4:4.8.7+dfsg-9
ii  libqt4-network4:4.8.7+dfsg-9
ii  libqt4-opengl 4:4.8.7+dfsg-9
ii  libqt4-svg4:4.8.7+dfsg-9
ii  libqtcore44:4.8.7+dfsg-9
ii  libqtgui4 4:4.8.7+dfsg-9
ii  libstdc++66.1.1-11

calligra-gemini recommends no packages.

calligra-gemini suggests no packages.

-- no debconf information

Bug#838553: Update 1.17-3.2+deb7u1 breaks libtommath integration (-DLTM_DESC needed)

[Jonas Meurer]

Hi Milan, hi Michael,

Am 09.10.2016 um 20:55 schrieb Michael Stapelberg:
> [+cc mejo, who did the upload in question]

Thanks for Cc'ing me.

> Looking into
> http://security.debian.org/debian-security/pool/updates/main/libt/libtomcrypt/libtomcrypt_1.17-3.2+deb7u1.diff.gz,
> I see debian/rules contains this line:
> 
> +CFLAGS += -DGMP_DESC -DLTM_DESC -DUSE_LTM
> 
> So the flag seems to be set accordingly.
> 
> Not quite sure what’s wrong here.

Indeed, the LTM_DESC flag is set at compile time. The 1.17-3.2+deb7u1
upload should not have changed anything here.

Milan, do you have an example code snippet to reproduce the bug?

Cheers,
 jonas

> On Thu, Sep 22, 2016 at 10:52 AM, Milan Budala  > wrote:
> 
> Package: libtomcrypt-dev
> Version: 1.17-3.2+deb7u1
> Severity: important
> 
> Security update 1.17-3.2+deb7u1 breaks libtommath integration
> ('undefined reference to ltm_desc' linking error).
> No problems with version 1.17-3.2. The build should probably define
> LTM_DESC.
> 
> -- System Information:
> Debian Release: 7.11
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.18.17-core2-rt14 (SMP w/1 CPU core; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages libtomcrypt-dev depends on:
> ii  libtomcrypt0  1.17-3.2+deb7u1
> 
> libtomcrypt-dev recommends no packages.
> 
> libtomcrypt-dev suggests no packages.
> 
> -- no debconf information
> 
> 
> 
> 
> -- 
> Best regards,
> Michael




signature.asc
Description: OpenPGP digital signature

Bug#840242: mpv fails to load libmp3lame.so.0

[Nicolas Braud-Santoni]

Package: mpv
Version: 0.20.0-1+b1
Severity: important

Dear Maintainer,

This is the error that occured while trying to run mpv:

> % mpv 'https://elevate-live.spreadspace.org/av-orig-webm-medium.webm'
> mpv: error while loading shared libraries: libmp3lame.so.0: ELF load command 
> address/offset not properly aligned
> 
> % mpv ~/Downloads/big_buck_bunny_1080p_stereo.ogg
> mpv: error while loading shared libraries: libmp3lame.so.0: ELF load command 
> address/offset not properly aligned

The error might belong to libmp3lame,
but I'm not entirely sure how to check this.


Best,

  nicoo


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

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

Versions of packages mpv depends on:
ii  libasound2  1.1.2-1
ii  libass5 0.13.4-1
ii  libavcodec577:3.1.3-1+b3
ii  libavdevice57   7:3.1.3-1+b3
ii  libavfilter67:3.1.3-1+b3
ii  libavformat57   7:3.1.3-1+b3
ii  libavutil55 7:3.1.3-1+b3
ii  libbluray1  1:0.9.3-2
ii  libc6   2.24-3
ii  libcdio-cdda1   0.83-4.2+b1
ii  libcdio-paranoia1   0.83-4.2+b1
ii  libcdio13   0.83-4.2+b1
ii  libdrm2 2.4.70-1
ii  libdvdnav4  5.0.3-1
ii  libdvdread4 5.0.3-1
ii  libegl1-mesa [libegl1-x11]  12.0.3-1
ii  libenca01.19-1
ii  libgl1-mesa-glx [libgl1]12.0.3-1
ii  libguess1   1.2-1.1
ii  libjack-jackd2-0 [libjack-0.116]1.9.10+20150825git1ed50c92~dfsg-2
ii  libjpeg62-turbo 1:1.5.0-1
ii  liblcms2-2  2.7-1
ii  liblua5.2-0 5.2.4-1.1
ii  libpulse0   9.0-3
ii  librubberband2  1.8.1-6+b1
ii  libsdl2-2.0-0   2.0.4+dfsg2-1
ii  libsmbclient2:4.4.5+dfsg-3
ii  libsndio6.1 1.1.0-2
ii  libswresample2  7:3.1.3-1+b3
ii  libswscale4 7:3.1.3-1+b3
ii  libva-wayland1  1.7.2-1
ii  libva-x11-1 1.7.2-1
ii  libva1  1.7.2-1
ii  libvdpau1   1.1.1-4
ii  libwayland-client0  1.11.0-2
ii  libwayland-cursor0  1.11.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  12.0.3-1
ii  libx11-62:1.6.3-1
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.6.1-1
ii  libxrandr2  2:1.5.0-1
ii  libxss1 1:1.2.2-1
ii  libxv1  2:1.0.10-1+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mpv recommends:
ii  xdg-utils   1.1.1-1
ii  youtube-dl  2016.06.25-2

mpv suggests no packages.

-- no debconf information

Bug#726174: apt: APT::Get::Upgrade-Allow-New installs new packages when depending package isn't upgraded

[Timo Haas]

Hi

I've got the same problem. Situation after apt autoremove:

apt upgrade
Reading package lists... Done
Building dependency tree  
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
  kactivities-bin kactivitymanagerd kio-extras kio-extras-data
kpackagelauncherqml kpackagetool5 ktexteditor-data ktexteditor-katepart
libboost-program-options1.61.0 libboost-regex1.61.0
  libboost-serialization1.61.0 libclang1-3.8 libdbusmenu-qt5-2
libgrantlee-templates5 libkasten3controllers3 libkasten3core3
libkasten3gui3 libkasten3okteta1controllers1 libkasten3okteta1core1
  libkasten3okteta1gui1 libkf5activities5 libkf5attica5
libkf5bookmarks-data libkf5bookmarks5 libkf5declarative-data
libkf5declarative5 libkf5dnssd-data libkf5dnssd5 libkf5globalaccel-bin
  libkf5globalaccel-data libkf5globalaccel5 libkf5globalaccelprivate5
libkf5gpgmepp5 libkf5itemmodels5 libkf5js5 libkf5kcmutils-data
libkf5kcmutils5 libkf5kdelibs4support-data libkf5kdelibs4support5
  libkf5kdelibs4support5-bin libkf5khtml-bin libkf5khtml-data
libkf5khtml5 libkf5kiofilewidgets5 libkf5newstuff-data libkf5newstuff5
libkf5notifications-data libkf5notifications5 libkf5notifyconfig-data
  libkf5notifyconfig5 libkf5package-data libkf5package5 libkf5parts-data
libkf5parts-plugins libkf5parts5 libkf5pty-data libkf5pty5
libkf5quickaddons5 libkf5solid5 libkf5solid5-data libkf5sonnet5-data
  libkf5sonnetcore5 libkf5sonnetui5 libkf5sysguard-data
libkf5texteditor5 libkf5textwidgets-data libkf5textwidgets5
libkf5threadweaver5 libkf5wallet-bin libkf5wallet-data libkf5wallet5
libkf5xmlgui-bin
  libkf5xmlgui-data libkf5xmlgui5 libkomparediff2-5 libkwalletbackend5-5
libobjc-6-dev libokteta2core2 libokteta2gui2 libphonon4qt5-4
libprocesscore7 libprocessui7 libqca-qt5-2 libqca-qt5-2-plugins libssh-4
  phonon4qt5 phonon4qt5-backend-vlc sonnet-plugins
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  kactivities-bin kactivitymanagerd kio-extras kio-extras-data
kpackagelauncherqml kpackagetool5 ktexteditor-data ktexteditor-katepart
libclang1-3.8 libdbusmenu-qt5-2 libkasten3controllers3 libkasten3core3
  libkasten3gui3 libkasten3okteta1controllers1 libkasten3okteta1core1
libkasten3okteta1gui1 libkf5activities5 libkf5attica5
libkf5bookmarks-data libkf5bookmarks5 libkf5declarative-data
libkf5declarative5
  libkf5dnssd-data libkf5dnssd5 libkf5globalaccel-bin
libkf5globalaccel-data libkf5globalaccel5 libkf5globalaccelprivate5
libkf5gpgmepp5 libkf5js5 libkf5kcmutils-data libkf5kcmutils5
libkf5kdelibs4support-data
  libkf5kdelibs4support5 libkf5kdelibs4support5-bin libkf5khtml-bin
libkf5khtml-data libkf5khtml5 libkf5kiofilewidgets5 libkf5newstuff-data
libkf5newstuff5 libkf5notifications-data libkf5notifications5
  libkf5package-data libkf5package5 libkf5parts-data libkf5parts-plugins
libkf5parts5 libkf5pty-data libkf5pty5 libkf5quickaddons5 libkf5solid5
libkf5solid5-data libkf5sonnet5-data libkf5sonnetcore5
  libkf5sonnetui5 libkf5sysguard-data libkf5texteditor5
libkf5textwidgets-data libkf5textwidgets5 libkf5threadweaver5
libkf5wallet-bin libkf5wallet-data libkf5wallet5 libkf5xmlgui-bin
libkf5xmlgui-data
  libkf5xmlgui5 libkwalletbackend5-5 libobjc-6-dev libokteta2core2
libokteta2gui2 libphonon4qt5-4 libprocesscore7 libprocessui7
libqca-qt5-2 libqca-qt5-2-plugins libssh-4 phonon4qt5 phonon4qt5-backend-vlc
  sonnet-plugins
The following packages have been kept back:
  kdevelop libboost-date-time-dev libboost-filesystem-dev
libboost-program-options-dev libboost-regex-dev libboost-system-dev
0 upgraded, 80 newly installed, 0 to remove and 6 not upgraded.
Need to get 20.9 MB of archives.
After this operation, 104 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Bug#836415: nodejs: SIGILL when running nodejs

[Jérémy Lal]

2016-10-06 12:28 GMT+02:00 Jérémy Lal :

>
>
> 2016-09-04 16:41 GMT+02:00 Sam Imberman :
>
>>
>>
>> This is using nodejs 4.4.7 from sid:
>>
>> (gdb) run
>> Starting program: /usr/bin/nodejs
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/powerpc-linux-gnu/libthr
>> ead_db.so.1".
>> [New Thread 0xb7fba450 (LWP 6224)]
>> [New Thread 0xb77ba450 (LWP 6225)]
>> [New Thread 0xb6fba450 (LWP 6226)]
>> [New Thread 0xb67ba450 (LWP 6227)]
>>
>> Thread 1 "nodejs" received signal SIGILL, Illegal instruction.
>> 0x41418f28 in ?? ()
>> (gdb) x/i $pc
>> => 0x41418f28:  fcfid   f1,f1
>> (gdb) x/x $pc
>> 0x41418f28: 0xfc200e9c
>>
>>
> Thanks,
>
> If powerpc G4 cpu is officially supported by debian powerpc architecture
> and
> if you can reproduce this with nodejs 4.x (from debian/sid), then nodejs
> package
> should also be removed from powerpc arch.
>

Upstream issues:
https://github.com/ibmruntimes/v8ppc/issues/100 and
https://github.com/ibmruntimes/node/issues/65.

Jérémy

Bug#836415: Bug#838440: [Pkg-javascript-devel] Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries

[Jérémy Lal]

2016-10-09 23:02 GMT+02:00 Sebastiaan Couwenberg :

> On 10/09/2016 10:25 PM, Jérémy Lal wrote:
> > Now the same is going to happen with "powerpc" arch: libv8 is actually
> not
> > compatible with all processors supported by debian (ppc64xx are ok,
> though).
> >
> > Sebastiaan, i feel bad asking for your help again, but since you already
> > filled all the RM bugs once, i suppose you're in the best position to do
> it again
> > for powerpc.
>
> Sure, the list of immediately affected packages is limited.
>
> Is there a bugreport or other reference for the powerpc issue I can
> include for more information in the RM bugs?
>
> Currently nodejs still built successfully on powerpc, so filing the RM
> bugs is a bit premature.
>
> The affected packages were retrieved from UDD as follows:
>
>  udd=>SELECT DISTINCT source
>  udd->  FROM packages
>  udd-> WHERE distribution = 'debian'
>  udd->   AND release  = 'sid'
>  udd->   AND architecture = 'powerpc'
>  udd->   AND source  != 'nodejs'
>  udd->   AND (dependsLIKE '%nodejs%' OR
>  udd(>recommends LIKE '%nodejs%')
>  udd->  ORDER BY source
>  udd-> ;
> source
>  -
>   almond
>   codelite
>   node-bones
>   node-expat
>   node-groove
>   node-iconv
>   node-leveldown
>   node-mapnik
>   node-sqlite3
>   node-srs
>   node-stringprep
>   node-topcube
>   node-websocket
>   node-ws
>   node-xmlhttprequest
>   node-zmq
>  (16 rows)
>
>
The bug would be https://bugs.debian.org/836415

Jérémy.

Bug#771441: I don't believe that NetworkManager is at fault here

[Mike Crowe]

On Thursday 06 October 2016 at 13:01:07 +1030, Ron wrote:
> > The current tftpd-hpa package defaults to being available on all interfaces
> > via an IPv4 address. In Message #25, Ron rightly questioned whether this is
> > still a sensible default. But, as I said in Message #30, I don't believe
> > that changing the default to TFTP_ADDRESS=":69" makes the situation any
> > worse, and it does mean that tftpd does work correctly when no network
> > interface is available at startup. Maybe if the default was changed then it
> > could be turned into a debconf question?
> 
> What if it already was a debconf question ;?

Oh, it is. :)

I'd never noticed since it is low priority so I'd never been asked it. :(

The full text of the question is:

--8<--
  Please specify an address and port to listen to in the form of
  [address][:port].

  By default, the TFTP server listens to port 69 on all addresses and all
  interfaces (0.0.0.0:69). If no port is specified, it defaults to 69.

  Please note that numeric IPv6 addresses must be enclosed in square
  brackets to avoid ambiguity with the optional port information.

  TFTP server address and port:
-->8--

I think that a reasonable reading of that would leave me with the
expectation that the default would work with IPv6, which it does not. But,
that's a different bug which I should probably raise separately.

> What the default should be is mostly a balancing act between what is
> sane for a relatively naive user who doesn't know what they should
> answer there, and what would be right out of the box for most people
> without 'special needs'.  Whether it should be changed now, also adds
> the question of line of least surprise for existing users, so there
> is some inertia and risk there which we shouldn't ignore if changing
> it now is not the clearly compelling thing to do.

If the default were changed to :69 then the observable change to users who
accept that default would be that IPv6 would start working when previously
it hadn't. I suspect that Debian is full of services that started working
on IPv6 upon package upgrade (mostly in the now distant past.)

> I'm inclined to think that running this on a laptop is a special case.
> And that changing it "because otherwise NM breaks" would be hiding a
> bug in NM rather than fixing it at the real cause.

I can't help wondering whether there might be more users now installing
tftpd-hpa on their desktop or laptop in order to backup their router
configuration or boot some embedded device, than on a server to boot a room
full of diskless workstations. Maybe I'm guilty of being skewed by my own
experience.

> But I'm not ruling out that there might be other compelling reasons
> to still change the default for this at some point.  Whether that
> should be to :69, or to something else, is still an open question.

You won't be surprised to hear that I think that :69 makes a more sensible
default. I believe that this is only slightly influenced by that default
also ensuring that tftpd-hpa starts even when the network interface isn't
yet up.

Thanks.

Mike.

Bug#748374: Shipment delivery problem #0000465804

[FedEx International Next Flight]

Dear Customer,

This is to confirm that one or more of your parcels has been shipped.
Shipment Label is attached to email.

Thanks and best regards,
Chris Daniels,
FedEx Operation Manager.



Malware Alert Text.txt
Description: Malware Alert Text.txt

Bug#838440: [Pkg-javascript-devel] Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries

[Sebastiaan Couwenberg]

On 10/09/2016 10:25 PM, Jérémy Lal wrote:
> Now the same is going to happen with "powerpc" arch: libv8 is actually not
> compatible with all processors supported by debian (ppc64xx are ok, though).
> 
> Sebastiaan, i feel bad asking for your help again, but since you already
> filled all the RM bugs once, i suppose you're in the best position to do it 
> again
> for powerpc.

Sure, the list of immediately affected packages is limited.

Is there a bugreport or other reference for the powerpc issue I can
include for more information in the RM bugs?

Currently nodejs still built successfully on powerpc, so filing the RM
bugs is a bit premature.

The affected packages were retrieved from UDD as follows:

 udd=>SELECT DISTINCT source
 udd->  FROM packages
 udd-> WHERE distribution = 'debian'
 udd->   AND release  = 'sid'
 udd->   AND architecture = 'powerpc'
 udd->   AND source  != 'nodejs'
 udd->   AND (dependsLIKE '%nodejs%' OR
 udd(>recommends LIKE '%nodejs%')
 udd->  ORDER BY source
 udd-> ;
source
 -
  almond
  codelite
  node-bones
  node-expat
  node-groove
  node-iconv
  node-leveldown
  node-mapnik
  node-sqlite3
  node-srs
  node-stringprep
  node-topcube
  node-websocket
  node-ws
  node-xmlhttprequest
  node-zmq
 (16 rows)

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#839331: libvisual-plugins: FTBFS: ./conftest.c:63: undefined reference to `floor'

[Eriberto Mota]

Hi Lucas,

Not a tzdata issue. Recently libvisual-plugins gotten this FTBFS
because a configure.ac test to find gstreamer-0.8 fails. It didn't
fail in last upload but fails now.

I will disable the gstreamer support to fix this issue.

Thanks a lot.

Regards,

Eriberto


2016-10-01 5:40 GMT-03:00 Lucas Nussbaum :
> Source: libvisual-plugins
> Version: 1:0.4.0+dfsg1-8
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160930 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> g++: fatal error: no input files
>> compilation terminated.
>> configure:4539: $? = 1
>> configure:4543: checking whether we are using the GNU C++ compiler
>> configure:4562: g++ -c -g -O2 
>> -fdebug-prefix-map=/<>/libvisual-plugins-0.4.0+dfsg1=. -fPIE 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE conftest.cpp >&5
>> configure:4562: $? = 0
>> configure:4571: result: yes
>> configure:4580: checking whether g++ accepts -g
>> configure:4600: g++ -c -g -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
>> conftest.cpp >&5
>> configure:4600: $? = 0
>> configure:4641: result: yes
>> configure:4666: checking dependency style of g++
>> configure:4777: result: none
>> configure:4794: checking for an ANSI C-conforming const
>> configure:4860: gcc -c -g -O2 
>> -fdebug-prefix-map=/<>/libvisual-plugins-0.4.0+dfsg1=. -fPIE 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE conftest.c >&5
>> configure:4860: $? = 0
>> configure:4867: result: yes
>> configure:4875: checking for inline
>> configure:4891: gcc -c -g -O2 
>> -fdebug-prefix-map=/<>/libvisual-plugins-0.4.0+dfsg1=. -fPIE 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE conftest.c >&5
>> configure:4891: $? = 0
>> configure:4899: result: inline
>> configure:4918: checking whether time.h and sys/time.h may both be included
>> configure:4938: gcc -c -g -O2 
>> -fdebug-prefix-map=/<>/libvisual-plugins-0.4.0+dfsg1=. -fPIE 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE conftest.c >&5
>> configure:4938: $? = 0
>> configure:4945: result: yes
>> configure:4958: checking how to run the C preprocessor
>> configure:4989: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
>> conftest.c
>> configure:4989: $? = 0
>> configure:5003: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
>> conftest.c
>> conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
>>  #include 
>> ^
>> compilation terminated.
>> configure:5003: $? = 1
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME "Libvisual plugins"
>> | #define PACKAGE_TARNAME "libvisual-plugins"
>> | #define PACKAGE_VERSION "0.4.0"
>> | #define PACKAGE_STRING "Libvisual plugins 0.4.0"
>> | #define PACKAGE_BUGREPORT "d...@nerds-incorporated.org"
>> | #define PACKAGE_URL ""
>> | #define PACKAGE "libvisual-plugins"
>> | #define VERSION "0.4.0"
>> | #define TIME_WITH_SYS_TIME 1
>> | /* end confdefs.h.  */
>> | #include 
>> configure:5028: result: gcc -E
>> configure:5048: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
>> conftest.c
>> configure:5048: $? = 0
>> configure:5062: gcc -E -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE 
>> conftest.c
>> conftest.c:12:28: fatal error: ac_nonexistent.h: No such file or directory
>>  #include 
>> ^
>> compilation terminated.
>> configure:5062: $? = 1
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME "Libvisual plugins"
>> | #define PACKAGE_TARNAME "libvisual-plugins"
>> | #define PACKAGE_VERSION "0.4.0"
>> | #define PACKAGE_STRING "Libvisual plugins 0.4.0"
>> | #define PACKAGE_BUGREPORT "d...@nerds-incorporated.org"
>> | #define PACKAGE_URL ""
>> | #define PACKAGE "libvisual-plugins"
>> | #define VERSION "0.4.0"
>> | #define TIME_WITH_SYS_TIME 1
>> | /* end confdefs.h.  */
>> | #include 
>> configure:5091: checking for grep that handles long lines and -e
>> configure:5149: result: /bin/grep
>> configure:5154: checking for egrep
>> configure:5216: result: /bin/grep -E
>> configure:5221: checking for ANSI C header files
>> configure:5241: gcc -c -g -O2 
>> -fdebug-prefix-map=/<>/libvisual-plugins-0.4.0+dfsg1=. -fPIE 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE conftest.c >&5
>> configure:5241: $? = 0
>> configure:5314: gcc -o conftest -g -O2 
>> -fdebug-prefix-map=/<>/libvisual-plugins-0.4.0+dfsg1=. -fPIE 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -fPIE -pie -Wl,-z,relro -Wl,-z,now 
>> conftest.c  >&5
>> configure:5314: 

Bug#840200: texlive-lang-arabic: tries to overwrite file from texlive-xetex

[Hilmar Preuße]

On 09.10.2016 16:38, Holger Levsen wrote:

Hi,

> from 
> https://jenkins.debian.net/job/chroot-installation_stretch_install_full_desktop_upgrade_to_sid_aptdpkg_first/262//console
> 
> Preparing to unpack .../132-texlive-lang-arabic_2016.20161008-1_all.deb ...
> Unpacking texlive-lang-arabic (2016.20161008-1) over (2016.20160819-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-OUzNcU/132-texlive-lang-arabic_2016.20161008-1_all.deb 
> (--unpack):
>  trying to overwrite '/usr/share/doc/texlive-doc/xelatex/xepersian/README', 
> which is also in package texlive-xetex 2016.20160819-2
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> [...]
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-OUzNcU/132-texlive-lang-arabic_2016.20161008-1_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
Problem has been reported already and fixed in git. I added the bug
number to changelog now.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility

[Jeroen Massar]

On 2016-10-09 22:37, Axel Beckert wrote:
> Hi Jeroen,
> 
> Jeroen Massar wrote:
>> On 2016-10-09 18:56, Axel Beckert wrote:
>>> I'm yet another DD who's interested in having that package maintained
>>> properly in Debian (and who NMUed it once in the past for that
>>> reason). But I don't want to maintain that package alone.
>>
>> Please check the dates on the ticket.
>>
>> Then please read https://www.sixxs.net/news/
> 
> I'm very well aware of both.

Are you sure?

As the text provided there is quite clear about the situation.

But maybe we need to re-iterate it again.

>> Then finally Call Your ISP for Native IPv6.
> 
> I already did. The answer so far was "We don't need that yet." :-(
> They seem to think that owning enough IPv4 address suffices and maybe
> also that there's no customer demand (yet).

As your ISP apparently is UPC Cablecom, which is part of the European
Cable Monopoly that is Liberty Global you should be aware that they are
providing DS-Lite to all their new customers, and have been silently
switching every cheap account to it to all around Europe.

That their helpdesk does not know what they actually provide, just shows
that you asked the wrong people.

Indeed, they are correct they have enough IPv4, this as they have been
telling RIPE for years that every customer needed 6 IPv4 IPs and have
silently been taking them away by changing contract language and what is
actually provided.

Lots of people with Playstations are having a lot of fun because of that.

> And in general: Just one person asking doesn't make them provide IPv6
> instantly. It needs enough people to nag them to realise the demand.

How often did you really call?

How often did you ask your friends, family, relatives, anybody you know
to call?

> Another issue is choice: At some locations, especially those with
> fiber, you don't have a choice wrt. to ISPs, otherwise changing the
> ISP towards one with native IPv6 connectivity is also an option.

Sounds you have a monopoly problem.

Read the news articles mentioned above, they mention what you could have
been doing about that in the last 20 years.

>> It is 2016. SixXS won't be around for much longer to provide free
>> connectivity
> 
> Yes, but until SixXS closes down, we want and need aiccu maintained
> properly in Debian.

AICCU has not been 'maintained properly' for well over a decade.

And 'closing down' will be sooner than you will want or expect.

PoPs are going to be dropping like flies soon. We do not have time for
it anymore, and the ISPs providing them in many cases for over a decade
have deployed native IPv6 for their customers and thus there is no need
for them to provide them.

>> Hence, better to stop wasting your time: Go Get Native IPv6.
> 
> I disagree that bringing the package back in shape is a waste of time,
> especially if getting native IPv6 is not yet possible everywhere at
> the moment.

I heavily suggest you spend your time more wisely.

The package we build over a decade ago functioned quite fine. The
changes made by various Debian "Developers" who never asked the upstream
about anything did not do much good to that though.

That we where cut off from Debian from maintaining it, is something we
have not been able to solve due to lack of will from people who hold the
ability to do so.

We thus have no interest in further bothering with it either.

Call Your ISP and get Native IPv6.

And spend your time on something more worthy than this IPv6 thing,
something we should have been doing: nobody will ever thank you for it.

Greets,
 Jeroen

Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility

[Axel Beckert]

Hi Jeroen,

Jeroen Massar wrote:
> On 2016-10-09 18:56, Axel Beckert wrote:
> > I'm yet another DD who's interested in having that package maintained
> > properly in Debian (and who NMUed it once in the past for that
> > reason). But I don't want to maintain that package alone.
> 
> Please check the dates on the ticket.
>
> Then please read https://www.sixxs.net/news/

I'm very well aware of both.
 
> Then finally Call Your ISP for Native IPv6.

I already did. The answer so far was "We don't need that yet." :-(
They seem to think that owning enough IPv4 address suffices and maybe
also that there's no customer demand (yet).

And in general: Just one person asking doesn't make them provide IPv6
instantly. It needs enough people to nag them to realise the demand.

Another issue is choice: At some locations, especially those with
fiber, you don't have a choice wrt. to ISPs, otherwise changing the
ISP towards one with native IPv6 connectivity is also an option.

> It is 2016. SixXS won't be around for much longer to provide free
> connectivity

Yes, but until SixXS closes down, we want and need aiccu maintained
properly in Debian.

> Hence, better to stop wasting your time: Go Get Native IPv6.

I disagree that bringing the package back in shape is a waste of time,
especially if getting native IPv6 is not yet possible everywhere at
the moment.

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

Bug#840241: RFS: gxkb/0.7.8-1

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: gxkb
   Version : 0.7.8-1
   Upstream Author : Dmitriy Poltavchenko 
 * URL : http://sourceforge.net/projects/gxkb/files/
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

gxkb  - X11 keyboard indicator and switcher

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


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


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gxkb/gxkb_0.7.8-1.dsc


  Changes since the last upload:

  * New upstream release.
  * Bump debhelper compat version to 10.


  Regards,
   Mateusz Łukasik

Bug#840240: RFS: openbox/3.6.1-3

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: openbox
   Version : 3.6.1-3
   Upstream Author : Dana Jansens 
 * URL : openbox.org
 * License : GPL-2+
   Section : x11

  It builds those binary packages:

 gnome-panel-control - command line utility to invoke GNOME panel run 
dialog/menu

 libobrender32v5 - rendering library for openbox themes
 libobt2v5  - parsing library for openbox
 openbox- standards-compliant, fast, light-weight and extensible 
window man

 openbox-dev - development files for the openbox window manager
 openbox-gnome-session - command line utility to run Openbox as GNOME 
session
 openbox-kde-session - command line utility to run Openbox as KDE SC 
session


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


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


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

dget -x 
https://mentors.debian.net/debian/pool/main/o/openbox/openbox_3.6.1-3.dsc


  Changes since the last upload:

   * debian/control:
+ Bump Standards-Version to 3.9.8.
+ Use secured links for VCS.
+ Add libxcursor-dev to B-D. (Closes: #838326, LP: #1336521)
  * Bump debhelper compat to 10.
  * debian/patches:
+ Add 808138_Replace-getgrent-with-getgroups.patch for not enumerate
all groups at startup (Closes: #808138)
+ Add d9a405e9.patch cherry-pick from upstream to Add 'last' as a 
desktop

target for if/foreach.
  * Drop menu file.


  Regards,
   Mateusz Łukasik

Bug#838440: [Pkg-javascript-devel] Bug#838440: nodejs: can't migrate to testing because of lack of armel binaries

[Jérémy Lal]

2016-10-06 12:24 GMT+02:00 Sebastiaan Couwenberg :

> On 10/06/2016 12:21 PM, Jérémy Lal wrote:
> > 2016-09-21 11:53 GMT+02:00 Sebastiaan Couwenberg :
> >
> >> On 09/21/2016 11:34 AM, Jérémy Lal wrote:
> >>> 2016-09-21 10:24 GMT+02:00 Emilio Pozuelo Monfort :
>  I see you dropped support for armel in #818552 and requested the
> removal
>  of the outdated armel binaries. That's fine. However, nodejs doesn't
>  migrate to testing because the lack of armel binaries breaks a number
>  of packages that depend on nodejs on armel:
> 
>  trying: nodejs
>  skipped: nodejs (15, 0, 81)
>  got: 68+546: a-3:i-18:a-0:a-11:a-0:m-0:m-0:p-35:p-0:s-1:m-546
>  * armel: node-almond, node-groove, node-iconv, node-leveldown,
>  node-node-expat, node-sqlite3, node-topcube, node-websocket, node-ws,
>  node-xmlhttprequest, qtwebchannel5-examples
> 
>  Those need to get their armel binaries removed as well.
> 
> >>>
> >>> Thank you for your help, at some point i believed the request for
> removal
> >>> implied removal of dependencies as well.
> >>> Should i make another removal request ? Would you like to do it ? I'm
> >>> super-busy right now.
> >>
> >> I've filed the RM bugs for the affected packages, some more may be
> >> required for their reverse dependencies.
> >
> > Thank you. Can we close this bug now ?
>
> No, ftp-master has not removed all the rdeps yet, so there are still RM
> bugs blocking this issue.


Now the same is going to happen with "powerpc" arch: libv8 is actually not
compatible with all processors supported by debian (ppc64xx are ok, though).

Sebastiaan, i feel bad asking for your help again, but since you already
filled
all the RM bugs once, i suppose you're in the best position to do it again
for
powerpc.

Jérémy.

Bug#805878: dh-systemd: dh_systemd_start --no-start --restart-after-upgrade causes the service to be started on install

[Felipe Sateler]

Control: tags -1 patch

On 23 November 2015 at 11:34, Felipe Sateler  wrote:
> Package: dh-systemd
> Version: 1.24
> Severity: normal
>
> Current autoscript has:
>
> if [ -d /run/systemd/system ]; then
> systemctl --system daemon-reload >/dev/null || true
> if [ -n "$2" : ]; then
> _dh_action=try-restart
> else
> _dh_action=start
> fi
> deb-systemd-invoke $_dh_action #UNITFILES# >/dev/null || true
> fi
>
>
> And this does not take into account that --no-start was passed. If it
> was passed, then try-restart should always be used.

This is more problematic now that restart-on-upgrade is default. The
following patch fixes the issue:

diff --git a/autoscripts/postinst-systemd-restartnostart
b/autoscripts/postinst-systemd-restartnostart
index e69de29..eb52e27 100644
--- a/autoscripts/postinst-systemd-restartnostart
+++ b/autoscripts/postinst-systemd-restartnostart
@@ -0,0 +1,6 @@
+if [ -d /run/systemd/system ]; then
+ systemctl --system daemon-reload >/dev/null || true
+ if [ -n "$2" ]; then
+ deb-systemd-invoke try-restart #UNITFILES# >/dev/null || true
+ fi
+fi
diff --git a/dh_systemd_start b/dh_systemd_start
index 940fc80..46c14a7 100755
--- a/dh_systemd_start
+++ b/dh_systemd_start
@@ -225,7 +225,8 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
  };

  if ($dh{RESTART_AFTER_UPGRADE}) {
- $sd_autoscript->("postinst", "postinst-systemd-restart");
+ my $snippet = "postinst-systemd-restart" . ($dh{NO_START} ? "nostart" : "");
+ $sd_autoscript->("postinst", $snippet);
  } elsif (!$dh{NO_START}) {
  # We need to stop/start before/after the upgrade.
  $sd_autoscript->("postinst", "postinst-systemd-start");


-- 

Saludos,
Felipe Sateler

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[GCS]

Control: tags -1 +confirmed

Hi Lucas,

On Sun, Oct 9, 2016 at 9:06 PM, Lucas Nussbaum  wrote:
> in the bug report, I wrote:
>> If the failure looks somehow time/timezone related:
 Sure, but tried in my unclean chroot, in an up-to-date+clean pbuilder
tree and on porterboxes. Then did a sourceful upload and it was
working everywhere, seems tzdata pulled in some other way.

> Did you try with tzdata not installed in the chroot?
 Just purged it and yes, confirm your findings.

> I can reproduce the failure with tzdata not installed. If I install tzdata, it
> builds fine. The package probably needs a build-depends on tzdata (and maybe a
> depends as well).
 Needs checking, now I don't think it needs a depends on tzdata.

Regards,
Laszlo/GCS

Bug#837679: [Pkg-samba-maint] Bug#837679: samba: Start fails for Samba as 'active directory domain controller'

[Mathieu Parent]

"

2016-09-13 14:58 GMT+02:00 Axel Dürrbaum :
> Package: samba
> Version: 2:4.4.5+dfsg-3
> Severity: important
>
> Dear Maintainer,
>
> after updating Samba from 2:4.3.8+dfsg-1 to  2:4.4.5+dfsg-3 I cannot start it
> anymore:
>
> [2016/09/13 10:13:29.504945,  0] ../source3/nmbd/nmbd.c:923(main)
>   server role = 'active directory domain controller' not compatible with
> running nmbd standalone.
>   You should start 'samba' instead, and it will control starting the internal
> nbt server

This check (upstream commit 8c71dc3505ab83ce95ab40a56f77313c4448be16,
from 2012) is here since samba 4.0.

As written, the nbt "server service" takes care of "NetBIOS over
TCP/IP. You don't need nmbd in your setup.


> Result: there will be no nmbd daemon running.

But do you have any missing feature?

What does "service samba-ad-dc status" outputs (with "server role =
'active directory domain controller' ")?

> When switching to server role = 'standalone' or 'auto' Samba starts but I 
> loose
> all domain users ...

Yes.

> Reinstalling 2:4.3.8+dfsg-1 does not help, the error stills remains.

Not a surprise.

Regards

-- 
Mathieu Parent

Bug#840239: /usr/bin/python3.5: /usr/bin/python3.5: pdb3.5 man page - wrong path to Python Library Reference

[Stephan Gabert]

Package: python3.5-minimal
Version: 3.5.2-6
Severity: minor
File: /usr/bin/python3.5

Dear Maintainer,

The man page (section 'SEE ALSO') of pdb3.5 refers to the Python Library 
Reference
of the python3.5-doc package at
  /usr/share/doc/python3.5/html/lib/module-pdb.html
but my version lies in:
  /usr/share/doc/python3.5/html/library/pdb.html

Furthermore there's also a reference to
  /usr/lib/python3.5/pdb.doc
within the man page's section 'DESCRIPTION', but I can't find such a file.

I just find following packages including a pdb.doc:
  $ apt-file search pdb.doc
  libpython2.7-stdlib: /usr/lib/python2.7/pdb.doc
  pypy-lib: /usr/lib/pypy/lib-python/2.7/pdb.doc

python3.5-doc info:
  $ aptitude show python3.5-doc
  Package: python3.5-doc
  Version: 3.5.2-6
  State: installed

Is the man page of pdb3.5 (and potentially other python3.5-related man pages) 
outdated?

Greetings,
Stephan Gabert

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

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

Versions of packages python3.5-minimal depends on:
ii  libc6 2.24-3
ii  libexpat1 2.2.0-1
ii  libpython3.5-minimal  3.5.2-6
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages python3.5-minimal recommends:
ii  python3.5  3.5.2-6

Versions of packages python3.5-minimal suggests:
ii  binfmt-support  2.1.6-1

-- no debconf information

Bug#839884: [Pkg-utopia-maintainers] Bug#839884: network-manager: Confirmed here

[Manuel Bilderbeek]

Hi,

On 06-10-16 23:37, Michael Biebl wrote:

I also see the hangup:

Setting up libkf5widgetsaddons-data (5.26.0-1) ...
Setting up network-manager (1.4.2-1) ...

and then nothing. ps -Af says:

root  4897  2663  0 21:35 pts/200:00:00 /usr/bin/dpkg --status-fd 80 
--configure --pending
root  4906  4897  0 21:35 pts/200:00:00 /bin/sh 
/var/lib/dpkg/info/network-manager.postinst configure 1.4.0-4
root  4972 1  0 21:35 ?00:00:00 /usr/sbin/NetworkManager 
--no-daemon
root  5060  4906  0 21:35 pts/200:00:00 /bin/systemctl try-restart 
NetworkManager-dispatcher.service
root  5061  5060  0 21:35 pts/200:00:00 
/bin/systemd-tty-ask-password-agent --watch



What's the output of systemctl status NetworkManager-dispatcher.service


I can't tell you at that point, as I have simply killed these last 2 
processes and that made aptitude continue installing. I always turn off 
the PC when I go to sleep, so I had to stop it anyway.


Let me know if there's still anything I can do.

--
Kind regards,

Manuel

Bug#840238: radvd has a new upstream release

[Geert Stappers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: radvd
Version: 1:2.11-1
Severity: wishlist


Hi,

At http://www.litech.org/radvd/ is version 2.15 announce.

Having that release in Stretch would be nice.


Perhaps I will package and upload it myself,
but please don't wait for me   ;-)


Groeten
Geert Stappers
- -- 
Leven en laten leven
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJX+qDuAAoJECE10SPYwZvs0sEP/15k0CXj3qs14mWRXhkoNcyg
lCp8e8uEoAAIY/Q00GXeniUKA2kxX26P9tCZ6Uq+igUBvL8N15kMG0s2rCAKeqVi
wS8j3Z7klIlOPBS6T2Df6w/Ut/aeGI+JuHNOv0cIHRed9JrVJ5ztVw2xe+3Jz1il
WCoNUuXY4s9IGrJ0c6R3qhk0zEFeOjcSPC7Yp6ptcipYVeRNNizxHqMrcP1fvhFI
qlaiOY2AnWqQosRj/255BRJzvjGe+iWNiV4VIAuHxs6olgjkk0NpxJCWw8KPf5s0
czl0rMg3BTAMcWrdkv29uPiSFmAs+XNRmct//bvkpW1RVnYajPphwj7r/qrWkmdJ
I90OgA2YhidlRhaqmfuV3L1c3ONYsk61HSWbNoAv+AXcfYNL2vBwZu+rv1BeTe5r
IrT38xqp8uQBPuSj1f9MZBSUvxc/Tq/pgDVNr2DNpn/TW24s582+KX7Vv/8O6IVS
0ZlWY5HPE8DRbw3tVoTmu+YGgfloLPAOtLYKqSGWej6tnkCeQQA4pUN14TvrY//b
1f4wFEKi7ZWL76w8yWPoyZGFoKjB/f62n8j8PICWyqH0n/gNPnxdwtZfNODqeRE0
hihsJwk04mZV2OQPJiNML4a1jE0u8FV9t5J7r/LXNI58DD9llQuesMlCDn5IISGd
V1ycWTP2heAVRjYiPoYC
=qbYP
-END PGP SIGNATURE-

Bug#840237: RM: kanla -- ROM; unmaintained upstream, few users, FTBFS bug #839388

[Michael Stapelberg]

Package: ftp.debian.org
Severity: normal

I’m the maintainer (and upstream) for kanla, a program which I no longer
use myself and which is decaying in the Debian archive as evidenced by
bug #839388 (kanla FTBFS).

Given that I no longer want to invest any time in maintaining kanla,
neither upstream nor in Debian, I think it’s best to just remove the
package. popcon reports a total of 2 installations.

Bug#840155: [Pkg-tcltk-devel] Bug#840155: xotcl: please make the build reproducible

[Chris Lamb]

> > ...
> > foreach {f fb} [lsort $fileList] {
> > ...

I think I'm missing this email of this thread. Anyway, seems like my
patch — even if not to be used verbatim — was enough to concisely show
the problem and it thus achieved its aims. :)

Thanks!


Regards,

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

Bug#692465: RFA: aiccu -- SixXS Automatic IPv6 Connectivity Client Utility

[Jeroen Massar]

On 2016-10-09 18:56, Axel Beckert wrote:
> Hi,
> 
> I'm yet another DD who's interested in having that package maintained
> properly in Debian (and who NMUed it once in the past for that
> reason). But I don't want to maintain that package alone.

Please check the dates on the ticket.

Then please read https://www.sixxs.net/news/

Then finally Call Your ISP for Native IPv6.

It is 2016. SixXS won't be around for much longer to provide free
connectivity while you nor your ISP can't be bothered with it.

Hence, better to stop wasting your time: Go Get Native IPv6.

Greets,
 Jeroen

Bug#839444: libgda5: FTBFS: tests failures annotations:

[Lucas Nussbaum]

On 04/10/16 at 13:40 +0200, Michael Biebl wrote:
> Hi Lucas!
> 
> Am 04.10.2016 um 12:56 schrieb Lucas Nussbaum:
> > On 04/10/16 at 12:13 +0200, Andreas Henriksson wrote:
> >> On Tue, Oct 04, 2016 at 08:34:16AM +0200, Lucas Nussbaum wrote:
> >>> severity 839444 serious
> >>> thanks
> >> [...]
>  If you can reproduce the problem, please provide a backtrace from the
>  segmentation fault.
> >>>
> >>> I can (on two different machines)
> >>
> >> ... but you still don't want to provide a backtrace?
> > 
> > When I do archive rebuilds, I automatically retry failed builds on a
> > different machine. So, yes, the failure is (most likely) not random, and
> > reproducible.
> > 
> > If you tried building it, and succeeded, why don't you post a build log,
> > then diff it with mine? Most likely, that will show a difference that
> > explains why the result is different. If it does not, then I'm willing
> > to restart all my rebuild setup and debug that. But I'd rather not do
> > that if it can be avoided by a cheaper plan.
> 
> Such (successful) build logs should be available from buildd.d.o afaics.
> They are quite recent [1].

Hi,

So, I tried to investigate this.

First, I ran into another failure:
(unstable-amd64-sbuild)root@ip-172-31-7-134:~/libgda5-5.2.4/tests# make 
check-TESTS
make[1]: Entering directory '/root/libgda5-5.2.4/tests'
PASS: test-ddl-creator
PASS: test-bin-converter
PASS: test-sql-identifier
PASS: test-identifiers-quotes
PASS: test-sql-builder
PASS: test-connection-string-split
FAIL: test-input-parsers
PASS: test-quark-list
PASS: test-sql-renderer

Testsuite summary for GNU Data Access 5.2.4

# TOTAL: 9
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=libgda

Makefile:1138: recipe for target 'test-suite.log' failed
make[1]: *** [test-suite.log] Error 1
make[1]: Leaving directory '/root/libgda5-5.2.4/tests'
Makefile:1244: recipe for target 'check-TESTS' failed
make: *** [check-TESTS] Error 2

That one is due to a missing build-dep on tzdata. 


After adding that build-dep, I can confirm that the package builds fine now.
There are some changes in versions of build-dependency, maybe one of them was
fixed in the meantime.

I don't know if test suite failures are frequent in that package, but it would
be useful to display the content of the log file in case of failure, so that it
ends up in the log.

Lucas


signature.asc
Description: PGP signature

Bug#839388: kanla: FTBFS randomly (failing tests)

[Michael Stapelberg]

Turns out I screwed up the 1.5 upload in that I forgot to push the changes
to the kanla git repository and don’t have them anymore. Hence, applying
the fix isn’t easy enough to justify spending the effort.

I’ll file a removal request for kanla instead.

On Wed, Oct 5, 2016 at 7:12 PM, Santiago Vila  wrote:

> tags 839388 + patch
> thanks
>
> On Wed, Oct 05, 2016 at 06:49:45PM +0200, Michael Stapelberg wrote:
>
> > Just to set expectations: kanla is unmaintained upstream by now, and I
> > don’t intend to address this issue. If any user of kanla would like to
> step
> > up and contribute a fix, that’d be welcome.
>
> I'm not a user myself (this is just QA work), but the package builds
> ok and it's only the tests that fail randomly.
>
> So if the package is unmaintained upstream I would just disable the
> tests:
>
> --- a/debian/rules
> +++ b/debian/rules
> @@ -5,3 +5,5 @@ override_dh_fixperms:
>
>  %:
> dh $@ --with=systemd
> +
> +override_dh_auto_test:
>
> This will always be better than having a package which FTBFS half of
> the time.
>
> Thanks.
>



-- 
Best regards,
Michael

Bug#840155: [Pkg-tcltk-devel] Bug#840155: xotcl: please make the build reproducible

[Stefan Sobernig]

My apologies:

> ...
> foreach {f fb} [lsort $fileList] {
> ...

The correct patch is:

...
foreach {f fb} [lsort -stride 2 $fileList] {
...

(assuming it is correct to assume Tcl 8.6 to be the default build-dep).

Stefan

Bug#796341: radvd colabmaint

[Geert Stappers]

On Mon, May 30, 2016 at 03:41:41PM +0200, Ghe Rivero wrote:
> On Sun, May 29, 2016 at 7:11 AM, Geert Stappers  wrote:
> 
> > Hello Ghe,
> >
> > Are you okay with having radvd in collaborative maintenance?
> >
> > https://wiki.debian.org/CollaborativeMaintenance
> >
>
> Please, go ahead.
> 
> Thanks a lot,
> Ghe Rivero

Unlikely that I will have it in place before the november 5th freeze.

My idea / plan is to start with a self hosted git repository.


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Bug#772576: looking for a hint

[Mechtilde]

Hello,

in the meantime I got a new maschine with more power. While i start
taskcoach i run htop too. so I can see that the CPU arised for taskcoach
(40 %) AND lightdm (nearly 60 %).

This maschine is a ThinkPad X250 i5-5xxx with 8 GB

Am 08.10.2016 um 13:24 schrieb Nicolas Boulenguez:
> Hello.
> In order to investigate the issue, an upstream author asks whether the
> path to your HOME directory contain non-ASCII characters.

The path to my HOMe directory / the directory to the Taskcoach file
contains only ASCII characters.

> Thanks.
> 

I hope I cvan help with these informations

Kind regards


Mechtilde Stehmann
--
## Debian
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## Key-ID 0x141AAD7F




signature.asc
Description: OpenPGP digital signature

Bug#837171: synaptic: Closes with weird error message

[Frank McCormick]

Package: synaptic
Version: 0.83+nmu1
Followup-For: Bug #837171

When Synaptic closes it deliver a weird error message:

root@frank:/home/frank# synaptic
cannot open /etc/aptapt.conf.d/99synaptic to write APT::Install-Recommends

I think there should be a forward slash in between the two "apt". There is no 
/etc/aptapt.conf.d




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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.15-1
ii  libapt-inst2.0   1.3.1
ii  libapt-pkg5.01.3.1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libept1.5.0  1.1+nmu3+b1
ii  libgcc1  1:6.2.0-5
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-2
ii  libgnutls30  3.5.4-2
ii  libgtk-3-0   3.22.1-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpcre2-8-0 10.22-2
ii  libstdc++6   6.2.0-5
ii  libvte-2.91-00.46.0-1
ii  libx11-6 2:1.6.3-1
ii  libxapian30  1.4.0-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages synaptic recommends:
ii  gksu   2.0.2-9
ii  libgtk2-perl   2:1.2499-1
ii  policykit-10.105-16
ii  rarian-compat  0.8.1-6
ii  xdg-utils  1.1.1-1

Versions of packages synaptic suggests:
pn  apt-xapian-index 
ii  deborphan1.7.28.8-0.3
pn  dwww 
ii  menu 2.1.47
pn  software-properties-gtk  
ii  tasksel  3.36

-- no debconf information

Bug#799586: dosbox: DOSBox quits after starting some games e.g. Screamer Rally

[Sven Arvidsson]

retitle 799586 Screamer Rally, HOMM2: segfault in __ieee754_pow_sse2
tags 799586 patch
thanks

Hi,

Both Screamer Rally and Heroes Of Might And Magic II segfault at the
same point:

#0  0x75f4e9d8 in __ieee754_pow_sse2 (x=2,
y=0.33215)
at ../sysdeps/ieee754/dbl-64/e_pow.c:114
#1  0x75f5dec4 in __pow (x=2, y=0.33215) at
w_pow.c:27

In HOMM2 it happens at the end of a turn. Presumably other titles are
affected too.

This seems to be a regression, and current svn of Dosbox does indeed
work fine.

I did a reverse svn-bisect to find the commit that fixed this and
found https://sourceforge.net/p/dosbox/code-0/3674

That commit mentions OSX, but applying it to the Debian package does
fix the problem, so I guess 64-bit Linux uses the same code path?

I'm not sure if only backporting this single fix is worth it, as it
looks like other things have regressed too (the opengl renderer) so
maybe an update to current svn is in order?

HTH,

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se

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

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[Lucas Nussbaum]

Control: tags -1 -unreproducible
Control: tags -1 -moreinfo
Control: severity -1 serious

Hi László,

in the bug report, I wrote:
> If the failure looks somehow time/timezone related:
> Note that this rebuild was performed without the 'tzdata' package
> installed in the chroot. tzdata used be (transitively) part of
> build-essential, but it no longer is. If this package requires it to
> build, it should be added to build-depends. For the release team's
> opinion on this, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836940#185

This is the case here, given that the failing test is
> FAIL: modules/date/tests/test_date

Did you try with tzdata not installed in the chroot?

I can reproduce the failure with tzdata not installed. If I install tzdata, it
builds fine. The package probably needs a build-depends on tzdata (and maybe a
depends as well).

Lucas

Bug#840236: qemu: CVE-2016-7995: usb: hcd-ehci: memory leak in ehci_process_itd

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.6+dfsg-3.1
Severity: normal
Tags: security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2016-7995[0]:
usb: hcd-ehci: memory leak in ehci_process_itd

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-7995
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1382668
[2] https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06609.html

Please adjust the affected versions in the BTS as needed. In
particular please double-check/review the note in the security-tracker
if this is correct. 

Regards,
Salvatore

Bug#840231: src:neovim: FTBFS if name of building user contains a digit

[James McCoy]

On Sun, Oct 09, 2016 at 08:38:27PM +0200, Jakob Haufe wrote:
> the way debian/rules extracts the UID/GID of the current user fails when the
> user name contains a digit:
> 
> sur5r@samsa:~$ id | cut -d' ' -f 1 | egrep -o '[0-9]+'
> 2000
> 5
> sur5r@samsa:~$
> 
> I'd suggest switching to "id -u" and "id -g", respectively.

Thanks! I'm not sure how I missed that in the man page. :)

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

Bug#835119: similar problem

[Brian Warner]

I'm seeing a similar problem, except that the computer in question has
been running continuously the whole time, and it's directly connected to
the internet (so no firewalls or NAT-entries that might be timing out).

This is with tor-0.2.8.8-1 (in sid). What I'm noticing is that if the
Tor daemon has been running for a while, a basic connection via the
SOCKS port never connects. If I bounce the daemon, then a connection
works. The daemon is not generally doing anything else: it's pretty
idle.

I haven't yet characterized how long it must be idle before connections
cease to work.. I'll try increasingly long intervals over the next week.
The current datapoint is that an uptime of 9.5 days lead to a failure,
but a connection that happens one minute after startup works.

I *did* see that 'arm' reported 0 circuits open when it was not working,
although just a few minutes before my (failed) test, /var/log/tor/log
said "Tor has successfully opened a circuit. Looks like client
functionality is working.", so it's not entirely idle (but also entirely
not working).

cheers,
 -Brian

Bug#840235: Lintian dir-or-file-in-etc-opt should not be 'fatal'

[David Steele]

Package: ftp.debian.org
thanks

Debian Policy does not support blanket rejects based on the Lintian
dir-or-file-in-etc-opt tag.
The tag should be removed from the "fatal" list at
https://ftp-master.debian.org/static/lintian.tags.

Rationale

The Debian Policy has little to say about opt, except that the FHS
must be followed. There
is a stated ban concerning /usr/local, but nothing specific about opt.

The FHS explicitly states that distributions MAY place files under
/opt (with narrow exceptions
outside of the /etc/opt tree), and that /etc/opt is there to support
such files, as long as the
local admin is given an option to bail.

If circumstances dictate, the Policy does not preclude the use of
files installed under /etc/opt.

Reference - #825820

Bug#840233: [liferea] Once changed, headlines order can not be set back to chronological order

[Paul Gevers]

control: forwarded -1 https://github.com/lwindolf/liferea/issues/408

Reported upstream.



signature.asc
Description: OpenPGP digital signature

Bug#840233: [liferea] Once changed, headlines order can not be set back to chronological order

[Bruno Kleinert]

Package: liferea
Version: 1.12~rc1-5
Severity: minor

--- Please enter the report below this line. ---
Hi,

with this RC version it became impossible to change the order of
headlines back to chronological order once a user changes it by
clicking on the "Headline" labeled bar. Once clicked, it allows only to
toggle between alphabetical and reversed alphabetical order.

The only way I could find to get back chronological order is by
quitting liferea, editing $HOME/.config/liferea/feedlist.opml directly
and setting sortColumn="time" for the affected feed(s).

I know it's not a stable release of liferea, but maybe nobody happened
to stumble over this, yet :)

Greetings - Fuddl

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

Debian Release: stretch/sid
  500 unstableftp.uni-erlangen.de 
1 experimentalftp.uni-erlangen.de 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
default-dbus-session-bus| 
 OR dbus-session-bus| 
gir1.2-peas-1.0 | 1.20.0-1
liferea-data (= 1.12~rc1-5) | 1.12~rc1-5
python-gi   | 3.22.0-1
gir1.2-freedesktop  | 1.50.0-1
gir1.2-gtk-3.0  | 3.22.1-1
dconf-gsettings-backend | 0.26.0-2
 OR gsettings-backend   | 
python3.5   | 3.5.2-6
python3:any   (>= 3.3.2-2~) | 
libc6 (>= 2.14) | 2.24-3
libgdk-pixbuf2.0-0  (>= 2.22.0) | 2.36.0-1
libgirepository-1.0-1(>= 0.9.3) | 1.50.0-1
libglib2.0-0(>= 2.41.1) | 2.50.0-2
libgtk-3-0  (>= 3.5.12) | 3.22.1-1
libjson-glib-1.0-0  (>= 0.12.0) | 1.2.2-1
libpango-1.0-0  (>= 1.14.0) | 1.40.3-2
libpeas-1.0-0(>= 1.1.0) | 1.20.0-1
libsoup2.4-1(>= 2.30.0) | 2.56.0-1
libsqlite3-0 (>= 3.5.9) | 3.14.2-1
libwebkit2gtk-4.0-37 (>= 2.5.3) | 2.14.0-1
libxml2  (>= 2.9.0) | 2.9.4+dfsg1-2
libxslt1.1  (>= 1.1.25) | 1.1.29-1


Recommends   (Version) | Installed
==-+-===
gir1.2-gnomekeyring-1.0| 3.12.0-1+b1
gir1.2-gstreamer-1.0   | 1.8.3-1
gnome-keyring  | 3.20.0-3


Suggests (Version) | Installed
==-+-===
kget   | 
network-manager| 1.4.2-1







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

Bug#840208: llvm-toolchain-3.8: FTBFS when golang-go is installe

[Sylvestre Ledru]

Le 09/10/2016 à 17:10, Adrian Bunk a écrit :
> Source: llvm-toolchain-3.8
> Version: 1:3.8.1-12
> Failing Tests (1):
> LLVM :: Bindings/Go/go.test
> 
> test/CMakeFiles/check-llvm.dir/build.make:60: recipe for target 
> 'test/CMakeFiles/check-llvm' failed
> make[5]: *** [test/CMakeFiles/check-llvm] Error 1

Having the actual error would be helpful ;)

S

Bug#838553: Update 1.17-3.2+deb7u1 breaks libtommath integration (-DLTM_DESC needed)

[Michael Stapelberg]

[+cc mejo, who did the upload in question]

Looking into
http://security.debian.org/debian-security/pool/updates/main/libt/libtomcrypt/libtomcrypt_1.17-3.2+deb7u1.diff.gz,
I see debian/rules contains this line:

+CFLAGS += -DGMP_DESC -DLTM_DESC -DUSE_LTM

So the flag seems to be set accordingly.

Not quite sure what’s wrong here.

On Thu, Sep 22, 2016 at 10:52 AM, Milan Budala 
wrote:

> Package: libtomcrypt-dev
> Version: 1.17-3.2+deb7u1
> Severity: important
>
> Security update 1.17-3.2+deb7u1 breaks libtommath integration
> ('undefined reference to ltm_desc' linking error).
> No problems with version 1.17-3.2. The build should probably define
> LTM_DESC.
>
> -- System Information:
> Debian Release: 7.11
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.18.17-core2-rt14 (SMP w/1 CPU core; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages libtomcrypt-dev depends on:
> ii  libtomcrypt0  1.17-3.2+deb7u1
>
> libtomcrypt-dev recommends no packages.
>
> libtomcrypt-dev suggests no packages.
>
> -- no debconf information
>



-- 
Best regards,
Michael

Bug#840193: liferea: Notification icon doesn't work for hide.

[Paul Gevers]

Hi Christian,

On 09-10-16 15:42, Christian Marillat wrote:
> The notification icon works for show but don't for hide.

Could you try to explain better what you mean? I am not sure I
understand. You mean the icon in the menu bar, or the notifications? I
guess you mean that if you click on the icon, liferea doesn't hide, but
when liferea is hidden, is does pop up liferea? What windows manager are
you running? I run KDE and the behavior that I have is actually the
opposite. (But as I believe there is quite some GNOME in liferea, I
didn't investigate myself yet).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#840230: When installing to rootfs on LVM, an empty subvol= is appended to rootflags

[Dimitri John Ledkov]

I think I did fix this before

http://launchpadlibrarian.net/251885735/zipl-installer_0.0.33ubuntu1_0.0.33ubuntu2.diff.gz

I guess it did not make over to debian. Will fix soon.

Regards,

Dimitri.


On 9 October 2016 at 19:34, Philipp Kern  wrote:

> Package: zipl-installer
> Version: 0.0.33
> Severity: serious
>
> zipl-installer 0.0.33 breaks installation for normal non-btrfs root
> filesystems.
>
>   (initramfs) cat /proc/cmdline
>   root=/dev/mapper/vg-root rootflags=subvol= BOOT_IMAGE=0
>
> The empty subvol= makes mount barf as it's not a valid ext4 flag. The code
> does not seem too healthy to me either:
>
>   if subvol="$(btrfs subvolume show /target 2>/dev/null | sed -n
> '2s/.*:[\t ]*//p')"
>   then
>   info "Root filesystem on btrfs subvolume ${subvol}"
>   PARAMETER="$PARAMETER rootflags=subvol=${subvol}"
>   fi
>
> It'd have been more helpful to take the output and compare it to the empty
> string instead.
>



-- 
Regards,

Dimitri.

Bug#786963: asterisk: running /etc/init.d/asterisk start after a crash, or after issuing a stop via asterisk console doesn't start asterisk

[Bernhard Schmidt]

Control: fixed -1 1:13.0.0~dfsg-1

On Wed, May 27, 2015 at 10:35:33AM +0200, Simone Ricci wrote:

Hi,

> trying to start asterisk via /etc/init.d/asterisk start, or by issuing
> a systemctl start asterisk fails (nothing happens) if machine is
> recovering from a crash, asterisk itself has crashed or stopped via
> its console. That's probably related to systemd seeing it running even
> if it's not.
> 
> How to reproduce:
> * Start asterisk normally
> * Stop it via its console (eg. asterisk -rx 'core stop now')
> * Try to start it again, either via /etc/init.d/asterisk start or systemctl 
> start asterisk
> * Nothing Happens and systemctl reports the software as active, for example:
> 
>   root@softswitch-02:~# systemctl status asterisk
>   ● asterisk.service - LSB: Asterisk PBX
 ^^^

This is an issue specific to Jessie, which uses systemd but does not
ship a native systemd unit for Asterisk. The problem is that "systemctl
status" checks the status of the unit, but does not invoke the status
action of the init script for further checks. The unit is always active,
whether the process has exited or not.

The fix is to ship a native unit with the appropriate type, as done in
sid. I don't think this can be fixed in jessie, since adding systemd
units has never been accepted for stable updates in the past. You can
fix it locally by adding a systemd unit (i.e. use
https://sources.debian.net/src/asterisk/1:13.10.0~dfsg-1/contrib/asterisk.service/)
in either /lib/systemd/system or /etc/systemd/system.

Bernhard


signature.asc
Description: Digital signature

Bug#840232: [uscan] False warning "more than one main upstream tarballs listed"

[Daniel Leidert]

Package: devscripts
Version: 2.16.8
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I run uscan in a directory containing packaging directories. I see a lot
of these warnings

> uscan warn: more than one main upstream tarballs listed.

But I doubt they are correct. When switching into the sub-directory and
running `uscan --report' the warnings do not show up. So I guess somehow
the counter, that is responsible for these warnings, gets triggered (and
maybe is not reset to zero?).

As an example:

svn co svn://anonscm.debian.org/debichem/unstable/ -> run uscan here

Regards, Daniel


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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.10
ii  libc62.24-3
ii  perl 5.24.1~rc3-3
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.3.1
ii  at  3.1.20-1
ii  curl7.50.1-1
ii  dctrl-tools 2.24-2
ii  debian-keyring  2016.09.04
ii  dput0.10.3
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-2
ii  file1:5.28-4
ii  gnupg   2.1.15-4
ii  gnupg2  2.1.15-4
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.24-1
ii  lintian 2.5.48
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.29
ii  python3-magic   1:5.28-4
ii  sensible-utils  0.0.9
ii  strace  4.13-0.1
ii  unzip   6.0-20
ii  wdiff   1.2.2-1+b1
ii  wget1.18-4
ii  xz-utils5.2.2-1.1

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-3
ii  build-essential  12.2
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
ii  gpgv 2.1.15-4
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.29-1+b2
pn  mozilla-devscripts   
ii  mutt 1.7.0-6
ii  openssh-client [ssh-client]  1:7.3p1-1
pn  piuparts 
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.6
ii  w3m  0.5.3-29

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJX+o3BAAoJEEvNBWfCltBdLPkQAJgb+jCecDSrZE+MBt1PRUSf
JV1AgVPuWP7aGbTC1wg7NGKRgdxrQxNYmRFg+V8KW1YRnJ+98xuyZ0oPEeMssO2i
SE0jnWZ8qPEXyvVFdNlDOaijcqOQXcReato0V6bSc15rptQTZgtYlzzwl9OX9hfv
2mcbNHLzeSrUhNsuwPdCwJqliFoqujnK4okXtzov+NCjBySymhu12NPiYeqPvr/4
1qm1LjVUfeBygQyQASzLI/DDKSudX4E/Oo2ColzTynpchBOSdI2Tut8pGrJBeByK
rXU/DxyFY/zcxw/mSIWrvzctCgWwdoFwp9zBgExhdPDDtXZDkmpj/bMF5Gha73jh
jR0o2LpMtFa1Z715+5ZfMc+jxhW1kPZpXZjwWnosMk9Q4+I2zKjhdPYHCiikBvOz
P7HW9C6SCLFwBVQekdxcxC7sRoJv+c3FI9ssYpmuBkgOP7cPMFN9+DRMdaPURcWF
pj9sQrbsBNOoAu1l7bDZmAkS+pa2vfzcbhQX7VdzMUnQ5rbfpH+cDiO+Oc+wx8Q3
KbfdmBjptQ28LGNY6fDL6REOFR3Fhf+9bw5WHCL2iu207/t2ajOX/vASAb7o7cEr
yCyh+RDqzOexRVEazLcCOCWJoMvXjsIAo3nTMw7N/qUpZ0wou//AEvS0epRveG+s
8Dq5phKFggzXVFfSdK2H
=c07Y
-END PGP SIGNATURE-

Bug#840231: src:neovim: FTBFS if name of building user contains a digit

[Jakob Haufe]

Package: src:neovim
Version: 0.1.5-6
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

the way debian/rules extracts the UID/GID of the current user fails when the
user name contains a digit:

sur5r@samsa:~$ id | cut -d' ' -f 1 | egrep -o '[0-9]+'
2000
5
sur5r@samsa:~$

I'd suggest switching to "id -u" and "id -g", respectively.

Cheers,
sur5r


-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX+o6dAAoJEEzyshj1Ta49GzwQAL+p8po/gamPUi7mY8Q7xffM
+LSjZtdjhzrAt1xB+EB9e22jr1ixXPXGM4999KiFZ+UufdQ8B2BC59Ifw/DjakcT
VuTEtrustGUzZhcTec7zP3S9TtzS2+nnW+8Jw7JcRBTa2Ac3gISZy4hqCDA7bIQP
V7sDIFD8T+NZP7sShivXl71Xcf75VIH0AJxOaGXVOkPllNZvWJ4CqT9hguhBOcT3
MQna4bqc3YdoA4w/tE0oMeNWvSW/dy4+nwWpp8LXEwdsQEb22BS5iIhbxLoLvz+5
fL5jB+aHezafP+9KY4S9g7Lpj7IpyA2TJH5FE8h3hf1LWnrUkhTjufVXwpRhBfY0
O8+LujcJDKErlEXaLUQDSioSOLQ5yTmpX83EqcE4R1BFgsSaf/9OGy3TN95v4u4j
H8Px3BpJJ0871DTU4GL50pxHTIVm3Hgs6ykmIQFMKysxpFrL/xrhCxrMMVMdE7D5
LvPZADyiH+ruZFC+es5I7GTLvds89rjOu/vLNhJ7nIWIcdAlyehHCtYfca6Cp4FR
DZEGBQjFppHM/CIjZTJTe1ispFeiYrEwvEMgComhBkPT7cgXW06Syd7Np3RYNe4B
B5Z8a8DL6jt/InSPgDR5GLZzdrMrLYyUZvlFt7MXJM88+4eioCQ4wlTPApQBEqVV
B1hOsGoVKEIltHq7PGsj
=y6o9
-END PGP SIGNATURE-
--- debian/rules.orig	2016-10-09 20:27:43.417812556 +0200
+++ debian/rules	2016-10-09 20:28:02.777957447 +0200
@@ -19,8 +19,8 @@
   UNITTEST = unittest
 endif
 
-ID = $(shell id | cut -d' ' -f 1 | egrep -o '[0-9]+')
-GID = $(shell id | cut -d' ' -f 2 | egrep -o '[0-9]+')
+ID = $(shell id -u)
+GID = $(shell id -g)
 
 %:
 	dh $@ --parallel

Bug#840230: When installing to rootfs on LVM, an empty subvol= is appended to rootflags

[Philipp Kern]

Package: zipl-installer
Version: 0.0.33
Severity: serious

zipl-installer 0.0.33 breaks installation for normal non-btrfs root
filesystems.

  (initramfs) cat /proc/cmdline
  root=/dev/mapper/vg-root rootflags=subvol= BOOT_IMAGE=0 

The empty subvol= makes mount barf as it's not a valid ext4 flag. The code
does not seem too healthy to me either:

  if subvol="$(btrfs subvolume show /target 2>/dev/null | sed -n '2s/.*:[\t 
]*//p')"
  then
  info "Root filesystem on btrfs subvolume ${subvol}"
  PARAMETER="$PARAMETER rootflags=subvol=${subvol}"
  fi

It'd have been more helpful to take the output and compare it to the empty
string instead.

Bug#836601: [Pkg-amule-devel] Bug#836601: [amule] amulecmd gives "Warning: Mismatch between the program and library build versions detected."

[Sandro Tosi]

please try again with the new amule release in unstable/testing

On Sun, Sep 4, 2016 at 8:30 AM, Matteo Calorio  wrote:
> Package: amule
>
> Version: 2.4.0~git20151120.0023527bc2-1+b3
>
> Severity: minor
>
>
>
> --- Please enter the report below this line. ---
>
> Since the last update I get this warning:
>
>
>
> Warning: Mismatch between the program and library build versions detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
> containers,compatible with 2.8),
> and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx
> containers,compatible with 2.8).
> This is amulecmd SVN
>
> Regards,
>
> Matteo
>
>
>
> --- System information. ---
>
> Architecture: amd64
>
> Kernel: Linux 4.6.0-1-amd64
>
>
>
> Debian Release: stretch/sid
>
> 500 unstable download.jitsi.org
>
> 500 testing www.deb-multimedia.org
>
> 500 testing ftp.it.debian.org
>
>
>
> --- Package information. ---
>
> Depends (Version) | Installed
>
> -+-===
>
> amule-common (= 2.4.0~git20151120.0023527bc2-1) |
> 2.4.0~git20151120.0023527bc2-1
>
> libboost-system1.61.0 | 1.61.0+dfsg-2.1
>
> libc6 (>= 2.14) |
>
> libcrypto++6 |
>
> libgcc1 (>= 1:3.0) |
>
> libgeoip1 |
>
> libstdc++6 (>= 5.2) |
>
> libupnp6 (>= 1:1.6.13) |
>
> libwxbase3.0-0v5 (>= 3.0.2+dfsg) |
>
> libwxgtk3.0-0v5 (>= 3.0.2+dfsg) |
>
> zlib1g (>= 1:1.1.4) |
>
>
>
>
>
> Recommends (Version) | Installed
>
> ==-+-===
>
> amule-utils | 2.4.0~git20151120.0023527bc2-1+b3
>
> unzip | 6.0-20
>
>
>
>
>
> Suggests (Version) | Installed
>
> ==-+-===
>
> amule-utils-gui |
>
>
> ___
> Pkg-amule-devel mailing list
> pkg-amule-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-amule-devel



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

Bug#768073: LXC team take over ITP?

[Adnan Hodzic]

Jonathan and everybody else,

Since I couldn't find my original LXD package source, I started from
scratch.

I created new Git repo (pkg-lxc/lxd.git) and pushed initial Debian package
of LXD 2.4.1 (Yakkety release). Git repo is available on Alioth:
https://anonscm.debian.org/git/pkg-lxc/lxd.git

Building the package will fail due to missing golang-* deps which ATM are
missing in Debian. I can't remember if the original list of missing
dependencies was this long, but this is what we we're currently dealing
with:

---

Unmet build dependencies: golang-any-shared-dev golang-go.crypto-dev
golang-context-dev golang-github-gorilla-mux-dev
golang-github-gosexy-gettext-dev golang-github-mattn-go-colorable-dev
golang-github-mattn-go-sqlite3-dev golang-github-olekukonko-tablewriter-dev
golang-github-pborman-uuid-dev golang-gocapability-dev
golang-gopkg-flosch-pongo2.v3-dev golang-gopkg-inconshreveable-log15.v2-dev
golang-gopkg-lxc-go-lxc.v2-dev golang-gopkg-tomb.v2-dev golang-petname-dev
golang-yaml.v2-dev golang-websocket-dev

---

Has pkg-go team been notified of this problem? And are they willing to
package these for Debian?

Let me know if you have any additional questions and/or comments.

On Thu, Sep 29, 2016 at 7:49 PM, Adnan Hodzic  wrote:

> Jonathan,
>
> >> Awhile back I started packaging process. I basically re-packaged the LXD
> >> Ubuntu package. As Evgeni mentioned it "is what we did with the other
> LXC
> >> components and that worked out pretty well so far."
> >
> >Do you have that lying around, and if so is it worth us pushing it to a
> git
> >repo for pkg-lxc?
>
> I think it is, as once golang dependencies are satisfied, we can push it
> into Debian.
>
> Let me look in what state I left it in, also I want to update it to the
> latest lxd version and I'll push into pkg-lxc git repo. If there are no
> objections?
>
> I'll do this this weekend.
>
> On Thu, Sep 29, 2016 at 6:13 PM, Jonathan Dowland  wrote:
>
>> On Mon, Sep 26, 2016 at 12:35:24AM +0200, Adnan Hodzic wrote:
>> > Awhile back I started packaging process. I basically re-packaged the LXD
>> > Ubuntu package. As Evgeni mentioned it "is what we did with the other
>> LXC
>> > components and that worked out pretty well so far."
>>
>> Do you have that lying around, and if so is it worth us pushing it to a
>> git
>> repo for pkg-lxc?
>>
>> > At this point, I think we just need to align the efforts between pkg-go
>> and
>> > pkg-lxc teams, and we'll see LXD in Debian in no time.
>>
>> I've just joined both teams and opened an ITP for golang-petname. I've
>> got a
>> package prepared pending a few questions on the pkg-go list, I should get
>> it
>> into NEW Tomorrow. Then perhaps I can start on the others next week.
>>
>>
>> Thanks,
>>
>> --
>> Jonathan Dowland
>>
>
>
>
> --
> Adnan
>



-- 
Adnan

Bug#840189: dblatex fails in pdflatex: Use of \@xmultirow doesn't match its definition

[Anders Kaseorg]

Control: clone -1 -2
Control: reassign -2 texlive-latex-extra 2016.20161008-1
Control: retitle -2 texlive-latex-extra should Breaks: dblatex (<< 0.3.8-2~)
Control: severity -2 serious

Although it is not texlive-latex-extra’s fault that dblatex fails with the 
new version, I believe it should not enter testing without declaring this 
Breaks.  If you disagree, feel free to downgrade or close this.

Anders

Bug#840228: qemu: CVE-2016-7994: virtio-gpu: memory leak in virtio_gpu_resource_create_2d

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.6+dfsg-3.1
Severity: normal
Tags: security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2016-7994[0]:
virtio-gpu: memory leak in virtio_gpu_resource_create_2d

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-7994
[1] https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04129.html

Regards,
Salvatore

Bug#840227: libgit2: CVE-2016-8568 CVE-2016-8569

[Salvatore Bonaccorso]

Source: libgit2
Version: 0.24.1-2
Severity: grave
Tags: security upstream

Hi,

the following vulnerabilities were published for libgit2.

CVE-2016-8568[0, 3]:
Read out-of-bounds in git_oid_nfmt

CVE-2016-8569[1, 4]:
DoS using a null pointer dereference in git_commit_message

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-8568
[1] https://security-tracker.debian.org/tracker/CVE-2016-8569
[2] https://marc.info/?l=oss-security=147594097425642=2
[3] https://github.com/libgit2/libgit2/issues/3936
[4] https://github.com/libgit2/libgit2/issues/3937
[5] https://github.com/libgit2/libgit2/pull/3956

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#730904: The only failing tests in openmeeg are now on s390x

[Yaroslav Halchenko]

Thanks Adrian.

I will first try to gb openmeeg so we make sure it still fails this way
on s390x.

On Sun, 09 Oct 2016, Adrian Bunk wrote:

> Hi,

> the only remaining test failures in 2.3.0~20160502-2 are on s390x:
>   https://buildd.debian.org/status/package.php?p=openmeeg=sid

> At the moment this is the only problem preventing openmeeg from being 
> part of stretch.

> cu
> Adrian
-- 
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#839327: pandas: FTBFS: tests failures

[Yaroslav Halchenko]

On Sun, 09 Oct 2016, Rebecca N. Palmer wrote:

> The tests in question are checking that numexpr and numpy give the same
> answers (by default, pandas uses numexpr if available for large arrays but
> numpy for small ones), and require integers to match exactly.  The failing
> values are all 15**15, which is 437893890380859375 in exact arithmetic but
> 437893890380859392 in double-precision arithmetic.

> numpy int**int returns an int but uses doubles internally, so returns
> 437893890380859392.  (Upstream agree this is a bug, but haven't decided
> whether it should be an exact int or a float:
> https://github.com/numpy/numpy/issues/2475
> https://github.com/numpy/numpy/issues/899 )

> numexpr in jessie and testing does the same (which is why pandas built
> successfully before), but numexpr in sid returns the correct
> 437893890380859375.  (Given how little changed between 2.6.0 and 2.6.1,
> https://github.com/pydata/numexpr/commits/master, I suspect the cause of
> this may be further up the stack than numexpr itself, but have not actually
> done a "compile numexpr 2.6.0 in sid" test.)

> Hence, this failure is the result of an improvement(!), and the obvious
> workaround to get pandas building again would be to use approximate rather
> than exact matching in the tests in question.

> (You don't need to rebuild pandas to see this failure: running the test on
> its own, i.e. nosetests3 -v pandas/tests/test_expressions.py , is
> sufficient.)

Thank you Rebecca for the analysis and the references!  I will look into
patching it up in few days unless you beat me to it with an NMU or a
ready patch which would be super appreciated


-- 
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#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications

[Thomas Pircher]

Hi Gianfranco,

I missed to add you and 837...@bugs.debian.org in my last mail. In the 
upload to mentors from last week I have addressed your feedback (at 
least I think I did, that is). The only thing I'm not entirely sure 
about is the missing build-dependency on pkg-config as build-dependency, 
as described below.


Cheers,
Thomas

On 2016-10-02 18:07, Thomas Pircher wrote:

On 2016-09-28 22:37, Gianfranco Costamagna wrote:

[..] drop the explicit dependencies since dh-autoreconf already
depends on automake and libtool? If this is the customary way then 
I'll

drop the explicit dependencies on automake and libtool.


I think so. dh-autoreconf should be enough (with an added pkg-config 
if needed,

IIRC)


Hi Gianfranco,

automake and libtool are no longer explicit dependencies in my latest
upload to mentors [1]. But I haven't added pkg-config. It is not
required for building libcgicc and I could not find a mention of
pkg-config in the dh-autoreconf documentation. But if I'm missing
something than I'll be happy to add the build dependency.

I think patching it to be architecture independent might be the best 
solution


Thanks for that. I had not appreciated that packages may contain
bit-identical files. That does indeed solve my problem, and I have
patched out the --host and --libdir options and re-added the script to
the package.

Thanks again for your continuing efforts!

Thomas


[1] https://mentors.debian.net/package/libcgicc

Bug#840226: npm2deb should convert package names to small letters

[Pirate Praveen]

package: npm2deb
version: 0.2.5-1
severity: important

When running npm2deb create JSONSelect it should create package as
node-jsonselect instead of node-JSONSelect.



signature.asc
Description: OpenPGP digital signature

Bug#840206: [Pkg-mozext-maintainers] Bug#840206: whonix-de...@whonix.org

[David Prévot]

Control: retitle -1 Please remove premium proxy advertising page
Control: severity wishlist

Thank you for your report.

Le 09/10/2016 à 05:05, ban...@openmailbox.org a écrit :
> Package: foxyproxy
> Version: 3.4-1.1

I assume this is still valid for 4.5.6-debian-2.

> Dear maintainer, please consider patching the package source to remove
> the premium proxy advertising page that opens on first start.

Regards

David




signature.asc
Description: OpenPGP digital signature

Bug#840152: rsyslog-gnutls: rsyslog+RELP+TLS=broken

[Michael Biebl]

Am 08.10.2016 um 23:35 schrieb Demetris Demetriou:
> Package: rsyslog-gnutls
> Version: 8.4.2-1+deb8u2, 8.16.0-1~bpo8+1
> Severity: important
> 
> Hello,
> 
> Debian 8.6 x64.
> 
> The jessie and jessie-backports rsyslog-gnutls packages are broken with 
> regards
> to TLS and RELP.




Can you share your complete configuration and would it be possible that
you try it with the latest version 8.22.0-1 from unstable?


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



signature.asc
Description: OpenPGP digital signature

Bug#840225: contributors.debian.org: unclaim email not working

[Sandro Knauß]

Package: nm.debian.org
Severity: normal

Hey,

currently I can't unclaim any email for my hefee-guest@alioth account, so
I can't add my previous work to my new DD identity. Nor can I claim
email addresses that are already claimed by my other account :(

Regards,

Sandro Knauß

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

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

Bug#840205: please turn libgcrypt11-dev into an Arch:any package

[Helmut Grohne]

Hi Andreas,

On Sun, Oct 09, 2016 at 06:18:45PM +0200, Andreas Metzler wrote:
> The second part of the changes does not really work (it expands to
> "libgcrypt20-dev (= 1.5.4-3+really1.7.3-2)") because libgcrypt11-dev
> has a different version number than the source package. As I do not see
> the point of tightening this dependency I have dropped this part of the
> change.

Thank you for not blindly applying my patches. Indeed, the major reason
to change the dependency was that arch:all packages cannot use
${binary:Version} at all, so I assumed that this was the reason for a
loose dependency without looking further. Thank you for catching that
mistake and pushing the relevant change to the archive quickly.

Helmut