date:20171112

Bug#879718: aptly: Aptly can't handle deb packages built using dpkg 1.19.0+

2017-11-12 Thread Sébastien Delafond

On Nov/11, Boyuan Yang wrote:
> However, aptly in Stretch and Jessie are still left unfixed. Will you
> backport the patch and provide stable updates later?

It's already in stretch-backports, but I don't plan on doing
jessie-backports.

Cheers,

--Seb

Bug#877364: pjproject: source file licensed as BSD-4-clause and GPL-2+ effectively unlicensed

2017-11-12 Thread Bernhard Schmidt

Control: tags -1 fixed-upstream
Control: forwarded -1 https://trac.pjsip.org/repos/ticket/2062

On Mon, Nov 06, 2017 at 01:27:38PM +0100, Bernhard Schmidt wrote:

> > > The file pjlib/src/pj/sock_linux_kernel.c is licensed as both
> > > BSD-4-clause and GPL-2+. Not dual-licensed, but separately declared.
> > > Those licenses are incompatible, and therefore the licensing is useless.
> > 
> > I'm far from being a license expert, so thanks for looking into this.
> > 
> > I have forwarded this to the upstream mailinglist.
> 
> No answer yet from the devs, I'll keep pushing.

According to upstream this is dead code [1] and has been removed for the
next upstream version.

Bernhard

[1]
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2017-November/020323.html

Bug#881493: [3dprinter-general] Bug#881493: libsavitar FTBFS on !amd64: symbol differences

2017-11-12 Thread Gregor Riepl

Thanks for reporting, I'll add/mark those symbols ASAP.

Bug#876934: openorienteering-mapper FTBFS: test failures

2017-11-12 Thread Kai Pastor


v0.7.92 hopefully fixes the FTBFS in the reproducible builds environment.

v0.7.92+2 (cd0aed9) might fix reproducibility. (At least, v0.7.92+1 
deals with the time stamp in the help collection.)


Kai.

Bug#881581: python3-pyqt5: PyQt5 Leaks memory on dereference of QStyleOptionTab

2017-11-12 Thread Jay Kamat

Package: python3-pyqt5
Version: 5.7+dfsg-5
Severity: normal

Dear Maintainer,


The version of PyQt5 in the Debian stretch archives seems to leak memory on 
deference of a QStyleOptionTab.

I have created a simple python file to reproduce the issue:

import resource
from PyQt5.QtWidgets import QStyleOptionTab
import tracemalloc

before = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(before)

opt = QStyleOptionTab()

for i in range(1000):
a = opt.rect

after = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(after)

if after > before + 1:
print("you seem to be leaking memory?")
else:
print("you're probably fine...")

On a normal system, this snippet should print "you're probably fine...",
but on debian stable it prints "you seem to be leaking memory?".

This issue also affects fedora25.

Is it possible that a patch could be prepared for this, or is it too
late for that in stable now? I think this has been fixed in testing, but
I have not verified it.

Here is the original issue where I found and debugged the problem:
https://github.com/qutebrowser/qutebrowser/issues/3280

This currently affects:

- Debian Stable
- Ubuntu zesty
- Fedora 25

And curiously, the 5.7.1 PyQt5 on pypi does not suffer from this.

Please let me know if you need any additional information.

-Jay

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

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

Versions of packages python3-pyqt5 depends on:
ii  libc62.24-11+deb9u1
ii  libgcc1  1:6.3.0-18
ii  libpython3.5 3.5.3-1
ii  libqt5core5a [qtbase-abi-5-7-1]  5.7.1+dfsg-3+b1
ii  libqt5dbus5  5.7.1+dfsg-3+b1
ii  libqt5designer5  5.7.1-1
ii  libqt5gui5   5.7.1+dfsg-3+b1
ii  libqt5help5  5.7.1-1
ii  libqt5network5   5.7.1+dfsg-3+b1
ii  libqt5printsupport5  5.7.1+dfsg-3+b1
ii  libqt5test5  5.7.1+dfsg-3+b1
ii  libqt5widgets5   5.7.1+dfsg-3+b1
ii  libqt5xml5   5.7.1+dfsg-3+b1
ii  libstdc++6   6.3.0-18
ii  python3  3.5.3-1
ii  python3-sip [sip-py3api-11.3]4.18.1+dfsg-2

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information

Bug#881536: ffmpeg: Breaks sound in kodi

2017-11-12 Thread Viktor Malyarchuk

Hi James,

just want to confirm that

gcc -shared shim.c -olibshim.so
LD_PRELOAD=$(pwd)/libshim.so kodi-standalone

indeed fixed the audio problem with kodi.

Best regards,
Viktor Malyarchuk

Bug#881580: googleearth-package: Generated package is uninstallable, and application unrunnable

2017-11-12 Thread Dima Kogan

Package: googleearth-package
Version: 1.2.2dima1
Severity: grave

Hi. I'm installing googleearth on a recent Debian/sid on amd64. Clearly
I need to have the i386 foreign arch enabled. It'd be nice if the
install explicitly told unsuspecting users this, but whatever.

The generated package Depends:lbs-core even though this package is no
longer a part of Debian. Removing this, I can make a googleearth package
that I can install.

At that point I can't run the application though. To make it work, I
needed to

1. install libqtcore4:i386 libqtgui4:i386 libqt4-network:i386 libqtwebkit4:i386 
libglu1-mesa:i386
   This list is likely incomplete; it's just what I was missing

2. The i386 linker the application requires is /lib/ld-lsb.so.3. This
   presumably lived in lsb-core at one point, but it no longer does. I
   can fake it with

 sudo ln -fs /lib/ld-linux.so.2 /lib/ld-lsb.so.3

Then I can run googleearth. I'm not sure what the best way is to provide
the linker. Is this worth fixing? Is there some other googleearth build
that we should be using instead?

Bug#881579: RM: uwsgi-plugin-php [arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x] -- NBS; binary package moved to src:uwsgi-plugin-php

2017-11-12 Thread Adrian Bunk

Package: ftp.debian.org
Severity: normal

The uwsgi-plugin-php binary package moved from
src:uwsgi to src:uwsgi-plugin-php.

src:uwsgi has a higher version than src:uwsgi-plugin-php
(the versions of the binary packages are correct),
resulting in src:uwsgi-plugin-php not bring built as long
as the old binaries are still around:
https://buildd.debian.org/status/package.php?p=uwsgi-plugin-php

Bug#881578: watcher: Wrong encoding in Portuguese debconf translation

2017-11-12 Thread Christian Perrier

Source: watcher
Severity: normal
Tags: l10n

The Portuguese translaiton of debconf messages sent in #876177 claims
to be UTF-8 encoded while it is indeed ISO-8859-1.

Please find attached to the report a fixed version of this file.


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# watcher debconf portuguese messages
# Copyright (C) 2013 THE Watcher COPYRIGHT HOLDER
# This file is distributed under the same license as the watcher package.
# Pedro Ribeiro , 2013-2014, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: watcher_0.30.0-5\n"
"Report-Msgid-Bugs-To: watc...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 12:24+\n"
"PO-Revision-Date: 2017-09-11 10:27+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid "Set up a database for Watcher?"
msgstr "Configurar uma base de dados para o Watcher?"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"No database has been set up for Watcher to use. Before continuing, you "
"should make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para uso do Watcher. Antes de "
"continuar, deve certificar-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que deseja usar;\n"
" * o nome da máquina do servidor da base de dados (que tem que permitir\n"
"ligações TCP a partir desta máquina);\n"
" * um nome de utilizador e palavra-passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se não tem alguns destes requisitos, não escolha esta opção e corra com "
"suporte SQLite normal."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"watcher\"."
msgstr ""
"Pode mudar esta definição mais tarde executando \"dpkg-reconfigure -plow "
"watcher\"."

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Por favor especifique o nome de máquina do servidor de autenticação. "
"Tipicamente este é também o nome de máquina do Serviço de Identidade "
"OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do inquilino ('tenant') do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique por favor o nome 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador do servidor de autenticação:"

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique por favor o nome de

Bug#864642: Effects Vanilla images as well

2017-11-12 Thread Dennis Downs III

I experienced this problem running a minecraft server on in a VM. The
server would stay up until shortly after joining it in game. After <5min
i'd lose connection. The virtual console would freeze, with no new messages
on either linux or java consoles. VMWare resource monitoring indicated that
the system had stopped completely. Following others example, I changed the
nic type from from vmxnet3 to E1000e. This also solved the issue for me.
I'm a linux novice but can follow instructions well. If there's any more
info I can provide, let me know.

Host:
Image profile ESXi-6.5.0-20170104001-standard (VMware, Inc.)
vSphere HA state Not configured
Manufacturer Dell Inc.
Model PowerEdge R510
CPU 8 CPUs x Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
Memory 63.99 GB
Virtual flash 0 B used, 0 B capacity

Guest:
Ubuntu Server 17.04
CPU 2 vCPUs
Memory 4 GB
Hard disk  16 GB
VMWare Tools installed and running

Bug#881577: libmagics++-dev: cmake files require libraries without package dependency

2017-11-12 Thread Adrian Bunk

Package: libmagics++-dev
Version: 2.34.3-4
Severity: serious
Control: affects -1 src:metview

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/metview.html

...
/usr/bin/ld: cannot find -lOdb_fortran
/usr/bin/ld: cannot find -lOdb
/usr/bin/ld: cannot find -leckit
/usr/bin/ld: cannot find -leckit_geometry
/usr/bin/ld: cannot find -leckit_linalg
/usr/bin/ld: cannot find -leckit_maths
/usr/bin/ld: cannot find -leckit_web
/usr/bin/ld: cannot find -leckit_cmd
/usr/bin/ld: cannot find -lmetkit
collect2: error: ld returned 1 exit status
src/uPlot/CMakeFiles/uPlot.dir/build.make:3405: recipe for target 'bin/uPlot' 
failed
make[3]: *** [bin/uPlot] Error 1


The libraries at the commandline seem to come from
/usr/lib/x86_64-linux-gnu/cmake/magics/magics-*

Bug#794138: reopening 794138

2017-11-12 Thread Petter Reinholdtsen

[Helmut Grohne]
> I'm sorry and stand corrected. Thank you for insisting. The patch is
> applied in git and in unstable.

No worries.  Then I know we talk about the same thing.  No need to
apology.

> The problem now is: Someone added the check target to dh_auto_build
> for running tests. Now tests are run even when DEB_BUILD_OPTIONS
> contains nocheck. Typically test suites fail during cross compilation
> with an expected "Exec format error", which is why cross builds set
> nocheck.  That's what happens for startpar. Simply removing check from
> dh_auto_build is ok, because dh_auto_test (which honours the nocheck
> setting) correctly detects the check target and runs it. I hope this
> is correct or do we need to pass EXTRACFLAGS and friends to
> dh_auto_test now?

I added this in 2014, to ensure it was impossible for a autobuilder to
build a package that did not handle the test suite, to avoid ending up
with unbootable systems on some of the less used architectures.  I
believe this is an important safety fuse in the build system.  As long
as the default build will run the check, I am fine with the change.

> diff --minimal -Nru startpar-0.59/debian/changelog 
> startpar-0.59/debian/changelog
> --- startpar-0.59/debian/changelog2017-11-07 00:17:03.0 +0100
> +++ startpar-0.59/debian/changelog2017-11-12 14:00:14.0 +0100
> @@ -1,3 +1,10 @@
> +startpar (0.59-3.3) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Do not run tests when DEB_BUILD_OPTIONS contains nocheck. (Closes: #-1)
> +
> + -- Helmut Grohne   Sun, 12 Nov 2017 14:00:14 +0100
> +
>  startpar (0.59-3.2) unstable; urgency=medium

If dh_auto_test now run 'make check' automatically, can you figure out
which version of it started doing this, and update the build
dependencies, to ensure it still is impossible to build the source
without checking that it work?

-- 
Happy hacking
Petter Reinholdtsen

Bug#881576: cross-toolchain-base-ports: add mipsn32 and mips r6 support

2017-11-12 Thread YunQiang Su

Package: src:cross-toolchain-base-ports
Version: 12
Control: block -1 by 881147 881454 881455 881457 881575

Please add mips n32 and mips r6 support to cross-toolchain-base-ports.
As we need to add the support to glibc and gcc-6,
so this bug is blocked by them.

-- 
YunQiang Su
diff --git a/debian/kernelarch.make b/debian/kernelarch.make
index a76c9ab..252d731 100644
--- a/debian/kernelarch.make
+++ b/debian/kernelarch.make
@@ -13,8 +13,16 @@ KERNEL_ARCH_m68k:=m68k
 KERNEL_ARCH_hppa:=parisc
 KERNEL_ARCH_mips:=mips
 KERNEL_ARCH_mipsel:=mips
+KERNEL_ARCH_mipsn32:=mips
+KERNEL_ARCH_mipsn32el:=mips
 KERNEL_ARCH_mips64:=mips
 KERNEL_ARCH_mips64el:=mips
+KERNEL_ARCH_mipsr6:=mips
+KERNEL_ARCH_mipsr6el:=mips
+KERNEL_ARCH_mipsn32r6:=mips
+KERNEL_ARCH_mipsn32r6el:=mips
+KERNEL_ARCH_mips64r6:=mips
+KERNEL_ARCH_mips64r6el:=mips
 KERNEL_ARCH_powerpc:=powerpc
 KERNEL_ARCH_powerpcspe:=powerpc
 KERNEL_ARCH_ppc64:=powerpc
diff --git a/debian/rules b/debian/rules
index 4119604..e480308 100755
--- a/debian/rules
+++ b/debian/rules
@@ -37,7 +37,8 @@ ifeq ($(DEB_NAME_ACT),cross-toolchain-base)
 else
   CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc ppc64 sh4 sparc64 \
$(if $(filter $(vendor), Ubuntu), mips mipsel mips64el) 
\
-   powerpcspe
+   powerpcspe mipsn32 mipsn32el \
+   mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el
 endif
 CROSS_ARCH   = $(subst .,,$(suffix $@))
 KERNEL_ARCH  = $(KERNEL_ARCH_$(CROSS_ARCH))
@@ -273,13 +274,19 @@ endif
  dpkg-deb -x 
lib64gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH} \
)
-   $(if $(filter $(CROSS_ARCH),mips mipsel), \
+   $(if $(filter $(CROSS_ARCH),mips mipsel mipsr6 mipsr6el), \
  dpkg-deb -x 
lib64gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH}; \
  dpkg-deb -x 
libn32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH} \
)
-   $(if $(filter $(CROSS_ARCH),mips64 mips64el), \
+   $(if $(filter $(CROSS_ARCH),mipsn32 mipsn32el mipsn32r6 mipsn32r6el), \
+ dpkg-deb -x 
lib64gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
+   debian/tmp.${CROSS_ARCH}; \
+ dpkg-deb -x 
lib32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
+   debian/tmp.${CROSS_ARCH} \
+   )
+   $(if $(filter $(CROSS_ARCH),mips64 mips64el mips64r6 mips64r6el), \
  dpkg-deb -x 
lib32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH}; \
  dpkg-deb -x 
libn32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
@@ -343,7 +350,7 @@ endif
  dpkg-deb -x 
lib64gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH} \
)
-   $(if $(filter $(CROSS_ARCH),mips mipsel), \
+   $(if $(filter $(CROSS_ARCH),mips mipsel mipsr6 mipsr6el), \
  dpkg-deb -x lib64gcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH}; \
  dpkg-deb -x 
lib64gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
@@ -353,7 +360,17 @@ endif
  dpkg-deb -x 
libn32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH} \
)
-   $(if $(filter $(CROSS_ARCH),mips64 mips64el), \
+   $(if $(filter $(CROSS_ARCH),mipsn32 mipsn32el mipsn32r6 mipsn32r6el), \
+ dpkg-deb -x lib64gcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
+   debian/tmp.${CROSS_ARCH}; \
+ dpkg-deb -x 
lib64gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
+   debian/tmp.${CROSS_ARCH}; \
+ dpkg-deb -x lib32gcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
+   debian/tmp.${CROSS_ARCH}; \
+ dpkg-deb -x 
lib32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
+   debian/tmp.${CROSS_ARCH} \
+   )
+   $(if $(filter $(CROSS_ARCH),mips64 mips64el mips64r6 mips64r6el), \
  dpkg-deb -x lib32gcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
debian/tmp.${CROSS_ARCH}; \
  dpkg-deb -x 
lib32gcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
@@ -437,11 +454,15 @@ endif
$(if $(filter $(CROSS_ARCH),powerpc), \
  dpkg-deb -x libc6-dev-ppc64_${DEB_VER_GLIBC}_${CROSS_ARCH}.deb 
debian/tmp.${CROSS_ARCH} \
)
-   $(if $(filter $(CROSS_ARCH),mips mipsel), \
+   $(if $(filter $(CROSS_ARCH),mips mipsel mipsr6 mipsr6el), \
  dpkg-deb -x libc6-dev-mips64_${DEB_VER_GLIBC}_${CROSS_ARCH}.deb 
debian/tmp.${CROSS_ARCH}; \
  dpkg-deb -x libc6-dev-mipsn32_${DEB_VER_GLIBC}_${CROSS_ARCH}.deb

Bug#881574: debconf: Please Break: update-notifier-common (<< 3.187) for Ubuntu compatibility

2017-11-12 Thread Steve Langasek

Package: debconf
Version: 1.5.64
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hi Colin,

debconf 1.5.64 has stalled in bionic-proposed, in part because the
update-notifier autopkgtests correctly detect that update-notifier is broken
by the removal of debconf.py.

I have uploaded update-notifier to bionic to add the necessary dependency on
python3-debconf, and I have also uploaded debconf to declare a Breaks:
against previous versions of update-notifier-common.

Please consider adding this Breaks: in Debian as well, even though
update-notifier is not in Debian more recently than oldstable.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru debconf-1.5.64/debian/control debconf-1.5.64ubuntu2/debian/control
--- debconf-1.5.64/debian/control   2017-10-15 03:44:37.0 -0700
+++ debconf-1.5.64ubuntu2/debian/control2017-11-12 21:04:37.0 
-0800
@@ -14,7 +14,7 @@
 Priority: important
 Pre-Depends: perl-base (>= 5.20.1-3~)
 Conflicts: cdebconf (<< 0.96), debconf-tiny, apt (<< 0.3.12.1), menu (<= 
2.1.3-1), dialog (<< 0.9b-20020814-1), whiptail (<< 0.51.4-11), whiptail-utf8 
(<= 0.50.17-13), debconf-utils (<< 1.3.22)
-Breaks: apt-listchanges (<< 3.14), ubiquity (<< 17.10.2)
+Breaks: apt-listchanges (<< 3.14), ubiquity (<< 17.10.2), 
update-notifier-common (<< 3.187~)
 Provides: debconf-2.0
 Replaces: debconf-tiny
 Depends: ${misc:Depends}

Bug#881575: gcc-6: add mips r6 support

2017-11-12 Thread YunQiang Su

Package: src:gcc-6
Version: 6.4.0-9

Please add mips r6 support to gcc-6, and it also contains a little fix
for mipsn32.

This patch also works with gcc-7 with a little modification.
I will submit for gcc-7 soon.

-- 
YunQiang Su
diff --git a/debian/libstdc++6.symbols.mips64r6 
b/debian/libstdc++6.symbols.mips64r6
new file mode 100644
index 000..7aa71da
--- /dev/null
+++ b/debian/libstdc++6.symbols.mips64r6
@@ -0,0 +1,7 @@
+libstdc++.so.6 libstdc++6 #MINVER#
+#include "libstdc++6.symbols.64bit"
+#include "libstdc++6.symbols.128bit"
+#include "libstdc++6.symbols.excprop"
+#include "libstdc++6.symbols.money.ldbl"
+ _ZN9__gnu_cxx12__atomic_addEPVii@GLIBCXX_3.4 4.1.1
+ _ZN9__gnu_cxx18__exchange_and_addEPVii@GLIBCXX_3.4 4.1.1
diff --git a/debian/libstdc++6.symbols.mips64r6el 
b/debian/libstdc++6.symbols.mips64r6el
new file mode 100644
index 000..fcc4963
--- /dev/null
+++ b/debian/libstdc++6.symbols.mips64r6el
@@ -0,0 +1,10 @@
+libstdc++.so.6 libstdc++6 #MINVER#
+#include "libstdc++6.symbols.64bit"
+#include "libstdc++6.symbols.128bit"
+#include "libstdc++6.symbols.excprop"
+#include "libstdc++6.symbols.glibcxxmath"
+#include "libstdc++6.symbols.money.ldbl"
+ _ZN9__gnu_cxx12__atomic_addEPVii@GLIBCXX_3.4 4.1.1
+ _ZN9__gnu_cxx18__exchange_and_addEPVii@GLIBCXX_3.4 4.1.1
+ _ZNKSt3tr14hashIeEclEe@GLIBCXX_3.4.10 4.9.0
+ _ZNKSt4hashIeEclEe@GLIBCXX_3.4.10 4.9.0
diff --git a/debian/libstdc++6.symbols.mipsr6 b/debian/libstdc++6.symbols.mipsr6
new file mode 100644
index 000..885c8d1
--- /dev/null
+++ b/debian/libstdc++6.symbols.mipsr6
@@ -0,0 +1,7 @@
+libstdc++.so.6 libstdc++6 #MINVER#
+#include "libstdc++6.symbols.32bit"
+ __gxx_personality_v0@CXXABI_1.3 4.1.1
+#include "libstdc++6.symbols.excprop"
+#include "libstdc++6.symbols.glibcxxmath"
+ _ZNKSt3tr14hashIeEclEe@GLIBCXX_3.4.10 4.3.0
+ _ZNKSt4hashIeEclEe@GLIBCXX_3.4.10 4.3.0
diff --git a/debian/libstdc++6.symbols.mipsr6el 
b/debian/libstdc++6.symbols.mipsr6el
new file mode 100644
index 000..70ed99b
--- /dev/null
+++ b/debian/libstdc++6.symbols.mipsr6el
@@ -0,0 +1,8 @@
+libstdc++.so.6 libstdc++6 #MINVER#
+#include "libstdc++6.symbols.32bit"
+ __gxx_personality_v0@CXXABI_1.3 4.1.1
+#include "libstdc++6.symbols.excprop"
+#include "libstdc++6.symbols.glibcxxmath"
+#include "libstdc++6.symbols.money.ldbl"
+ _ZNKSt3tr14hashIeEclEe@GLIBCXX_3.4.10 4.3.0
+ _ZNKSt4hashIeEclEe@GLIBCXX_3.4.10 4.3.0
diff --git a/debian/rules.conf b/debian/rules.conf
index a34bed7..2c2c0a2 100644
--- a/debian/rules.conf
+++ b/debian/rules.conf
@@ -284,7 +284,12 @@ LIBC_DEV_DEP := $(LIBC_DEP)-dev
 # this is about Debian archs name, *NOT* GNU target triplet
 biarch_deb_map := \
i386=amd64 amd64=i386 \
-   mips=mips64 mipsel=mips64 \
+   mips=mips64 mipsel=mips64el \
+   mipsn32=mips mipsn32el=mipsel \
+   mips64=mips mips64el=mipsel \
+   mipsr6=mips64r6 mipsr6el=mips64r6el \
+   mipsn32r6=mipsr6 mipsn32r6el=mipsr6el \
+   mips64r6=mipsr6 mips64r6el=mipsr6el \
powerpc=ppc64 ppc64=powerpc \
sparc=sparc64 sparc64=sparc\
s390=s390x s390x=s390 \
@@ -312,7 +317,7 @@ ifneq (,$(findstring yes,$(biarch64) $(biarch32) 
$(biarchn32) $(biarchx32)$(biar
   endif
   endif
   # mips*
-  ifneq (,$(findstring $(DEB_TARGET_ARCH),mips mipsel mipsn32 mipsn32el mips64 
mips64el))
+  ifneq (,$(findstring $(DEB_TARGET_ARCH),mips mipsel mipsn32 mipsn32el mips64 
mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el))
   ifeq ($(biarchn32)$(biarch32),yesyes)
   LIBC_BIARCH_DEV_DEP := libc6-dev-mips32$(LS)$(AQ) (>= $(libc_ver)), 
libc6-dev-mipsn32$(LS)$(AQ) (>= $(libc_ver))
   endif
@@ -352,7 +357,7 @@ ifneq ($(DEB_CROSS),yes)
   ifeq (,$(filter $(distrelease),lenny etch squeeze dapper hardy jaunty karmic 
lucid maverick natty oneiric))
 LIBC_BUILD_DEP += , libc6-dev (>= 2.13-31) [armel armhf]
   endif
-  LIBC_BIARCH_BUILD_DEP = libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 
[sparc], libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x 
[s390], libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 
[powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc1 [amd64 ppc64 
kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el s390x sparc64 x32], libn32gcc1 
[mips mipsel mips64 mips64el], lib64gcc1 [i386 mips mipsel mipsn32 mipsn32el 
powerpc sparc s390 x32], libc6-dev-mips64 [mips mipsel mipsn32 mipsn32el], 
libc6-dev-mipsn32 [mips mipsel mips64 mips64el], libc6-dev-mips32 [mipsn32 
mipsn32el mips64 mips64el],
+  LIBC_BIARCH_BUILD_DEP = libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 
[sparc], libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x 
[s390], libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 
[powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc1 [amd64 ppc64 
kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el s390x sparc64 x32], libn32gcc1 [mips mipsel mips64 mips64el mipsr6 
mipsr6el mips64r6 mips64r6el], lib64gcc1 [i386

Bug#881573: scala FTBFS: A class needed by class class org.eclipse.aether.internal.ant.types.RemoteRepository cannot be found: org/codehaus/plexus/logging/AbstractLogEnabled

2017-11-12 Thread Adrian Bunk

Source: scala
Version: 2.11.8-2
Severity: serious

Some recent change in unstable makes scala FTBFS:

https://tests.reproducible-builds.org/debian/history/scala.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/scala.html

...
BUILD FAILED
/build/1st/scala-2.11.8/build.xml:117: The following error occurred while 
executing this line:
/build/1st/scala-2.11.8/build-ant-macros.xml:8: The following error occurred 
while executing this line:
/build/1st/scala-2.11.8/build.xml:269: Type urn:maven-artifact-ant:remoterepo: 
A class needed by class class 
org.eclipse.aether.internal.ant.types.RemoteRepository cannot be found: 
org/codehaus/plexus/logging/AbstractLogEnabled

Total time: 2 seconds
debian/rules:12: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1

Bug#881572: sikulix FTBFS: error: package com.melloware.jintellitype does not exist

2017-11-12 Thread Adrian Bunk

Source: sikulix
Version: 1.1.1-5
Severity: serious

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

...
11 errors
5 warnings
[[1;34mINFO[m] 
[1m[m
[[1;34mINFO[m] [1mReactor Summary:[m
[[1;34mINFO[m] 
[[1;34mINFO[m] sikulix1 ... 
[1;32mSUCCESS[m [  0.763 s]
[[1;34mINFO[m] sikulixlibslux . 
[1;32mSUCCESS[m [  1.294 s]
[[1;34mINFO[m] sikulixapi . 
[1;31mFAILURE[m [  5.370 s]
[[1;34mINFO[m] sxjygments . 
[1;33mSKIPPED[m
[[1;34mINFO[m] sikulix  
[1;33mSKIPPED[m
[[1;34mINFO[m] 
[1m[m
[[1;34mINFO[m] [1;31mBUILD FAILURE[m
[[1;34mINFO[m] 
[1m[m
[[1;34mINFO[m] Total time: 7.778 s
[[1;34mINFO[m] Finished at: 2017-11-13T01:14:44Z
[[1;34mINFO[m] Final Memory: 14M/217M
[[1;34mINFO[m] 
[1m[m
[[1;31mERROR[m] Failed to execute goal 
[32morg.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:jar[m 
[1m(default-cli)[m on project [36msikulixapi[m: 
[1;31mMavenReportException: Error while generating Javadoc: [m
[[1;31mERROR[m] [1;31mExit code: 1 - 
/<>/API/src/main/java/org/sikuli/basics/WindowsHotkeyManager.java:8:
 error: package com.melloware.jintellitype does not exist[m
[[1;31mERROR[m] [1;31mimport com.melloware.jintellitype.JIntellitype;[m
[[1;31mERROR[m] [1;31m ^[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/basics/WindowsHotkeyManager.java:26:
 error: package com.melloware.jintellitype does not exist[m
[[1;31mERROR[m] [1;31m  class JIntellitypeHandler implements 
com.melloware.jintellitype.HotkeyListener {[m
[[1;31mERROR[m] [1;31m   
  ^[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/script/RunTime.java:320: 
warning - @return tag has no arguments.[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/script/RunTime.java:332: 
warning - @return tag has no arguments.[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/script/RunTime.java:349: 
warning - @return tag has no arguments.[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/script/Sikulix.java:223: 
warning - @return tag has no arguments.[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:9: error: 
package org.bridj does not exist[m
[[1;31mERROR[m] [1;31mimport org.bridj.BridJ;[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:10: 
error: package org.bridj does not exist[m
[[1;31mERROR[m] [1;31mimport org.bridj.Pointer;[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:11: 
error: package org.bridj.ann does not exist[m
[[1;31mERROR[m] [1;31mimport org.bridj.ann.Library;[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:21: 
error: cannot find symbol[m
[[1;31mERROR[m] [1;31m  @Library("kernel32")[m
[[1;31mERROR[m] [1;31m   ^[m
[[1;31mERROR[m] [1;31m  symbol:   class Library[m
[[1;31mERROR[m] [1;31m  location: class SysJNA[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:35: 
error: cannot find symbol[m
[[1;31mERROR[m] [1;31mPointer lpName,[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] [1;31m  symbol:   class Pointer[m
[[1;31mERROR[m] [1;31m  location: class WinKernel32[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:36: 
error: cannot find symbol[m
[[1;31mERROR[m] [1;31mPointer lpBuffer,[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] [1;31m  symbol:   class Pointer[m
[[1;31mERROR[m] [1;31m  location: class WinKernel32[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:46: 
error: cannot find symbol[m
[[1;31mERROR[m] [1;31mPointer lpName,[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] [1;31m  symbol:   class Pointer[m
[[1;31mERROR[m] [1;31m  location: class WinKernel32[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:47: 
error: cannot find symbol[m
[[1;31mERROR[m] [1;31mPointer lpValue[m
[[1;31mERROR[m] [1;31m^[m
[[1;31mERROR[m] [1;31m  symbol:   class Pointer[m
[[1;31mERROR[m] [1;31m  location: class WinKernel32[m
[[1;31mERROR[m] 
[1;31m/<>/API/src/main/java/org/sikuli/util/SysJNA.java:86:

Bug#880990: Qualify for Natural Pain Relief! See How th

2017-11-12 Thread Debbie Myers

Stop

On Nov 11, 2017 12:13 PM, "Living With Pain"  wrote:

> Welcome To LivingWithPain.org
>
> 
>
> 
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Your message dated Sat, 11 Nov 2017 19:38:55 +0100 with message-id and
> subject line Re: Bug#880990: widelands: Segmentation fault on loading a
> game has caused the Debian Bug report #880990, regarding widelands:
> Segmentation fault on loading a game to be marked as done. This means that
> you claim that the problem has been dealt with. If this is not the case it
> is now your responsibility to reopen the Bug report if necessary, and/or
> fix the problem forthwith. (NB: If you are a system administrator and have
> no idea what this message is talking about, this may indicate a serious
> mail system misconfiguration somewhere. Please contact
> ow...@bugs.debian.org immediately.) -- 880990:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880990 Debian Bug
> Tracking System Contact ow...@bugs.debian.org with problems
>
> -- Forwarded message --
> From: "Elena ``of Valhalla''" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 06 Nov 2017 19:25:27 +0100
> Subject: widelands: Segmentation fault on loading a game
> Package: widelands
> Version: 1:19+repack-4
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> I have installed widelands on a buster amd64 system and found the sad
> surprise that it is no longer working: opening any game (tutorial,
> campaign or game) results in a segfault with the attached output.
> I didn't try multiplayer games.
>
> Originally I tried with an existing ~/.widelands directory, but I moved
> it away and could still reproduce the behaviour.
>
> Please let me know if there is any other information I can provide: I
> have all of the free time saved by not playing widelands that I can use
> to help investigate this issue :)
>
> The following are the last few lines of ``strace widelands``:
>
> [ENOENT on files in ~/.widelands as far as my eyesbdwabacklog can see]
> 
> stat("/usr/share/games/widelands/data/world/critters/fox/fox_walk_nw_20.png",
> 0x7ffe463be940) = -1 ENOENT (No such file or directory)
> stat("/home/valhalla/.widelands/sound/animals", 0x7ffe463be220) = -1
> ENOENT (No such file or directory)
> stat("/usr/share/games/widelands/data/sound/animals",
> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> open("/home/valhalla/.widelands/sound/animals", 
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
> = -1 ENOENT (No such file or directory)
> open("/usr/share/games/widelands/data/sound/animals",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 18
> fstat(18, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> getdents(18, /* 46 entries */, 32768)   = 1488
> getdents(18, /* 0 entries */, 32768)= 0
> close(18)   = 0
> stat("/home/valhalla/.widelands/sound/animals/coyote_01.ogg",
> 0x7ffe463be170) = -1 ENOENT (No such file or directory)
> stat("/usr/share/games/widelands/data/sound/animals/coyote_01.ogg",
> {st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
> stat("/usr/share/games/widelands/data/sound/animals/coyote_01.ogg",
> {st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
> open("/usr/share/games/widelands/data/sound/animals/coyote_01.ogg",
> O_RDONLY) = 18
> fstat(18, {st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
> fstat(18, {st_mode=S_IFREG|0644, st_size=29348, ...}) = 0
> lseek(18, 28672, SEEK_SET)  = 28672
> read(18, 
> "\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"...,
> 676) = 676
> lseek(18, 0, SEEK_SET)  = 0
> read(18, 
> "OggS\0\2\0\0\0\0\0\0\0\0\320S(t\0\0\0\0006~\352\315\1\36\1vor"...,
> 28672) = 28672
> read(18, 
> "\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"...,
> 4096) = 676
> close(18)   = 0
> brk(0x55fb3b0f8000) = 0x55fb3b0f8000
> mmap(NULL, 33329152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x7f5e59837000
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0x7ffe463c5000} ---
> +++ killed by SIGSEGV +++
> Segmentation fault
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
> Locale:

Bug#881564: u-boot: please add a64-olinuxino target to [arm64] u-boot-sunxi binary package

2017-11-12 Thread Jonas Smedegaard

Quoting Vagrant Cascadian (2017-11-13 04:09:11)
> On 2017-11-12, Vagrant Cascadian wrote:
> > On 2017-11-12, Jonas Smedegaard wrote:
> >> I own a TERES-I and can offer to test
> ...
> > so I can build and upload a package somewhere for you to test before
> > uploading to Debian, if you'd rather.
> 
>   deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
> 
> Should have a u-boot-sunxi:arm64 package with a64-olinuxino enabled, and
> /usr/share/doc/u-boot-sunxi/README.* describing what's needed to install
> u-boot.

Thanks.  Will test first thing tomorrow.

I already compiled arm-trusted-firmware - and will probably package that 
for Debian, as it seems noone else is planning to do that (yes, I am 
aware a sunxi-specific fork is needed currently).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#881570: linux-image-4.14.0-rc7-armmp-lpae: please enable DRM_SUN4I_HDMI_CEC

2017-11-12 Thread Jonas Smedegaard

Package: src:linux
Version: 4.14~rc7-1~exp1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Kernel 4.14 introduces support for HDMI CEC support for Allwinner A10/A20
SoC.

Please enable that - it should be DRM_SUN4I_HDMI_CEC (which I guess need
DRM_SUN4I enabled too).


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloJEzcACgkQLHwxRsGg
ASErsQ/9FrlJikZTdHkZvMVnTLxGSPgEsUulz3BjbBrE7SnqjQTEH9yp+t4YVt2n
qQKg8/T52CEp+rp0fW66hef90owE31ptfZE/hzQeP3h44utCmbFX5b2msrItVkZR
TRqEyCER7oSG59EQF8RoCiJ6/qeqLWsh6pVBxBCmud7oskh1j1NWCbKBRkwZnB4/
J1newkLSVhNFMyLCqZkdZMCPzZlOEPkZyBS7+H6Pj3EmwEusTIXNhoQKnYLpzDjM
2jGDFxh+YbnY+F9ggYMO2B1KvPBYwcSebm+PGgq4rgNoMlobuVYOG0X8y3C1E8st
ZZFMFJgdNrVjHDFgQNLw80sGRpzIG8ZjoZa94dDhItgzxRpmWG3cuGbIfaIc6Dl6
CPdxOSyEp7dife2udxlD+jzHKl6UoQ72xaKWyIWlZ85v39KaR/08Eq3kny8dOQcS
smHMEYIH6lAte3VYxpxbAve++mianhQ3WRwpIE6AGghpCryBwJCpL2XJajFmIZru
VXeQX6iLvVNd9jcHizIlZ4Mo+oSgTTGdgaq0q3pjIHHZtOCuWcd3xu9NuIGqJIbI
0tkffloNLOrJGXr7PlgeGLVohii4NjLanlYp0rVT/AcXjaUxR1Fpt7KbOlpohBO+
/u/k1s4tutaEtgjq9c3TJQTs6pKU4XNj1Hp+FW5aSycGLuzCRw8=
=RKr3
-END PGP SIGNATURE-

Bug#881564: u-boot: please add a64-olinuxino target to [arm64] u-boot-sunxi binary package

2017-11-12 Thread Jonas Smedegaard

Quoting Vagrant Cascadian (2017-11-13 03:29:33)
> On 2017-11-12, Jonas Smedegaard wrote:
>> Please build and include with binary arm64 package u-boot-sunxi the 
>> a64-olinuxino target, covering both the development board by that 
>> name and the TERES-I DIY laptop.
>>
>> I own a TERES-I and can offer to test
>
> Didn't know the TERES-I was 100% compatible; nice!

Seems so: Olimex use that dtb in the pre-installed system.

>> (but am not familiar with the packaging style of the u-boot source 
>> package (seems to not use common git-buildpackage style and no hints 
>> is provided in README.source), so I would prefer to leave to others 
>> to implement the change.
>
> Pretty standard package in some regards: dpkg-buildpackage, debuild, 
> sbuild, pbuilder should all work without any unusual incantations 
> (e.g. orig.tar.* in the upper directory). You will need 
> DEB_BUILD_PROFILES=cross if you want to cross-compile, and have the 
> appropriate (multi-arch) build dependencies installed... sbuild 
> generally does the right thing for me.

Right.  I meant git source maintenance style, however: Branches 
"upstream" and "pristine-tar" exist but apparently haven't been used for 
quite some time.

> Which... can be a bit of an adventure... and it also may need an 
> upstream version not yet uploaded to Debian... so I can build and 
> upload a package somewhere for you to test before uploading to Debian, 
> if you'd rather.
> 
> 
> This patch should do it, if you're willing to be listed as a tester:
> 
> diff --git a/debian/targets b/debian/targets
> index a35c559f77..c67a7a4adb 100644
> --- a/debian/targets
> +++ b/debian/targets
> @@ -176,6 +176,9 @@ arm64   qcomdragonboard410c u-boot.bin
>  # Ryan Finnie 
>  arm64  rpi rpi_3   u-boot.bin
>  
> +# Jonas Smedegaard 
> +arm64  sunxi   a64-olinuxino   u-boot.bin spl/sunxi-spl.bin 
> u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb
> +
>  # Vagrant Cascadian 
>  arm64  sunxi   pine64_plus u-boot.bin spl/sunxi-spl.bin 
> u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-plus.dtb 
> arch/arm/dts/sun50i-a64-pine64.dtb

Ah, so the names listed there are testers.  Makes sense.

Yes, Please do add me there as tester.

I already built a test package - with _exactly_ the same patch as above 
(and your last commit in git applied too - which does more than just 
update the documentation so you might want to adjust when applying to 
changelog).

Not tested yet, though - Will do that tomorrow (it is getting late now).

> Unfortunately, arm-trusted-firmware is not packaged for Debian, and 
> the allwinner boards require using a vendor fork, so you will need to 
> build that yourself. The process is roughly documented in 
> board/sunxi/README.sunxi64 and debian/u-boot-sunxi.README.Debian in 
> git.

Right: After fighting blindly with several (stupid, in hindsight) 
attempts I checked out u-boot git and noticed your commit the 9th which 
I hope is the final missing piece to boot a purely Debian system for my 
TERES-I.

> I've recently successfully tested the non-legacy process on a Pine64+, 
> which is similar hardware.

Yes, I noticed some of your changes for that, and appreciate all your 
work on that: Obviously makes it far easier to then adapt to similar 
devices.

Any chance you can make a release to Debian soon?

I would love to be able to run pure Debian on my laptop when showing off 
my TERES-I at MiniDebconf in France next weekend.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#881569: gdb: FTBFS on hurd-i386

2017-11-12 Thread Svante Signell

Source: gdb
Version: 8.0-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd, experimental

Hi,

gdb FTBFS on GNU/Hurd due to three reasons:

- Usage of PATH_MAX in gdb/remote.c

- Recent changes in Hurd failing the build of gdb/gnu-nat.c

- A name clash of struct thread_info and the kernel function thread_info()
included in gdb/thread.c and gdb/python/py-record-btrace.c.

Include paths:
1) defs.h: #include "gdbarch.h": struct thread_info

2) defs.h: #include "nm.h":#include :#include 
where the function thread_info() is defined:

extern kern_return_t thread_info
(
 mach_port_t target_thread,
 int flavor,
 thread_info_t thread_info_out,
 mach_msg_type_number_t *thread_info_outCnt
);

The attached patches fixes these issues:
gdb-PATH_MAX.patch
gnu-nat.c.patch
struct-thread_info.patch

Thanks :)Index: gdb-8.0/gdb/remote.c
===
--- gdb-8.0.orig/gdb/remote.c
+++ gdb-8.0/gdb/remote.c
@@ -6939,7 +6939,7 @@ Packet: '%s'\n"),
 	  else if (strprefix (p, p1, "exec"))
 	{
 	  ULONGEST ignored;
-	  char pathname[PATH_MAX];
+	  char *pathname = NULL;
 	  int pathlen;
 
 	  /* Determine the length of the execd pathname.  */
@@ -6948,12 +6948,14 @@ Packet: '%s'\n"),
 
 	  /* Save the pathname for event reporting and for
 		 the next run command.  */
+	  pathname = (char *) xmalloc(pathlen + 1);
 	  hex2bin (p1, (gdb_byte *) pathname, pathlen);
 	  pathname[pathlen] = '\0';
 
 	  /* This is freed during event handling.  */
 	  event->ws.value.execd_pathname = xstrdup (pathname);
 	  event->ws.kind = TARGET_WAITKIND_EXECD;
+	  xfree (pathname);
 
 	  /* Skip the registers included in this packet, since
 		 they may be for an architecture different from the
Index: gdb-8.0/gdb/gnu-nat.c
===
--- gdb-8.0.orig/gdb/gnu-nat.c
+++ gdb-8.0/gdb/gnu-nat.c
@@ -1869,22 +1869,28 @@ S_proc_wait_reply (mach_port_t reply, ke
   return 0;
 }
 
+/* Note: The third argument to S_proc_getmsgport_reply, S_proc_task2proc_reply and
+   S_proc_pid2proc_reply is of type mach_port_poly_t. Look at gdb/process_reply_S.h
+   derived from process_reply.defs to find out the fourth argument */
+
 ILL_RPC (S_proc_setmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 mach_port_t oldmsgport)
 ILL_RPC (S_proc_getmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
-	 mach_port_t msgports)
+	 mach_port_t msgports, mach_msg_type_name_t msgportsPoly)
 ILL_RPC (S_proc_pid2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_task2pid_reply,
 	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
 ILL_RPC (S_proc_task2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc,
+	 mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_proc2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_pid2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc,
+	 mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_getprocinfo_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,
@@ -2356,7 +2362,7 @@ gnu_write_inferior (task_t task, CORE_AD
   mach_msg_type_number_t copy_count;
   int deallocate = 0;
 
-  char *errstr = "Bug in gnu_write_inferior";
+  const char *errstr = "Bug in gnu_write_inferior";
 
   struct vm_region_list *region_element;
   struct vm_region_list *region_head = NULL;
@@ -2743,7 +2749,7 @@ show_thread_default_cmd (char *args, int
 }
 
 static int
-parse_int_arg (char *args, char *cmd_prefix)
+parse_int_arg (const char *args, const char *cmd_prefix)
 {
   if (args)
 {
@@ -2758,7 +2764,7 @@ parse_int_arg (char *args, char *cmd_pre
 }
 
 static int
-_parse_bool_arg (char *args, char *t_val, char *f_val, char *cmd_prefix)
+_parse_bool_arg (const char *args, const char *t_val, const char *f_val, const char *cmd_prefix)
 {
   if (!args || strcmp (args, t_val) == 0)
 return 1;
@@ -2774,7 +2780,7 @@ _parse_bool_arg (char *args, char *t_val
   _parse_bool_arg (args, "on", "off", cmd_prefix)
 
 static void
-check_empty (char *args, char *cmd_prefix)
+check_empty (const char *args, const char *cmd_prefix)
 {
   if (args)
 error (_("Garbage after \"%s\" command: `%s'"), cmd_prefix, args);
Index: gdb-8.0/gdb/thread.c
===
--- gdb-8.0.orig/gdb/thread.c
+++ gdb-8.0/gdb/thread.c
@@ -76,21 +76,21 @@ static void restore_current_thread (ptid
 class scoped_inc_dec_ref
 {
 public:
-  explicit scoped_inc_dec_ref (const std::vector )
+  explicit scoped_inc_dec_ref (const std::vector )
 :

Bug#881564: u-boot: please add a64-olinuxino target to [arm64] u-boot-sunxi binary package

2017-11-12 Thread Vagrant Cascadian

On 2017-11-12, Vagrant Cascadian wrote:
> On 2017-11-12, Jonas Smedegaard wrote:
>> I own a TERES-I and can offer to test
...
> so I can build and upload a package somewhere for you to test before
> uploading to Debian, if you'd rather.

  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main

Should have a u-boot-sunxi:arm64 package with a64-olinuxino enabled, and
/usr/share/doc/u-boot-sunxi/README.* describing what's needed to install
u-boot.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#881564: u-boot: please add a64-olinuxino target to [arm64] u-boot-sunxi binary package

2017-11-12 Thread Vagrant Cascadian

Control: tags 881564 +patch

On 2017-11-12, Jonas Smedegaard wrote:
> Please build and include with binary arm64 package u-boot-sunxi the
> a64-olinuxino target, covering both the development board by that name
> and the TERES-I DIY laptop.
>
> I own a TERES-I and can offer to test

Didn't know the TERES-I was 100% compatible; nice!

> (but am not familiar with the packaging style of the u-boot source
> package (seems to not use common git-buildpackage style and no hints
> is provided in README.source), so I would prefer to leave to others to
> implement the change.

Pretty standard package in some regards: dpkg-buildpackage, debuild,
sbuild, pbuilder should all work without any unusual incantations
(e.g. orig.tar.* in the upper directory). You will need
DEB_BUILD_PROFILES=cross if you want to cross-compile, and have the
appropriate (multi-arch) build dependencies installed... sbuild
generally does the right thing for me.

Which... can be a bit of an adventure... and it also may need an
upstream version not yet uploaded to Debian... so I can build and upload
a package somewhere for you to test before uploading to Debian, if you'd
rather.

This patch should do it, if you're willing to be listed as a tester:

diff --git a/debian/targets b/debian/targets
index a35c559f77..c67a7a4adb 100644
--- a/debian/targets
+++ b/debian/targets
@@ -176,6 +176,9 @@ arm64   qcomdragonboard410c u-boot.bin
 # Ryan Finnie 
 arm64  rpi rpi_3   u-boot.bin

+# Jonas Smedegaard 
+arm64  sunxi   a64-olinuxino   u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb
+
 # Vagrant Cascadian 
 arm64  sunxi   pine64_plus u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-plus.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb

Unfortunately, arm-trusted-firmware is not packaged for Debian, and the
allwinner boards require using a vendor fork, so you will need to build
that yourself. The process is roughly documented in
board/sunxi/README.sunxi64 and debian/u-boot-sunxi.README.Debian in git.

I've recently successfully tested the non-legacy process on a Pine64+,
which is similar hardware.

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#880068: virtualbox: Doesn't build on kernel linux-4.14-rc6

2017-11-12 Thread Kevin Locke

Package: virtualbox
Version: 5.2.0-dfsg-5
Followup-For: Bug #880068

Dear Maintainer,

I can also confirm the issue is still present in virtualbox-source
5.2.0-dfsg-5 when building against kernel 4.14.  I was able to compile
successfully by applying r69539 from upstream.[1]  You may want to
consider including it in a future package version.

Cheers,
Kevin

1.  https://www.virtualbox.org/changeset/69539/vbox


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

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

Versions of packages virtualbox depends on:
ii  adduser   3.116
ii  iproute2  4.9.0-2
ii  libc6 2.24-17
ii  libcurl3-gnutls   7.56.1-1
ii  libdevmapper1.02.12:1.02.145-1
ii  libgcc1   1:7.2.0-12
ii  libgsoap-2.8.49   2.8.49-1
ii  libpng16-16   1.6.34-1
ii  libpython3.6  3.6.3-1
ii  libsdl1.2debian   1.2.15+dfsg2-0.1
ii  libssl1.1 1.1.0g-2
ii  libstdc++67.2.0-12
ii  libvncserver1 0.9.11+dfsg-1
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libxcursor1   1:1.1.14-3
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-5+b1
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  python3   3.6.3-2
ii  python3.6 3.6.3-1
ii  virtualbox-source 5.2.0-dfsg-5
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages virtualbox recommends:
ii  libgl1  1.0.0-1
ii  libqt5core5a5.9.1+dfsg-9
ii  libqt5opengl5   5.9.1+dfsg-9
ii  libqt5widgets5  5.9.1+dfsg-9
ii  virtualbox-qt   5.2.0-dfsg-2

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  5.2.1-118918-1

-- no debconf information

Bug#879027: libtomcrypt: FTBFS on x32: final link failed: Bad value

2017-11-12 Thread Aaron M. Ucko

Michael Stapelberg  writes:

> ucko, what’s the procedure here? How can Steffen get access to a
> machine on which to reproduce this issue?

Good question.  Technically, x32 is an alternate ABI for amd64, so the
amd64 porter box could in principle additionally host x32 chroots.
However, to do so, it would need an explicit kernel command line setting
(syscall.x32=y), since x32 binary support is off by default for now to
avoid adding a potential attack vector for little practical gain.

I'm not an official porter or buildd maintainer, and don't know what
setup they use, sorry.

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

Bug#880920: Document Rules-Requires-Root field

2017-11-12 Thread Guillem Jover

On Sun, 2017-11-05 at 10:20:35 -0700, Sean Whitton wrote:
> Package: debian-policy
> Version 4.1.1.1
> Severity: normal
> User: debian-pol...@packages.debian.org
> Usertags: proposal
> 
> On Sat, Nov 04 2017, Niels Thykier wrote:
> > While there has not been any comments / feedback on devel-devel, we
> > have seen about 35-40 packages adopting R³ since the proposal was
> > posted to debian-devel. :)
> >   This puts us on about ~50 packages that can now build without
> > (fake)root today (per [codesearch query]).
> 
> Given this, Rules-Requires-Root should go into Policy.

Yes, now, that the feedback deadline has passed.

> I wonder if we should just make Policy the new home of the spec that
> Niels and Guillem have already written?

While I think this should be obviously documented in policy. I'm not
planning on removing the "spec" from dpkg itself, because it's been my
growing opinion that dpkg should be self-contained when it comes to the
documentation about every of the interfaces it uses and provides. More
so because dpkg is used beyond Debian, and in many places it has no
saying on policies (vs. mechanisms), and in others it allows things
that Debian policy does not.

I could perhaps consider removing the debhelper keyword mention from
there because it feels like a layer violation, but I'm not overly
bothered.

Thanks,
Guillem

Bug#881568: src:linux: please enable CONFIG_RTL8723BS (staging driver for wifi used in TERES-I laptop)

2017-11-12 Thread Jonas Smedegaard

Package: src:linux
Version: 4.14~rc7-1~exp1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please enable CONFIG_RTL8723BS, for building the staging driver for the
Realtek 8723bs wifi+bluetooth chip used in at least the Olimex TERES-I
DIY laptop.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloI/EcACgkQLHwxRsGg
ASEcOA//WgXyEORnEX4hmbiEQQjfVXu1i/qnCy/ADIbDFmcc3rjqNmju95yIjQCe
8QhvbfR5febUowwAyqkoIT+u2iIHdss4N+Fl0n1VEdgJSf8Mjo8yDRf9INzBF2BU
7FnK0E1oHDWgjwCHA/xrVqY2kP8j46X3rtPErBEOSUgAN/XP1qXyPTOasq4/Mh49
wxQLoHMp8O6qFoB6wuy/YN0zzslYU2lo6T5aflJ7rnyZH6LuBi0YMJgHf7oTVHfQ
lw/vFw9+jxTflQc9SbBt6tmfikrCHaVmiRp56ze1mWsNExbGBVfnpjyW0AUtJcUg
D1gvHSuRofepWxivEcbt6yQ44Y82Q++IXGUHpCX1P+8Of4pesp2idhIhl6BQNKET
Z0siYEU7WxuVuo9544I2LTJH6IeG/Z0TF2iiFTTv5iIxK6GsYGXW1uZSCvkZXdSZ
6XRPRdD6iC8Veb/Ex1KB94MjI0KTCfb4yDPBQhVbTe+59VOk5YWQ98E7SAOoi16p
rjiflvyHLjODQIsQGJTlvO9ypqBafy5EOi/EfVhIPO2pyp6DZrBMa4+0MJjQQcfO
/udWWuyr7d3/6NeMdiMs0cWDNaZOKQbQ7N5vYAs6Z2lAoQqjmYuXviKNKuIVi7Qn
CB6XfIrzIIjx6gQZW3uhKKkc84g2p/I9HCgB36DX40LyUTSX5A0=
=KBr/
-END PGP SIGNATURE-

Bug#881567: linux-image-4.14.0-rc7-arm64: Consider enabling CONFIG_NVMEM_SUNXI_SID

2017-11-12 Thread Jonas Smedegaard

Package: src:linux
Version: 4.14~rc7-1~exp1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In checking what my exciting new Olimex TERES-I laptop is capable of, I
notice that CONFIG_NVMEM_SUNXI_SID is disabled in its config.

The feature is available on all Allwinner SoC apparently, and documented
at , so probably relevant to
enable both on arm64 and armmp kernels.

I don't have a crucial need for this personally, but wonder if harmless
to enable in case someone finds it useful.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloI+csACgkQLHwxRsGg
ASErpA//SBRc+UWtVap6ECUPPYGs496DGtvzP2dR/y2+FzjzBbVGQM3wB2U8nnNY
lqskyRRJzGrQH0YlvqfGEBMmZngGFFputPXOZHRe5gzjFMn+H2jj0YoIAuwP8eu6
FHLwhAqiPnLhOuew0aFMjUQr5xdy5dvM5uv0CiZve/53oaYogVmyeb26L1GC4Gdf
Nq1wrboqr7vAlXGtUAqJID9pblRBJrZ+ZAaEkKxn9smH+1k3l/LZkdCQbXAsY2SO
dH6CxTQNTapbvC8wfZVhJLeTj7EEgP+Y4SS4SGi4GZ4rXnu449gdPumTiRDXV2zN
uwWGoZMnCeVJW0lia31FTr63Vcv1y25qYq9xstUJsoi9+1UIbdVqyfeBo33kHPkb
nKkiJkPfCGlNQI6RMEofqsubUak+VV5BULxYcIyc3AwwHxbPQJCkF5m0Aijk55x9
adN+7mIUhmwFd8wlcaOXagoyPPHxFv83ep3stxpDILvSlgdfRlCFKvAhMIYffP8B
KxzfENto7el6wpshROTxrbPACrpArorEJhG4dGt2QjA9gvLsDmNY5DxTJ8u22RF1
hoE+UUNLcj7yehEH/xZryOKk1SvzFi6VIC+S4kT9SY5HalkRRSCbbRz42+TDv4XS
3mKcPrl3FqMh5thsJv5gzLwiLy+4DOwjdiyy8zphMTOsiYKa0AQ=
=9oPJ
-END PGP SIGNATURE-

Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP

2017-11-12 Thread Gabriel Filion

intrigeri:
> Let's sort this out first as there seems to be a misunderstanding.
> IMO this bug is not RC because:
> 
> 1. The profile this bug report is about is not enforced by default;
>it's not even shipped in /etc/apparmor.d. It takes 2 manual steps
>to enforce it, so thankfully, we're far from shipping a broken
>default configuration :)

oh! you're totally right! I don't remember enabling the profile but I
was just blindly finding my way around to understand apparmor in the
recent days.
thanks for the super clear explanation for changing the status :)

> If you came across instructions that told you to enforce such profiles
> and that did not point you to the aforementioned warning, then I'm
> very sorry! I'll treat this as a RC bug. Please point me to that doc
> and I'll fix it ASAP. Thanks in advance!

fwiw I was following mainly the debian wiki pages about apparmor. I
remember reading the advisory, but for some reason I didn't keep the
information that "the profiles might not work with default
configurations" when reading. probably some level of confusion on my part.

>> and when I rebooted to activate the kernel part, I didn't notice the
>> issue below.. but a couple reboots afterwards I couldn't obtain
>> a DHCP address anymore for wired and wifi interfaces.
> 
> Thanks for reporting this. I'm sorry this profile broke an essential
> part of your system. I'm not surprised though: to the best of my
> knowledge, nobody is actively using this profile on, and maintaining
> this profile for, Debian. Quite some paths in it don't match where
> things are shipped in Debian. This is why we don't enable this profile
> by default.

well I guess that my report confirms that the current profile in
apparmor-profiles-extra is somewhat broken. (it's still intriguing why
it was working for some time and then stopped working.. but I'd have to
repeat in order to figure out why. my time is probably better spent on
testing this other profile you mentioned)

> The good news is that there is a dhclient profile available elsewhere,
> that works way better on Debian: see #795467.

ok I can see that it looks like the proposed profile for isc-dhcp-client
is the one from ubuntu. still no reply from debian packagers about this
though, two years later.

what approach should we take here in order to get things going? do you
think that having more feedback from ppl who use the profile
successfully would help to get that merged in, or do you suspect it
might just be lack of available time or interest from package maintainers?

also, maybe if we can get more ppl to test ubuntu's profile in debian,
then they'd be willing to upstream it in apparmor?

Cheers



signature.asc
Description: OpenPGP digital signature

Bug#881566: python-acoustid: incompatible/broken on Python 3 (fix available upstream)

2017-11-12 Thread James Braid

Package: python3-acoustid
Version: 1.1.2-2
Severity: important

Dear Maintainer,

The current version of python-acoustid doesn't work with Python 3.
Specifically the submit() function to submit fingerprints is broken:
https://github.com/beetbox/pyacoustid/pull/33

There is a fix available upstream in the 1.1.5 release. Could you please
update the Debian packaging to include this fix?

Thanks,
James


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

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

Versions of packages python3-acoustid depends on:
ii  libchromaprint11.4.2-1
ii  python33.6.3-2
pn  python3-audioread  
ii  python3-requests   2.18.1-1

python3-acoustid recommends no packages.

python3-acoustid suggests no packages.

-- no debconf information

Bug#881565: python-acoustid: incompatible with python3 (fix availble upstream)

2017-11-12 Thread James Braid

Package: python-acoustid
Version: 1.1.2-2
Severity: important

Dear Maintainer,

The current version of python-acoustid doesn't work with Python 3.
Specifically the submit() function to submit fingerprints is broken:
https://github.com/beetbox/pyacoustid/pull/33

There is a fix available upstream in the 1.1.5 release. Could you please
update the Debian packaging to include this fix?

Thanks,
James


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

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

Versions of packages python3-acoustid depends on:
ii  libchromaprint11.4.2-1
ii  python33.6.3-2
pn  python3-audioread  
ii  python3-requests   2.18.1-1

python3-acoustid recommends no packages.

python3-acoustid suggests no packages.

-- no debconf information

Bug#880551: xterm: corrections to man page

2017-11-12 Thread Thomas Dickey

On Thu, Nov 02, 2017 at 05:40:22AM -0400, G. Branden Robinson wrote:
> I didn't realize that was the case.  My battered old copy of _Unix Text
> Processing_ (Dougherty, O'Reilly) doesn't really cover these matters.
> (Its explanation of \- is simply "the minus sign in the _current_ font",
> emphasis in original.)  There simply isn't much discussion of spacing
> vs. combining glyphs.

I didn't have a copy of this (and have limped along).
But checking for availability, I find it's online:

http://www.oreilly.com/openbook/utp/

...so I'll have some more reading to do.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#881564: u-boot: please add a64-olinuxino target to [arm64] u-boot-sunxi binary package

2017-11-12 Thread Jonas Smedegaard

Source: u-boot
Version: 2017.09+dfsg1-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please build and include with binary arm64 package u-boot-sunxi the
a64-olinuxino target, covering both the development board by that name
and the TERES-I DIY laptop.

I own a TERES-I and can offer to test (but am not familiar with the
packaging style of the u-boot source package (seems to not use common
git-buildpackage style and no hints is provided in README.source), so I
would prefer to leave to others to implement the change.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAloI8BIACgkQLHwxRsGg
ASGJ4w//Xsdo9kfzcBFDaxWQZarWU1+aunhbY1ALNO2mBCGfH6BU9BfivXFQI+ml
fqWQgpdKtfOmLN/dQCgmDcNlqKIN9k9kCkgmYeeG/YlhiIHA6WAM5D5fVLFXeXTi
6YSGq7IHENRnH1bHcitRXUj0SmRPdmN+wU8TF234fuxjgF+IIPDBA/ouSOy4nWRM
uRdzWZtKu9dVnYG9mhlawLpQb5+AFZlslPB1ZyyzMfa4Xf4bKFGRW9n1T0MHLutN
wHUpEocbsYuKtVeT+IfltRZ78QUjDZ9U5HABKVZTCgax29o6OKsJ+ua9SC3bp3pB
WLINOsIDCIROiGHOg26qTT7x+1TJH8uRrkAdo9GRGbQuV1q2wHs8irzOzXA7UBSh
9NZeAMOq7dN0obfE4SfA66LAMEArk4AJRGAzk3RkUJzLxpHbaAWiWoDq6MP6FA5x
h4OckLcaaac7EogPVuCIl2dB2cvCkEmAOKXVtCr0TgzeA+73LtCrJ6iTMe74GtCr
K5+c1EkS1gufq3X4dyX33rK1E3hkTyUxux0ZZSBX+Y8SZf0K634KkaVA08kerGpq
c7bDnn0215tsM70dh3hTlPzkWRNW6TsGGRfStKoV4sOZIBYAiih2IA/J/bOiC6xR
imAQjFMLSWEUPwYkwqfcwG9qShH4jHMYmZyjpfUVjLI+u5GgNoc=
=kwnh
-END PGP SIGNATURE-

Bug#880551: xterm: corrections to man page

2017-11-12 Thread Thomas Dickey

On Tue, Nov 07, 2017 at 08:21:54AM -0500, G. Branden Robinson wrote:
> At 2017-11-07T08:10:40-0500, G. Branden Robinson wrote:
> > Here's an updated version of the patch, reverting the de-boldfacing of
> > action names (and some token names) in resource translations.
> 
> Of course, by sending that I guaranteed I'd find a problem with it.
> 
> Here's my next try.  The problem with the previous was stuff like this:
> 
> \\fP(ti

hmm - I've applied about half.

Offhand, there are three areas not applied:

a) Solaris eats the \e's as well as the named characters such as \(ha

b) I'm unsure why you removed all of the \&'s
   (my notes say it's used to fix preprocessor problems).

c) some of the right-double-quotes don't look right.

Attaching a cumulative diff, and the unapplied part of your patch.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
2c2
< .\" $XTermId: xterm.man,v 1.715 2017/06/18 18:07:02 tom Exp $
---
> .\" $XTermId: xterm.man,v 1.722 2017/11/13 00:42:56 Branden.Robinson Exp $
64c64
< .ie \n(.IP \(bu 4
---
> .ie n  .IP \(bu 4
70c70
< .ie \n(.sp
---
> .ie n  .sp
72c72
< .ie \n(.in +4
---
> .ie n  .in +4
97c97
< [\-\fItoolkitoption\fP ...] [\-\fIoption\fP ...] [\fIshell\fP]
---
> [\-\fItoolkitoption\fP \&...\&] [\-\fIoption\fP \&...\&] [\fIshell\fP]
510c510
< .B "\-cc \fIcharacterclassrange\fP:\fIvalue\fP[,...]"
---
> .B "\-cc \fIcharacterclassrange\fP:\fIvalue\fP[, \&...\&]"
589c589
< .BI \-e "\fI program \fP[ \fIarguments \fP.\|.\|. ]\fI"
---
> .BI \-e "\fI program \fP[ \fIarguments \fP\&.\|.\|.\& ]\fI"
630c630
< .BI \-fbb
---
> .B \-fbb
635c635
< .BI +fbb
---
> .B +fbb
640c640
< .BI \-fbx
---
> .B \-fbx
646c646
< .BI +fbx
---
> .B +fbx
667c667
< .BI \-fullscreen
---
> .B \-fullscreen
673c673
< .BI +fullscreen
---
> .B +fullscreen
705c705
< .BI \-hf
---
> .B \-hf
710c710
< .BI +hf
---
> .B +hf
715c715
< .BI \-hm
---
> .B \-hm
721c721
< .BI +hm
---
> .B +hm
727c727
< .BI \-hold
---
> .B \-hold
733c733
< .BI +hold
---
> .B +hold
795c795
< of C1 control characters (code 128-159) to treat them as printable.
---
> of C1 control characters (code 128\(en159) to treat them as printable.
905c905
< indicating to the shell that it should read the user's .login or .profile).
---
> indicating to the shell that it should read the user's \&.login or \&.profile).
1252c1252
< This option indicates that \fI\*n\fP should not write a record into the
---
> This option indicates that \fI\*n\fP should not write a record into
1328,1330c1328,1330
< -S/dev/pts/123/45
< -S123/45
< -Sab34
---
> \-S/dev/pts/123/45
> \-S123/45
> \-Sab34
1491c1491
< \fIstty\fP erase character (^H for backspace, ^? for delete)
---
> \fIstty\fP erase character (^H for backspace, ^?\& for delete)
1494c1494,1495
< will affect DECBKM.  First, \fI\*n\fP obtains the initial \fIerase\fP character:
---
> will affect DECBKM.
> First, \fI\*n\fP obtains the initial \fIerase\fP character:
1529,1530c1530,1532
< to 2 (internal).  This ties together \fBbackarrowKey\fP
< and the control sequence for \fBDECBKM\fP
---
> to 2 (internal).
> This ties together \fBbackarrowKey\fP
> and the control sequence for \fBDECBKM\fP.
1777c1779
< setting the intial screen size, e.g., via window manager interaction.
---
> setting the initial screen size, e.g., via window manager interaction.
1924c1926
< keywords; \fI\*n\fR's table is built-in.
---
> keywords; \fI\*n\fR's table is built in.
2031c2033
< (codes 128-159) to make them be treated
---
> (codes 128\(en159) to make them be treated
2446c2448
< \fIlow\fP[-\fIhigh]\fP[:\fIvalue\fP].
---
> \fIlow\fP[\-\fIhigh]\fP[:\fIvalue\fP].
2492c2494
< The default shades of color are chosen to allow the colors 8-15
---
> The default shades of color are chosen to allow the colors 8\(en15
2714c2716
< will only be able to display codes 0-255, while UTF-8 text can include
---
> will only be able to display codes 0\(en255, while UTF-8 text can include
2845a2848
> (i.e.\& no operations are allowed).
3068,3069c3071,3072
< \=`xfontsel -print`
< \ -n "$FONT" && xfd -fn "$FONT"
---
> \=`xfontsel \-print`
> \ \-n "$FONT" && xfd \-fn "$FONT"
3077c3080
< fc-list :scalable=true:spacing=mono: family
---
> fc\-list :scalable=true:spacing=mono: family
3229c3232
< normally have the VT100 line-drawing glyphs in cells 1-31.
---
> normally have the VT100 line-drawing glyphs in cells 1\(en31.
3392c3395,3396
< The default is \*(``true\*(''. It may be set to false in order to work around
---
> The default is \*(``true\*(''.
> It may be set to false in order to work around
3538c3542
< *localeFilter: xterm-filter -p
---
> *localeFilter: xterm\-filter \-p
3585c3589
< If the resource is \*(``auto\*('' then \fI\*n\fR will use the 
---
> If the resource is \*(``auto\*('' then \fI\*n\fR will use the
3821c3825
< but appear to have been invented for \fI\*n\fP in X11R4. 
---
> but appear to have been invented for \fI\*n\fP in X11R4.
3994c3998
< In that case, only the alternate screen is selectd.
---
> In

Bug#881562: rdkit: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: rdkit
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881560: pywbem: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: pywbem
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881563: xappy: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: xappy
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881561: qpid-proton: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: qpid-proton
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881559: python-x2go: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: python-x2go
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#842569: mark autoconf2.13 Multi-Arch: foreign

2017-11-12 Thread Ben Pfaff

On Sat, Nov 11, 2017 at 02:48:31PM +0100, Manuel A. Fernandez Montecelo wrote:
> Hi Ben,
> 
> 2016-10-30 13:48 Helmut Grohne:
> >Package: autoconf2.13
> >Version: 2.13-67
> >Tags: patch
> >User: helm...@debian.org
> >Usertags: rebootstrap
> >Control: affects -1 + src:firefox src:firefox-esr src:gcc-3.3 
> >src:gcc-m68hc1x src:grass src:icedove src:postgis src:vflib3
> >
> >The affected packages fail to satisfy their cross Build-Depends, because
> >their dependency on autoconf2.13 is not satisfiable. In general,
> >Architecture: all packages cannot satisfy cross build dependencies
> >unless marked Multi-Arch: foreign.
> 
> The patch is simple enough and affects important packages.
> 
> Would it be possible to apply it in your next uploads?

As far as I can tell, this was applied in 2.13-67 and is still in
2.13-68.  What is missing?

Thanks,

Ben.

Bug#881558: python-rtslib-fb: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: python-rtslib-fb
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881557: python-openid: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: python-openid
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881556: python-demgengeo: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Package: python-demgengeo
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881554: python-configshell-fb: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: python-configshell-fb
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881555: python-csb: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: python-csb
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881552: pylogsparser: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: pylogsparser
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881553: pystemmer: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: pystemmer
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881551: pylibssh2: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: pylibssh2
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881550: pydoctor: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: pydoctor
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881549: munkres: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: munkres
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881547: lcm: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: lcm
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881548: libcloud: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: libcloud
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881546: esys-particle: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Package: esys-particle
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881461: frei0r-plugins: Breaks frei0r-plugins (<= 1.1.22)

2017-11-12 Thread Kingsley G. Morse Jr.

Hi Sebastian,

Thank you very much for sharing your thoughts.

It seems to me you asked a reasonable question:

> Why should frei0r-plugins break itself?

Through no fault of your own, when I filed the bug
report, I 

1.) was unaware that a source package named
just "frei0r" existed, and

2.) failed to mention I assumed 

a.) the "Breaks" header referred to a
non-existent package, and

b.) what the original author meant was to say 
frei0r-plugins broke an *earlier version*
of itself.

So...

You were right!

I was wrong!


But, but, but, I now find myself wondering if
maybe the "Breaks:" header should just be removed.

Why?

If 

a.) it doesn't make sense for a package to
break itself, then maybe

b.) it also doesn't make sense for a package
to break its own source package.

I dunno.

And I don't have a strong preference.

Thanks again for sharing your thoughts.

I find I often benefit from other peoples' point
of view.

Now seems to be one of those times!

:-)

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881545: configobj: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth J. Pronovici

Package: configobj
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

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

Kernel: Linux 3.2.0-4-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

Bug#881544: dbf: Please migrate away from Epydoc if possible

2017-11-12 Thread Kenneth Pronovici

Source: dbf
Severity: wishlist

Hi,

If possible, please consider moving away from the use of Epydoc in your
package.  Epydoc is basically unmaintained upstream.  Also, it is only
supported for Python 2, so it will reach its end of life along with
Python 2 sometime in 2020.

I will continue to maintain the Epydoc packages in Debian as long as I
can, acting as de facto upstream.  However, once Python 2 is unsupported
in Debian, I'm not sure that we'll have too many options to keep it
alive.  Migrating it to Python 3 is a fairly large job that I don't
have the time or the expertise to take on right now.

For my own Python code, I have recently converted to Sphinx using the
Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
script to convert common Epydoc markup to Google-style docstrings. It's
not perfect, but it would get you much of the way toward working code.

Thanks,

Ken (maintainer for python-epydoc)

[1] 
https://bitbucket.org/cedarsolutions/cedar-backup3/src/73037a2/util/sphinx-convert

Bug#881542: qtcreator: Qt Creator requires Valgrind and gdb-python2 to debug programs but neither package is listed as a dependency or even as a recommendation.

2017-11-12 Thread Rui

Package: qtcreator
Version: 4.2.0-1+b1
Severity: normal

Dear Maintainer,

Qt-Creator requires Valgrind to debug and profile code.  Yet, no package is 
listed as a dependency or even a
requirement.


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

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

Versions of packages qtcreator depends on:
ii  libbotan-1.10-1   1.10.16-1
ii  libc6 2.24-11+deb9u1
ii  libclang1-3.9 1:3.9.1-9
ii  libgcc1   1:6.3.0-18
ii  libqbscore1.7 1.7.0+dfsg-4
ii  libqbsqtprofilesetup1.7   1.7.0+dfsg-4
ii  libqt5concurrent5 5.7.1+dfsg-3+b1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5designer5   5.7.1-1
ii  libqt5designercomponents5 5.7.1-1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5help5   5.7.1-1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5qml5 [qtdeclarative-abi-5-7-0]  5.7.1-2+b2
ii  libqt5quick5  5.7.1-2+b2
ii  libqt5quickwidgets5   5.7.1-2+b2
ii  libqt5sql55.7.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  qml-module-qtqml-models2  5.7.1-2+b2
ii  qml-module-qtquick-controls   5.7.1~20161021-2
ii  qml-module-qtquick2   5.7.1-2+b2
ii  qtchooser 63-g13a3d08-1
ii  qtcreator-data4.2.0-1

Versions of packages qtcreator recommends:
ii  clang  1:3.8-36
ii  gdb-python2 [gdb]  7.12-6
ii  konsole [x-terminal-emulator]  4:16.12.0-4
ii  make   4.1-9.1
ii  qmlscene   5.7.1-2+b2
ii  qt5-doc5.7.1-2
ii  qt5-qmltooling-plugins 5.7.1-2+b2
ii  qtbase5-dev-tools  5.7.1+dfsg-3+b1
ii  qtcreator-doc  4.2.0-1
ii  qtdeclarative5-dev-tools   5.7.1-2+b2
ii  qttools5-dev-tools 5.7.1-1
ii  qttranslations5-l10n   5.7.1~20161021-1
ii  qtxmlpatterns5-dev-tools   5.7.1~20161021-3
ii  xterm [x-terminal-emulator]327-2

Versions of packages qtcreator suggests:
ii  cmake  3.7.2-1
ii  g++4:6.3.0-4
ii  git1:2.11.0-3+deb9u2
ii  kdelibs5-data  4:4.14.26-2
pn  subversion 

-- no debconf information

Bug#881541: ghostscript: renders wrong glyphs with libfreetype6 2.8.1-0.1

2017-11-12 Thread Kacper Gutowski

Package: ghostscript
Version: 9.22~dfsg-1
Severity: normal

Ghostscript renders many fonts incorrectly after
upgrading libfreetype7 from 2.8-0.2 to 2.8.1-0.1.
For example running this:

  /DejaVuSerif findfont 12 scalefont setfont
  9 9 moveto (abcd)show

displays a text that looks like "DEFG" (as if there was an offset of
-29 in ASCII values).  The same thing happens when using glyphshow:
/T glyphshow displays as "7".

This happens with many other fonts as well, most showing the same wrong
glyphs, others having different offset, and few still rendering correctly.


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

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

Versions of packages ghostscript depends on:
ii  debconf  1.5.63
ii  libc62.24-17
ii  libgs9   9.22~dfsg-1

Versions of packages ghostscript recommends:
ii  gsfonts  1:8.11+urwcyr1.0.7~pre44-4.4

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.22~dfsg-1

-- no debconf information

Bug#861508: zatacka: broken symlink: /usr/share/games/zatacka/font.ttf -> ../../fonts/truetype/ttf-dejavu/DejaVuSans.ttf

2017-11-12 Thread Eriberto Mota

Hi!

I confirm that the problem is the ttf-dejavu-core absence. I will provide a NMU.

Regards,

Eriberto

Bug#881448: [PKG-Openstack-devel] Bug#881448: Bug#881448: python-eventlet fails to install on amd64: SyntaxError: invalid syntax

2017-11-12 Thread Ondrej Novy

So you uploaded package without run of autopkgtest, which can check if
package works and without even trying to install that package? So just
blindly upgrade from upstream and upload? Huh.

2017-11-12 9:50 GMT+01:00 Thomas Goirand :

> On 11/12/2017 08:51 AM, Chris Lamb wrote:
> > Hi,
> >
> >> python-eventlet fails to install on amd64: SyntaxError: invalid syntax
> >
> >   Sat 11 18:37 < zigo> In Python 2, with what I just uploaded for
> python-eventlet, I have these issues:
> >   Sat 11 18:37 < zigo> Setting up python-eventlet (0.20.0-1) ...
> >   Sat 11 18:37 < zigo>   File "/usr/lib/python2.7/dist-
> packages/eventlet/green/http/client.py", line 195
> >   Sat 11 18:37 < zigo> _is_legal_header_name =
> re.compile(rb'[^:\s][^:\r\n]*\Z').match
> >   Sat 11 18:37 < zigo>
>   ^
> >   Sat 11 18:37 < zigo> SyntaxError: invalid syntax
> >   Sat 11 18:37 < zigo>   File "/usr/lib/python2.7/dist-
> packages/eventlet/green/http/cookiejar.py", line 1269
> >   Sat 11 18:37 < zigo> yield from deepvalues(obj)
> >   Sat 11 18:37 < zigo>  ^
> >   Sat 11 18:37 < zigo> SyntaxError: invalid syntax
> >   Sat 11 18:37 < zigo> Does anyone know how to patch this?
> >   Sat 11 18:38 < zigo> It works perfectly in py3...
> >   Sat 11 18:40 < zigo> Looks like doing b'' for the string of the first
> issue is fixing the issue for py2, and works in py3.
> >   Sat 11 18:40 < zigo> I'm not sure for the yield though.
> >   Sat 11 18:44 < wRAR> of course you can't "fix" yield from for Python <
> 3.5
> >   Sat 11 18:45 < zigo> Hum... I fix I got it ! :)
> >   Sat 11 18:46 < wRAR> https://github.com/eventlet/
> eventlet/blob/master/eventlet/green/http/__init__.py#L56
> >   Sat 11 18:46 < wRAR> you don't need to fix the *code*
> >   Sat 11 18:47 < zigo> wRAR: I actually do...
> >   Sat 11 18:48 < wRAR> ok
> >   Sat 11 18:48 < wRAR> and for the first line do you mean you removed
> the r prefix?
> >   Sat 11 18:48 < zigo> wRAR: Yes. Is this wrong?
> >   Sat 11 18:48 < wRAR> do you know what does this prefix mean?
> >   Sat 11 18:49 < zigo> wRAR: I know what b means, not sure what rb does.
> >   Sat 11 18:49 < wRAR> I see
> >   Sat 11 18:49 < zigo> Which is why I'm asking in the channel.
> >   Sat 11 18:49 < wRAR> https://docs.python.org/3/
> library/stdtypes.html#text-sequence-type-str
> >   Sat 11 18:50 < wRAR> I guess you never wrote regulare expression code
> in Python?
> >   Sat 11 18:51 < zigo> Right.
> >   Sat 11 18:52 < zigo> Oh...
> >   Sat 11 18:52 < zigo> Indeed, removing r is a bad idea... :P
> >
> > ie. the maintainer is at least aware of the issue.
> >
> > Zigo, I just went to provide a patch of my own but I cannot find
> > the latest packaging corresponding to this version in the Vcs-Git
> > repository.
> >
> > Regards,
>
> That's nice of you Chris. We're currently not sure where to host the VCS
> of this package, and I'm not sure it's going to stay there. Anyway, I've
> currently pushed it to:
>
> /git/openstack/python/python-eventlet.git
>
> I've produced 2 patches already for it:
> fix-string-using-rb-in-python2.patch
> fix-yield-from-in-py2.patch
>
> though I'm not sure they are good enough, and they are certainly not
> enough (ie: after applying, there's still Py 2.7 compile problems).
>
> Thanks a lot for any help you may provide, Eventlet is a key package for
> OpenStack, and we need it for finishing this release. I tried upgrading
> to 0.20.0, because there's a problem with building Neutron, which seems
> to be related to this (ie: unit test fails to start with the older
> version 0.19.0).
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> ___
> Openstack-devel mailing list
> openstack-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel
>



-- 
S pozdravem/Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
Jabber: on...@njs.netlab.cz
ICQ: 115-674-713
Facebook: http://www.facebook.com/onovy
Tel/Cell: +420 777 963 207
Datová schránka: aypqr6c

Bug#881536: ffmpeg: Breaks sound in kodi

2017-11-12 Thread James Cowgill

Hi,

On 12/11/17 20:32, Robert Luberda wrote:
> Package: ffmpeg
> Version: 7:3.4-2
> Severity: important
> 
> The latest ffmpeg makes sound in kodi to be scratchy, i.e. containing some 
> additional noise that makes watching videos in kodi uncomfortable/annoying.
> 
> Downgrading ffmpeg and dependent libraries to version 3.3.4-2+b3 fixes the
> issue (makes sound in kodi clear).

This is likely to be related to #879673 / #881286 which has a workaround
which I hoped would work, but doesn't seem to in every case. I can
reproduce the bug, but only for videos containing aac audio and only in
kodi.

I have attached a LD_PRELOAD shim which will cause any drain packets
sent to avcodec_decode_audio4 to be dropped (see the above bugs and
links for why this may be relevant). Could you compile it and run kodi
like this:

 gcc -shared shim.c -olibshim.so
 LD_PRELOAD=$(pwd)/libshim.so kodi-standalone

If that fixes your audio problems, then this is almost certainly #881286
in kodi (where kodi flagrantly violates the ffmpeg API).

Thanks,
James
#define _GNU_SOURCE
#include 
#include 

// Mini version of AVPacket
typedef struct AVPacket {
   void *buf;
   int64_t pts;
   int64_t dts;
   uint8_t *data;
   int   size;
} AVPacket;

int avcodec_decode_audio4(void* a, void* b, int* got_frame_ptr, const AVPacket* pkt)
{
// Ignore null packets
if (pkt->size == 0)
{
*got_frame_ptr = 0;
return 0;
}

// Forward to real function
int (*orig_decode)(void*, void*, int*, const AVPacket*) =
dlsym(RTLD_NEXT, "avcodec_decode_audio4");
return orig_decode(a, b, got_frame_ptr, pkt);
}

signature.asc
Description: OpenPGP digital signature

Bug#781532: Info received (keycodes wrong)

2017-11-12 Thread Eric Van Buggenhaut

skimming through the manpage, I found out this trick:

   If you have trouble with some keys not working, try setting the keymaps
   on both systems to be the same using setxkbmap.

That actually solved my issue, in my case having the same:

$ setxkbmap -query
rules:  evdev
model:  pc105
layout: be,es,jp

on both machines.

On Sun, Nov 12, 2017 at 10:36 PM, Debian Bug Tracking System
 wrote:
> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Barak A. Pearlmutter 
>
> If you wish to submit further information on this problem, please
> send it to 781...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 781532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781532
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



-- 
Eric

Bug#881540: Please package latest upstream version

2017-11-12 Thread Michael Biebl

Source: libepoxy
Version: 1.3.1-3
Severity: wishlist

Hi,

in gtk+3.0 we currently ship a patch, which is required to detect if we
have GLX support. Upstream solved that differently and implemented that
via libepoxy [2].
It would be nice if we could get rid of [1] and replace it with the much
smaller patches from [3] which landed upstream. That requires a newer
libepoxy though.
It would thus be great if you can package a version >= 1.4. The current
version seems to be 1.4.3.

Thanks for considering,

Michael


[1] 
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gtk%2B3.0/debian/patches/gdk-x11-Check-if-we-have-access-to-GL-before-using-G.patch?view=markup
[2] https://bugzilla.gnome.org/show_bug.cgi?id=775279
[2] 
https://git.gnome.org/browse/gtk+/commit/?id=183538c2e23ccbd495580f895069b22d44135d68

https://git.gnome.org/browse/gtk+/commit/?id=02eb344950547c66a9096094f271b98e94614fcb

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

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

Bug#881538: php7.0: CVE-2017-8923: Overflowing the length of string causes crash

2017-11-12 Thread Salvatore Bonaccorso

Source: php7.0
Version: 7.0.19-1
Severity: important
Tags: security upstream
Forwarded: https://bugs.php.net/bug.php?id=74577
Control: clone -1 -2
Control: reassign -2 src:php7.1 7.1.8-1
Control: retitle -2 php7.1: CVE-2017-8923: Overflowing the length of string 
causes crash

Hi,

the following vulnerability was published for php7.0 and php7.1.

CVE-2017-8923[0]:
| The zend_string_extend function in Zend/zend_string.h in PHP through
| 7.1.5 does not prevent changes to string objects that result in a
| negative length, which allows remote attackers to cause a denial of
| service (application crash) or possibly have unspecified other impact
| by leveraging a script's use of .= with a long string.

Attached to [1] and [2] are POCs to demostrate the issue (verified on
i386 sid).

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-2017-8923
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8923
[1] https://bugs.php.net/bug.php?id=74577
[2] https://bugs.php.net/bug.php?id=73122

Regards,
Salvatore

Bug#781532: keycodes wrong

2017-11-12 Thread Eric Van Buggenhaut

I also confirm the bug. Checking keycodes sent/received with ev, I get
that a keycode 11 or 12 sent with the 'to' keyboard are seen as
keycode 77 on the 'from' desktop. Letter keys (a-z) usually work fine,
but 1-9 are totally messed up.

Both to and from machines run Debian stretch with amd64 arch.

Greetings,

-- 
Eric

Bug#876521: FTBFS with CGAL 4.11

2017-11-12 Thread Sebastiaan Couwenberg

Hi Joachim,

On 11/12/2017 09:33 PM, Joachim Reichel wrote:
> any news here? SFCGAL is now the only remaining reverse dependency that 
> affects
> the upload of CGAL 4.11.

No news, upstream commented in the issue twice but that died down since.

> Unless you have information that changes the picture in the near-term future I
> would like to go on and request a transition slot for CGAL 4.11.

You shouldn't have waited for this issue to request the transition slot.
As I said before, I'll remove the SFCGAL dependency from PostGIS if this
issue is not resolved when the CGAL transition starts. That way we can
keep postgis is testing.

Just raise the severity of this issue to serious when the transition
starts. That's the usual procedure for blocking issues and transitions. [0]

Kind Regards,

Bas

[0] https://wiki.debian.org/Teams/ReleaseTeam/Transitions

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

Bug#833146: flex FTCBFS: executes host architectue stage1flex during build

2017-11-12 Thread Niels Thykier

On Thu, 19 Oct 2017 17:17:00 + Niels Thykier  wrote:
> Manoj Srivastava:
> > That sounds like a good option. I'll try to get that working this weekend
> > 
> >   Manoj
> > 
> > [...]
> 
> 
> [...]

Hi Manoj,

Did you have a chance to look the new upstream version?  :)

Thanks,
~Niels

Bug#881527: qemu: FTCBFS due to broken cross build depend on glusterfs-common

2017-11-12 Thread Héctor Orón Martínez

Hello,

2017-11-12 21:21 GMT+01:00 Michael Tokarev :
> Control: tag -1 + moreinfo
>
> 12.11.2017 22:14, Héctor Orón Martínez wrote:
>> Source: qemu
>> Version: 1:2.10.0+dfsg-2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>>   Your package fails to satisfy cross build dependency installability due to 
>> glusterfs-common not being installable via multiarch:
>>   * https://bootstrap.debian.net/cross_all/qemu.html
>>   * DebianBug#881526
>>
>>   You might want to consider disabling glusterfs-common build dependency for 
>> the cross build case, otherwise your package seems to cross build fine.
>
> I'm not sure what's the problem here and why this bugreport exists in the 
> first place.
>
> First, what is "the cross build case", which case is that and why should we 
> care about it?

There are efforts to cross build Debian packages from sources, which
might be beneficial for bootstraping new/old architectures among other
use cases.
I think it woud be nice to be able to cross build QEmu (for new comers
better experience) as explained at:

http://suihkulokki.blogspot.com/2017/06/cross-compiling-with-debian-stretch.html

> And second, why should we disable some option(s) and build a broken package 
> in case some
> dependent package is buggy?  I think it is better to fix the buggy package 
> than to introduce
> bugs in other packages.

At your consideration, the option is only to be temporarily disabled
*in the cross case* until #881526 gets properly fixed. Due to
glusterfs-common being uninstallable, I was toying with cross build
case and found QEmu disables this option for Ubuntu distribution and
attempted a successful build without this option. In practical means,
that only needs to add a  tag after build dependency (I could
provide a tested patch if you need). However, we might leave the cross
build dependency in same way as native build and leave this bug open
to track cross buildability of the package.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#881537: Annual ping for Andriy Grytsenko

2017-11-12 Thread Andriy Grytsenko

Package: debian-maintainers
Severity: normal

Annual ping it is.

Thanks!


signature.asc
Description: Digital signature

Bug#876521: FTBFS with CGAL 4.11

2017-11-12 Thread Joachim Reichel

Hi Sebastiaan,

any news here? SFCGAL is now the only remaining reverse dependency that affects
the upload of CGAL 4.11.

Unless you have information that changes the picture in the near-term future I
would like to go on and request a transition slot for CGAL 4.11.

Kind regards,
  Joachim

Bug#881536: ffmpeg: Breaks sound in kodi

2017-11-12 Thread Robert Luberda

Package: ffmpeg
Version: 7:3.4-2
Severity: important

The latest ffmpeg makes sound in kodi to be scratchy, i.e. containing some 
additional noise that makes watching videos in kodi uncomfortable/annoying.

Downgrading ffmpeg and dependent libraries to version 3.3.4-2+b3 fixes the
issue (makes sound in kodi clear).

Regards,
robert


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

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

Versions of packages ffmpeg depends on:
ii  libavcodec577:3.4-2
ii  libavdevice57   7:3.4-2
ii  libavfilter67:3.4-2
ii  libavformat57   7:3.4-2
ii  libavresample3  7:3.4-2
ii  libavutil55 7:3.4-2
ii  libc6   2.24-17
ii  libpostproc54   7:3.4-2
ii  libsdl2-2.0-0   2.0.7+dfsg1-3
ii  libswresample2  7:3.4-2
ii  libswscale4 7:3.4-2

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#881088: Wordpress on wheezy

2017-11-12 Thread Markus Koschany

I have investigated the issue and found out that it is not just about
the missing brace, an additional database upgrade would also be required
to fix CVE-2017-14990 in Wheezy. The signup_id column does not exist
before version 3.7. In addition further code changes would be necessary.
I believe this would be too intrusive in this case because
CVE-2017-14990 is merely a new hardening feature for multisite
installations. I will revert the patch for CVE-2017-14990 for now. I am
sorry for any inconvenience this may have caused.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#881535: hedgewars crashes when starting a new game

2017-11-12 Thread Lutz L.

Package: hedgewars
Version: 0.9.22-dfsg-14
Severity: important

Dear Maintainer,

hedgewars crashes with a call to PHYSFS_read (), when starting a new
game.

As can be seen in an Arch Linux bug report [0], there are two ways to
solve the problem:
 - downgrade libphysfs1 to version 2.0 as can be found in stretch (works
   on my machine)
 - recompile hedgewars

[0] https://bugs.archlinux.org/task/55999

BR,
Lutz

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

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

Versions of packages hedgewars depends on:
ii  fonts-wqy-zenhei  0.9.45-7
ii  freeglut3 2.8.1-3
ii  hedgewars-data0.9.22-dfsg-14
ii  libavcodec57  7:3.4-2
ii  libavformat57 7:3.4-2
ii  libavutil55   7:3.4-2
ii  libc6 2.24-17
ii  libffi6   3.2.1-6
ii  libgcc1   1:7.2.0-14
ii  libgmp10  2:6.1.2+dfsg-1.1
ii  liblua5.1-0   5.1.5-8.1+b2
ii  libphysfs12.0.3-5
ii  libpng16-16   1.6.34-1
ii  libqt4-network4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libsdl-image1.2   1.2.12-7
ii  libsdl-mixer1.2   1.2.12-14
ii  libsdl-net1.2 1.2.8-5
ii  libsdl-ttf2.0-0   2.0.11-4
ii  libsdl1.2debian   1.2.15+dfsg2-0.1
ii  libstdc++67.2.0-14
ii  ttf-dejavu-core   2.37-1
ii  zlib1g1:1.2.8.dfsg-5

hedgewars recommends no packages.

hedgewars suggests no packages.

-- no debconf information

Bug#881527: qemu: FTCBFS due to broken cross build depend on glusterfs-common

2017-11-12 Thread Michael Tokarev

Control: tag -1 + moreinfo

12.11.2017 22:14, Héctor Orón Martínez wrote:
> Source: qemu
> Version: 1:2.10.0+dfsg-2
> Severity: normal
> 
> Dear Maintainer,
> 
>   Your package fails to satisfy cross build dependency installability due to 
> glusterfs-common not being installable via multiarch:
>   * https://bootstrap.debian.net/cross_all/qemu.html
>   * DebianBug#881526
> 
>   You might want to consider disabling glusterfs-common build dependency for 
> the cross build case, otherwise your package seems to cross build fine.

I'm not sure what's the problem here and why this bugreport exists in the first 
place.

First, what is "the cross build case", which case is that and why should we 
care about it?

And second, why should we disable some option(s) and build a broken package in 
case some
dependent package is buggy?  I think it is better to fix the buggy package than 
to introduce
bugs in other packages.

Tagging as "moreinfo" instead of closing right away because I want to 
understand your
position here.

Thanks,

/mjt

Bug#881534: mathjax: Include if possible STIX-Web otf/woff fonts

2017-11-12 Thread Gordon Ball

Source: mathjax
Severity: wishlist

Dear Maintainer,

Would it be possible to include the STIX-Web otf or woff files
(`fonts/HTML-CSS/STIX-Web/{otf,woff}` in the source package),
perhaps in `fonts-mathjax-extras`?

Jupyter Notebook expects to be able to load these files (eg,
`$MATHJAX/fonts/HTML-CSS/STIX-Web/woff/STIXMathJax_Main-Regular.woff`),
and they're not available in any of the binary packages. I don't think
files from `fonts-stix` can be substituted. (Related bug: #857928)


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

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

Bug#881533: Socket used by systemd for triggerhappy overwrite configuration socket for udev

2017-11-12 Thread Guillaume Zin

Package: triggerhappy
Version: 0.5.0-1

Hello,

Triggerhappy uses a socket to update its devices listerner. Socket is
configured in "/lib/systemd/system/triggerhappy.service" with "--socket
/run/thd.socket". Udev rule in "/lib/udev/rules.d/60-triggerhappy.rules"
uses this socket each time a device is added to system to add it to
listened devices list. But "/lib/systemd/system/triggerhappy.socket"
overwrite this socket as systemd socket. I had to delete
"/lib/systemd/system/triggerhappy.socket" and reboot for my system for
bluetooth device to be detected by triggerhappy.

This happens on Raspbian Stretch.

Regards.

Guillaume

Bug#881531: libreoffice: Bad rendering of LibreOffice buttons and some other widgets

2017-11-12 Thread Rene Engelhard

Hi,

On Sun, Nov 12, 2017 at 08:23:26PM +0100, Q4OS Team wrote:
> This bug is related to KDE Plasma DE. If I set "Windows" style in KDE
> systemsettings and run LibreOffice, all buttons and some other widgets are
> rendered without border.
> 
> Exact steps to reproduce:
> - A fresh Debian 9.2 Stretch stable installation with KDE Plasma, 64bit
> - Set the "Windows" style in KDE systemsettings
> - Run LibreOffice > Open file
> - Bug: All buttons have no border and look ugly

Even with default style it has some drawing problems, and some fixes only
went into later versions. Since I never got a list on what to backport
the stuff was not backported for stretch.

In any case, libreoffice-kde is gone aleady because Qt4 is supposed to be gone
for buster and will not come back.

Maybe a libreoffice-kf5/-kde5 will come back when the stuff is available and
working.

Regards,

Rene

Bug#881304: gajim does not reconnect after suspend

2017-11-12 Thread Alex

Hi.
I am using debian buster with network-manager.
I will test the symlinks later, I guess this will be the problem.
Currently there are some issues with gnome (mate) packages in buster anyway.

Am 12.11.2017 um 20:36 schrieb W. Martin Borgert:
> On 2017-11-12 13:33, Allo wrote:
>> - It renders the ugly Gnome 3 titlebar even when gtk3-nocsd is installed
>> and a better window manager is installed.
> Ah, yes, I already wondered why the title bar is so huge on XFCE :~)
Yep. Gnome renders the title bar client side. gtk3-nocsd should prevent
this, but for gajim it does not work. I suspect that the preloaded
library is somewhere lost between python and the gtk libraries loaded by
python.

>> But for debian buster probably the 0.16.8-5 issues are more important,
>> which is that it does not reconnect after suspend to disk, while it for
>> example works with pidgin. gajim seems to reconnect after network
>> disconnects as well, just not after suspend.
> 
> I asked in the MUC (ga...@conference.gajim.org). Don't hesitate
> to join the room, if you like!
I will see when I have time for more debugging. Are there any obvious
things which could fail?
I think something like reacting on network-managers ifdown and not on
ifup or similar may be the problem, because else I would expect it to
reconnect at least after some retries.

Alex

Bug#881304: gajim does not reconnect after suspend

2017-11-12 Thread W. Martin Borgert

On 2017-11-12 13:33, Allo wrote:
> It still happens with the experimental version, but this is broken in
> other ways as well:
> - No plugins are loaded at all. Which makes it impossible to use for a
> longer time, i.e because of broken OMEMO.

Could you please check
 - whether the following symlink exists?
   /usr/lib/python3/dist-packages/gajim/data/plugins -> 
../../../../../share/gajim/plugins
   This should be in the latest experimental version.
 - whether you installed the plugins from experimental, too
   (the ones in unstable/testing are still GTK2 and Python2)

> - It renders the ugly Gnome 3 titlebar even when gtk3-nocsd is installed
> and a better window manager is installed.

Ah, yes, I already wondered why the title bar is so huge on XFCE :~)

> But for debian buster probably the 0.16.8-5 issues are more important,
> which is that it does not reconnect after suspend to disk, while it for
> example works with pidgin. gajim seems to reconnect after network
> disconnects as well, just not after suspend.

I asked in the MUC (ga...@conference.gajim.org). Don't hesitate
to join the room, if you like!

Are you using network-manager?

Bug#881532: Please keep out of buster

2017-11-12 Thread Laurent Bigonville

Source: goffice-0.8
Version: 0.8.17-8
Severity: serious
Tags: sid buster

Hi,

goffice-0.8 is only used by gnucash and grisbi in the archive. 

Both gnucash and grisbi have already switched to goffice 0.10 in an
unstable version or in their git repository.

At the time of the buster release, they'll hopefully have migrated to
that new major version of goffice, so it's probably a good idea to get
rid of goffice-0.8 for buster.

I guess this can be revised when we are getting closer from the release.

Kind regards,

Laurent Bigonville

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

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

Bug#871811: FTBFS with CGAL 4.11

2017-11-12 Thread Pierre Saramito

Dear Joachim,

Many thanks for your patch: I am integrating it
in the debian files of the Rheolef package in order
to support the new CGAL 4.11 version.
Sorry for my late response, I was travelling 
in new zealand for conferences... 

The path for CGAL will be integrated in the fortcoming 
Rheolef upstream versions.


Kind regards,

Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://ljk.imag.fr/membres/Pierre.Saramito

Bug#881492: [Pkg-dns-devel] Bug#881492: Bug#881492: knot-resolver FTBFS on amd64: tests/config/test_config.mk:12: recipe for target 'check-config' failed

2017-11-12 Thread Daniel Kahn Gillmor

On Sun 2017-11-12 17:59:47 +0100, Kurt Roeckx wrote:
> On Mon, Nov 13, 2017 at 12:09:05AM +0800, Daniel Kahn Gillmor wrote:
>> On Sun 2017-11-12 15:45:26 +0100, Ondřej Surý wrote:
>> > Control: forwarded -1
>> > https://gitlab.labs.nic.cz/knot/knot-resolver/issues/272
>> >
>> > dkg, I told you :)
>> 
>> I don't think this is the same problem.  knot-resolver 1.5.0-1 already
>> patches around the upstream problem Ondřej points to with:
>> 
>> 
>> https://anonscm.debian.org/git/pkg-dns/knot-resolver.git/tree/debian/patches/0002-work-around-https-gitlab.labs.nic.cz-knot-knot-resol.patch
>> 
>> It builds cleanly on my own amd64 cowbuilder instance.  I think this
>> should be a giveback for the amd64 buildd network, to see if it repeats.
>
> Given back.

ok, it failed again on x86-csail-01 (same buildd as the first failure).
So it's probably not a transient failure on that machine.  is there a
way to see whether some other amd64 build daemon can take it back?

The package builds fine on the other architectures, though.

I've just pushed 1.5.0-3, which hopefully contains a much more verbose
attempt to run the test that appears to be failing, maybe we can see
where it aborts on x86-csail-01.

   --dkg

signature.asc
Description: PGP signature

Bug#881531: libreoffice: Bad rendering of LibreOffice buttons and some other widgets

2017-11-12 Thread Q4OS Team


Package: libreoffice-kde
Version: 1:5.2.7-1
Severity: normal

This bug is related to KDE Plasma DE. If I set "Windows" style in KDE 
systemsettings and run LibreOffice, all buttons and some other widgets 
are rendered without border.


Exact steps to reproduce:
- A fresh Debian 9.2 Stretch stable installation with KDE Plasma, 64bit
- Set the "Windows" style in KDE systemsettings
- Run LibreOffice > Open file
- Bug: All buttons have no border and look ugly

Bug#881530: d-i.debian.org: Setting the 'grub-installer/bootdev' preseed variable affects more than its desired role.

2017-11-12 Thread Q4OS Team


Package: d-i.debian.org
Severity: normal
Tags: d-i

When I specify in my preseeding file:
  d-i grub-installer/bootdev string default
grub-installer doesn't provide a query to install grub at all, and 
rewrites mbr with no question, even an other OS is already installed on 
disk. Installer also ignores "grub-installer/with_other_os" and 
"grub-installer/only_debian" variables, when they are set.


Steps to reproduce:
- Run installer from regular Debian installation media on a non-uefi system.
- Specify 'grub-installer/bootdev=default' preseed variable as kernel 
paramenter for installer.

- Proceed Debian installation, grub will be written to mbr without a query.

Bug#857228: Wayland vs X Windows

2017-11-12 Thread Barak A. Pearlmutter

Additional bit of info: when using the above Gnome keybinding for F12,
and when guake is set up to make the window visible on the screen the
mouse is on, guake doesn't notice that the mouse has switched to a
different screen should such motion have occurred entirely within a
Wayland window. Presumably for the same reason xeyes stops tracking
the mouse while the mouse is inside a Wayland window.

Bug#881528: bnd: Please update to 3.5.0 or more recent releases

2017-11-12 Thread Miguel Landaeta

Package: src:bnd
Version: 2.4.1-7
Severity: wishlist

As title says.

More upstream projects (e.g. jruby) are depending on recent releases
of this tool and although I still can get them to build with the
version available in the archive, I believe is time to update this
package.

I understand is not a straightforward update so I'm willing to
collaborate in this effort if needed.



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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US:en (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)

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#881529: maven-bundle-plugin: Please package 3.3.0 or latest releases

2017-11-12 Thread Miguel Landaeta

Package: src:maven-bundle-plugin
Version: 2.5.4-6
Severity: wishlist

As title says.

More upstream projects (e.g. jruby) are depending on recent releases
of this plugin and although I still can get them to build with the
version available in the archive, I believe it's time to update this
package.

I understand is not a straightforward update so I'm willing to
collaborate on this effort if needed.


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE=en_US:en (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)

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#879027: libtomcrypt: FTBFS on x32: final link failed: Bad value

2017-11-12 Thread Michael Stapelberg

Sorry, I just realized we don’t actually have an x32 porterbox listed
at https://db.debian.org/machines.cgi.

ucko, what’s the procedure here? How can Steffen get access to a
machine on which to reproduce this issue?

Thanks.

On Fri, Nov 10, 2017 at 5:30 PM, Michael Stapelberg
 wrote:
> You can get a guest account on Debian porter machines (we have one for
> each architecture which Debian supports). Please follow
> https://dsa.debian.org/doc/guest-account/, I’m happy to sponsor your
> request.
>
> On Fri, Nov 10, 2017 at 5:26 PM, Steffen Jaeckel  wrote:
>> On 10/18/2017 05:31 PM, Michael Stapelberg wrote:
>>> [+cc steffen, karel]
>>>
>>> Any clues about this build failure?
>>>
>>> On Wed, Oct 18, 2017 at 8:22 AM, Aaron M. Ucko  wrote:
 Source: libtomcrypt
 Version: 1.18-1
 Severity: important
 Justification: fails to build from source (but built successfully in the 
 past)
 User: debian-...@lists.debian.or

 The latest build of libtomcrypt for x32 (admittedly not a release
 architecture) failed per the below excerpts from
 https://buildd.debian.org/status/fetch.php?pkg=libtomcrypt=x32=1.18.0-1=1508165690=0:

   libtool: compile:  gcc -I./src/headers/ -Wall -Wsign-compare -Wshadow 
 -DLTC_SOURCE -Wextra -Wsystem-headers -Wbad-function-cast -Wcast-align 
 -Wstrict-prototypes -Wpointer-arith -Wdeclaration-after-statement 
 -Wwrite-strings -Wno-type-limits -O3 -funroll-loops -fomit-frame-pointer 
 -DGIT_VERSION=\"1.18.0\" -g -O2 -fdebug-prefix-map=/<>=. 
 -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
 -Werror=format-security -DGMP_DESC -DLTM_DESC -DUSE_LTM -Wdate-time 
 -D_FORTIFY_SOURCE=2 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro 
 -Wl,-z,now -c src/ciphers/aes/aes.c  -fPIC -DPIC -o 
 src/ciphers/aes/.libs/aes.o
   [...]
   libtool --mode=link --tag=CC gcc -I./src/headers/ -Wall -Wsign-compare 
 -Wshadow -DLTC_SOURCE -Wextra -Wsystem-headers -Wbad-function-cast 
 -Wcast-align -Wstrict-prototypes -Wpointer-arith 
 -Wdeclaration-after-statement -Wwrite-strings -Wno-type-limits -O3 
 -funroll-loops -fomit-frame-pointer -DGIT_VERSION=\"1.18.0\" -g -O2 
 -fdebug-prefix-map=/<>=. 
 -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
 -Werror=format-security -DGMP_DESC -DLTM_DESC -DUSE_LTM -Wdate-time 
 -D_FORTIFY_SOURCE=2  -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro 
 -Wl,-z,now src/ciphers/aes/aes.lo src/ciphers/aes/aes_enc.lo 
 src/ciphers/anubis.lo [...] src/stream/sober128/sober128_test.lo -lgmp 
 -ltommath -o libtomcrypt.la -rpath /usr/local/lib -version-info 1:0
   libtool: link: gcc -shared  -fPIC -DPIC  src/ciphers/aes/.libs/aes.o 
 src/ciphers/aes/.libs/aes_enc.o src/ciphers/.libs/anubis.o [...] 
 src/stream/sober128/.libs/sober128_test.o   -lgmp -ltommath  -O3 -g -O2 
 -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong 
 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro -Wl,-z -Wl,now   
 -Wl,-soname -Wl,libtomcrypt.so.1 -o .libs/libtomcrypt.so.1.0.0
   /usr/bin/ld: src/ciphers/aes/.libs/aes.o: relocation R_X86_64_PC32 
 against symbol `rijndael_setup' can not be used when making a shared 
 object; recompile with -fPIC
   /usr/bin/ld: final link failed: Bad value
   collect2: error: ld returned 1 exit status

 I'm not sure why the linker's complaining about missing an option you
 did in fact supply, but perhaps the use of pie-*.specs is somehow
 throwing things off; please try forgoing PIE on x32 for now.

 Thanks!

 --
 Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
 http://www.mit.edu/~amu/ | 
 http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
>>
>> Any updates on this?
>>
>> I built the library with x32 support on my local machine and that
>> works as expected
>>
>>> $ file .libs/test
>>> .libs/test: ELF 32-bit LSB executable, x86-64, version 1 (SYSV),
>> dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux
>> 3.4.0, BuildID[sha1]=e747673ddc8a354679b2e0f97b12886a7c6273c2, not stripped
>>> $ gcc -dumpversion
>>> 5.4.0
>>
>>
>> Can I somehow create this exact environment locally so I can try to
>> reproduce?
>>
>> --
>> Steffen Jaeckel - s_jaec...@gmx.de
>> GnuPG fingerprint:  C438 6A23 7ED4 3A47 5541 B942 7B2C D0DD 4BCF F59B
>> My OTR key has changed on 30. Sept. 2015!
>> jabber: jaec...@jabber.ccc.de F052DE29 4FA9A02D 44A794E5 AE5AC0FB C5865C64
>
>
>
> --
> Best regards,
> Michael



-- 
Best regards,
Michael

Bug#881527: qemu: FTCBFS due to broken cross build depend on glusterfs-common

2017-11-12 Thread Héctor Orón Martínez

Source: qemu
Version: 1:2.10.0+dfsg-2
Severity: normal

Dear Maintainer,

  Your package fails to satisfy cross build dependency installability due to 
glusterfs-common not being installable via multiarch:
  * https://bootstrap.debian.net/cross_all/qemu.html
  * DebianBug#881526

  You might want to consider disabling glusterfs-common build dependency for 
the cross build case, otherwise your package seems to cross build fine.

Regards

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

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

Bug#881526: glusterfs-common: split package into many (-dev,python-,-bin/-tools/-utils)

2017-11-12 Thread Héctor Orón Martínez

Package: glusterfs-common
Version: 3.12.2-2
Severity: normal

Dear Maintainer,

  Attempting to cross build QEmu, when installing cross build
dependencies, it results in uninstallability issues with
glusterfs-common. Main issue we have here is that package needs to be
splitted in different packages to be able to mark them accordingly
Multi-Arch: same or foreign. The package contains:
  * headers and .a need to go into -dev shared libraries named libfooN
(I believe those need to be marked multiarch same)
  * python modules need to be shipped into python-foo package
  * tools need to go into -bin/-tools/-utils (I believe that should be
marked multiarch foreign)

Regards

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

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

-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

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

2017-11-12 Thread Herbert Fortes

Hi,

As Dererk  said, pynmea2 is
in Debian already.

https://packages.debian.org/python-nmea2

This bug (ITP and RFS) can be closed by email:

bugnumber-d...@bugs.debian.org



Regards,
Herbert

Bug#880884: marked as done (qtav: Adapt to libva 2)

2017-11-12 Thread Sebastian Ramacher

Control: reopen -1

On 2017-11-10 21:51:03, Debian Bug Tracking System wrote:
> Your message dated Fri, 10 Nov 2017 21:49:51 +
> with message-id 
> and subject line Bug#880884: fixed in qtav 1.12.0+ds-3
> has caused the Debian Bug report #880884,
> regarding qtav: Adapt to libva 2
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 880884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880884
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Sun, 5 Nov 2017 07:41:36 -0500
> From: Jeremy Bicha 
> To: submit 
> Subject: qtav: Adapt to libva 2
> Message-ID: 
> 
> 
> Source: qtav
> Version: 1.12.0+ds-2
> Severity: serious
> 
> The libva transition has started [1]. qtav has hard-code dependencies
> on old libva libraries.
> 
> I don't know if it would help, but you should check if you can use dh_libva 
> [2].
> 
> One more thing: could you consider only building qtav on architectures
> where i965-va-driver is available (amd64 and i386)? I can file a
> separate bug for that if you want.
> 
> [1] https://bugs.debian.org/880355
> [2] https://manpages.debian.org/dh_libva
> 
> Thanks,
> Jeremy Bicha

> Date: Fri, 10 Nov 2017 21:49:51 +
> From: Pino Toscano 
> To: 880884-cl...@bugs.debian.org
> Subject: Bug#880884: fixed in qtav 1.12.0+ds-3
> Message-Id: 
> 
> Source: qtav
> Source-Version: 1.12.0+ds-3
> 
> We believe that the bug you reported is fixed in the latest version of
> qtav, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 880...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Pino Toscano  (supplier of updated qtav package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> We believe that the bug you reported is fixed in the latest version of
> qtav, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 880...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Pino Toscano  (supplier of updated qtav package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Fri, 10 Nov 2017 22:36:00 +0100
> Source: qtav
> Binary: libqtav1 libqtavwidgets1 libqtav-dev libqtav-private-dev 
> qml-module-qtav qtav-players
> Architecture: source
> Version: 1.12.0+ds-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Qt extras Maintainers 
> Changed-By: Pino Toscano 
> Description:
>  libqtav-dev - QtAV development files
>  libqtav-private-dev - QtAV private development files
>  libqtav1   - QtAV library
>  libqtavwidgets1 - QtAV Widgets module
>  qml-module-qtav - QtAV QML module
>  qtav-players - QtAV/QML players
> Closes: 880884
> Changes:
>  qtav (1.12.0+ds-3) unstable; urgency=medium
>  .
>* Team upload.
>  .
>[ Steve M. Robbins ]
>* Update standards-version to 4.1.1.  Add Vcs-* fields.
>  .
>[ Pino Toscano ]
>* Remove manual library and va-driver dependencies. (Closes: #880884)

I am afraid that this change is not enough. qtav still needs to be ported to the
new libva. Currently it links libva2, but dlopens libva.so.1, libva-x11.so.1,
and maybe others. It would now need to dlopen libva.so.2, libva-x11.so.2, and so
on. Hence I'm reopening this bug.

Cheers

>* Specify the buildsystem as qmake.
>* Use dh_auto_configure in its override.
>* Link in as-needed mode.
> Checksums-Sha1:
>  f1ad877aea60819a5992ec8461d79a61ad1c5979 2513 qtav_1.12.0+ds-3.dsc
>

Bug#881524: graphicsmagick: CVE-2017-13134

2017-11-12 Thread Salvatore Bonaccorso

Source: graphicsmagick
Version: 1.3.26-18
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for graphicsmagick.

CVE-2017-13134[0]:
| In ImageMagick 7.0.6-6 and GraphicsMagick 1.3.26, a heap-based buffer
| over-read was found in the function SFWScan in coders/sfw.c, which
| allows attackers to cause a denial of service via a crafted file.

In this case upstream has decided to use the same CVE as the patched
code is basically the same still after forking. That's in general
after confirmation from MITRE: "If the GraphicsMagick author chooses
to use a CVE ID that was originally created for ImageMagick, then we
would not create an additional ID." This is just to clarify why we
have same CVEs here for src:imagemagick and src:graphicsmagick.

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-2017-13134
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13134
[1] http://hg.code.sf.net/p/graphicsmagick/code/rev/1b47e0078e05

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#881525: RFS: python-ck/1.9.4

2017-11-12 Thread Grigori Fursin


Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

  I am looking for a sponsor for my package "python-ck"

 * Package name    : python-ck
   Version : 1.9.4
   Upstream Author : Grigori Fursin 
 * URL : https://github.com/ctuning/ck
 * License : BSD-3-Clause
   Section : python

  It builds those binary packages:

  python-ck  - Python2 light-weight knowledge manager
  python3-ck - Python3 light-weight knowledge manager

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


https://mentors.debian.net/package/python-ck


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


    dget -x 
https://mentors.debian.net/debian/pool/main/p/python-ck/python-ck_1.9.4.dsc


  More information about CK can be obtained from http://cKnowledge.org

  Changes since the last upload:

 * many aggregated fixes since 1.7.2
   See https://github.com/ctuning/ck/blob/master/CHANGES.txt

  Regards,
   Grigori Fursin

Bug#881471: chromium translates tilde to underscore when downloading from packages.debian.org

2017-11-12 Thread Phil Wyett

Side note: Also affects Google Chrome.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A

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

Bug#879030: 375.82-5: glxgears segmentation fault in glXCreateContext

2017-11-12 Thread Luca Boccassi

On Sun, 2017-11-12 at 19:37 +0200, Vincas Dargis wrote:
> On 2017.11.12 19:21, Luca Boccassi wrote:
> > > Please note it's on Testing, not Sid if that makes difference.
> > 
> > Ok, thanks for trying. Buster and Sid have the same versions right
> > now
> > so it's ok. I'll try to have a look at why apt is failing like
> > that.
> > 
> 
> Sorry for little off-topic, but what's difference between primus-
> libs:i386 and primus-libs-ia32?

The second one is right now an empty metapackage that depends on the
first one. In the old days there was no multiarch, so to allow co-
installing libraries there were these pkg-foo-ia32 packages.

-- 
Kind regards,
Luca Boccassi

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

Bug#864927: Can we get a simple fix for #864927 into unstable/testing please?

2017-11-12 Thread Lisandro Damián Nicanor Pérez Meyer

Hi!

El 11 nov. 2017 6:14 p.m., "Steve McIntyre"  escribió:

On Sat, Nov 11, 2017 at 03:25:29PM -0500, Lou Poppler wrote:
>This seems to be OK as of the weekly testing live build of Nov 5, 2017,
with
>plasma-desktop-data (4:5.10.5-2)
>
>That live build boots OK here.

kde-l10n has been removed from testing, and that looks to have solved
the live build problem. Doesn't like the best of ways, maybe?

I *think* there are stuff in NEW still preventing Maxy from uploading to
unstable.

Bug#737623: [git-buildpackage/master] changelog: handle comma in maintainers name

2017-11-12 Thread Guido Günther

tag 737623 pending
thanks

Date:   Sun Nov 12 18:38:41 2017 +0100
Author: Guido GÃ¼nther 
Commit ID: 3b5a7ddbe6f230bcb659104765a2da0837a3f283
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=3b5a7ddbe6f230bcb659104765a2da0837a3f283
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=3b5a7ddbe6f230bcb659104765a2da0837a3f283

changelog: handle comma in maintainers name

Thanks: Andreas Beckmann for the proposed fix
Closes: #737623

Bug#881523: libdevil-dev: pkgconf libs for ILUT invalid

2017-11-12 Thread Andrew Domaszek

Package: libdevil-dev
Version: 1.7.8-10+b2
Severity: normal

Dear Maintainer,

`pkgconf -libs ILUT` produces invalid linking flags related to ILU, 
specifically -ILU instead of -lILU. When passed to gcc, this results in missing 
symbols when linking and an extraneous include search dir.

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

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

Versions of packages libdevil-dev depends on:
ii  libdevil1c2 1.7.8-10+b2
ii  liblcms2-dev2.8-4
ii  libtiff5-dev [libtiff-dev]  4.0.8-2+deb9u1

libdevil-dev recommends no packages.

libdevil-dev suggests no packages.

-- no debconf information

1 2 3 >

1 - 100 of 231 matches

Mail list logo