Bug#912285: mtools: New upstream release

[Chris Lamb]

Chris Lamb wrote:

> New upstream 4.0.20 release is available at:
> 
>   http://lists.gnu.org/archive/html/info-mtools/2018-11/msg4.html

Another newer upstream 4.0.21 release is available at:

  http://lists.gnu.org/archive/html/info-mtools/2018-11/msg9.html

May I upload?


Regards,

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

Bug#505857: debian-watch-file-should-mangle-version doesn't detect dversionmangle=auto

[Chris Lamb]

Hi Bertrand,

> Lintian also doesn't detect dversionmangle=auto in debian/watch and 
> reports a warning for this (see [2]).

Hm, can you quickly confirm you are using the latest Lintian? This should
have been fixed via #913761 in:

  
https://salsa.debian.org/lintian/lintian/commit/b1308b369b98985c46d050fb7604f4272abd066b

… which should probably be merged into this bug too (unless I'm
missing something).


Best wishes,

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

Bug#914577: RFP: dropwatch -- A tool for detecting and diagnosing packets being dropped

[Dean Hamstead]

Package: wnpp
Severity: wishlist

* Package name: dropwatch
  Version : 1.5
  Upstream Author : Neil Horman 
* URL : https://github.com/nhorman/dropwatch
* License : GPL
  Programming Lang: C
  Description : A tool for detecting and diagnosing packets being dropped

What is Dropwatch? Dropwatch is a project I started in an effort to improve the 
ability for developers and system administrator to diagnose problems in the 
Linux Networking stack, specifically in our ability to diagnose where packets 
are getting dropped. From my probing, I've come to the conclusion that there 
are four main shortcommings in our current environment:

1.Consolidation, or lack thereof. Currently, if you would like to check on 
the status of dropped packets in the kernel, you need to check at least 3 
places, and possibly more: The /proc/net/snmp file, the netstat utility, the tc 
utility, and ethool. This project aims to consolidate several of those checks 
into one tool, making it easier for a sysadmin or developer to detect lost 
packets

2.Clarity of information. Dropped packets are not obvious. a sysadmin needs 
to be intimately familiar with each of the above tools to understand which 
events or statistics correlate to a dropped packet and which do not. While that 
is often self evident, it is also often not. Dropwatch aims to improve that 
clarity

3.Ambiguity. Even when a dropped packet is detected, the causes for those 
dropped packets are not always clear. Does a UDPInError mean the application 
receive buffer was full, or does it mean its checksum was bad? Dropwatch 
attempts to disambiguate the causes for dropped packets.

4.Performance. Utilties can be written to aggregate the data in the various 
other utilities to solve some of these problems, but such solutions require 
periodic polling of several interfaces, which is far from optimal, especially 
when lost packets are rare. This solution improves on the performance aspect by 
implementing a kernel feature which allows asyncronous notification of dropped 
packets when they happen.

Bug#914513: TR : boost python

[PICCA Frederic-Emmanuel]

Hello,

thanks for this initiativ.

1) I think that it would be nice also to deal with the python-dbg interpreter.


2) I do not know how, but in order to use boost_python and friends from 
setup.py we need to code the naming scheme.
someting like this in pytango

# Linux distribution
distribution = distro.linux_distribution()[0].lower() if POSIX else ""
distribution_match = lambda names: any(x in distribution for x in names)
DEBIAN = distribution_match(['debian', 'ubuntu', 'mint'])
REDHAT = distribution_match(['redhat', 'fedora', 'centos', 'opensuse'])
GENTOO = distribution_match(['gentoo'])


# special boost-python configuration

BOOST_ROOT = os.environ.get('BOOST_ROOT')
boost_library_name = 'boost_python'
if BOOST_ROOT is None:
if DEBIAN:
suffix = "-py{v[0]}{v[1]}".format(v=PYTHON_VERSION)
boost_library_name += suffix
elif REDHAT:
if PYTHON3:
boost_library_name += '3'
elif GENTOO:
suffix = "-{v[0]}.{v[1]}".format(v=PYTHON_VERSION)
boost_library_name += suffix
else:
inc_dir = os.path.join(BOOST_ROOT, 'include')
lib_dirs = [os.path.join(BOOST_ROOT, 'lib')]
if IS64:
lib64_dir = os.path.join(BOOST_ROOT, 'lib64')
if os.path.isdir(lib64_dir):
lib_dirs.insert(0, lib64_dir)

directories['include_dirs'].append(inc_dir)
directories['library_dirs'].extend(lib_dirs)

directories['libraries'].append(boost_library_name)


So my question is it would be nice to have something upstreamed which allows
to configure the boost_python name for a given interpreter. This would simplify 
work for upstream and distributions.


Cheers

Frederic

Bug#822761: Xfce bug 12832

[Fabrice Delliaux]

It's Xfce bug 12832 [1].
The patch was released into Xfdesktop 4.12.4 [2].

1. https://bugzilla.xfce.org/show_bug.cgi?id=12832
2. https://git.xfce.org/xfce/xfdesktop/log/?h=xfce-4.12

Bug#914578: heat: [INTL:de] Initial German debconf translation

[Dr. Tobias Quathamer]

Source: heat
Severity: wishlist
Tags: l10n patch

Hi,

please find attached an initial German deconf translation, proofread on
our mailing list.

Regards,
Tobias
# Copyright © 2018 Dr. Tobias Quathamer 
# This file is distributed under the same license as the heat package.
#
# Dr. Tobias Quathamer , 2018.
msgid ""
msgstr ""
"Project-Id-Version: heat\n"
"Report-Msgid-Bugs-To: h...@packages.debian.org\n"
"POT-Creation-Date: 2018-11-21 13:32+0100\n"
"PO-Revision-Date: 2018-11-25 10:28+0100\n"
"Last-Translator: Dr. Tobias Quathamer \n"
"Language-Team: German \n"
"Language: de_DE\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: string
#. Description
#: ../heat-common.templates.in:1001
msgid "Heat domain administrator username:"
msgstr "Benutzername des Heat-Domain-Administrators:"

#. Type: string
#. Description
#: ../heat-common.templates.in:1001
msgid "Please enter the username of the Heat domain administrator."
msgstr "Bitte geben Sie den Benutzernamen des Heat-Domain-Administrators ein."

#. Type: password
#. Description
#: ../heat-common.templates.in:2001
msgid "Heat domain administrator password:"
msgstr "Passwort des Heat-Domain-Administrators:"

#. Type: password
#. Description
#: ../heat-common.templates.in:2001
msgid "Please enter the password of the Heat domain administrator."
msgstr "Bitte geben Sie das Passwort des Heat-Domain-Administrators ein."

#. Type: string
#. Description
#: ../heat-common.templates.in:3001
msgid "Heat domain:"
msgstr "Heat-Domain:"

#. Type: string
#. Description
#: ../heat-common.templates.in:3001
msgid "Please enter domain name which will be used as heat domain."
msgstr ""
"Bitte geben Sie den Domain-Namen ein, der als Heat-Domain verwendet werden "
"soll."


signature.asc
Description: OpenPGP digital signature

Bug#914550: borgbackup needs to be rebuilt for python 3.7

[Adrian Bunk]

On Sat, Nov 24, 2018 at 08:21:21PM +0100, Albert Dengg wrote:
> Package: borgbackup
> Version: 1.1.7-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> since the update to python 3.7 in debian unstable, borg is uninstable.
> 
> a simple rebuild of the package seems to be enough to get a working
> package.

Thanks for your report.

The rebuild scheduling will be handled in #913069.

> regards,
> albert dengg

cu
Adrian

-- 

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

Bug#914579: open-infrastructure-storage-tools: French debconf templates translation

[Jean-Philippe MENGUAL]

Package: open-infrastructure-storage-tools
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


Please find attached the french debconf templates translation, proofreadby the 
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# French translation of open-infrastructure-storage-tools debconf templates.
# Copyright (C) 2017, 2018 French l10n Team 

# This file is distributed under the same license as the 
open-infrastructure-storage-tools package.
#
# Translators:
# Jean-Paul Guillonneau , 2017.
# Jean-Philippe MENGUAL , 2018.
msgid ""
msgstr ""
"Project-Id-Version: open-infrastructure-storage-tools\n"
"Report-Msgid-Bugs-To: open-infrastructure-storage-to...@packages.debian.org\n"
"POT-Creation-Date: 2017-04-09 19:17+0200\n"
"PO-Revision-Date: 2018-11-19 14:39+0100\n"
"Last-Translator: Jean-Phillippe MENGUAL \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: title
#. Description
#: ../open-infrastructure-storage-tools.templates:1001
msgid "storage-tools: Setup"
msgstr "storage-tools : configuration"

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:2001
msgid "ceph-log:"
msgstr "ceph-log :"

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:2001
msgid "ceph-log stores Ceph cluster log as a logfile, see ceph-log(1)."
msgstr ""
"ceph-log journalise la grappe Ceph dans un fichier d’historique, consulter "
"ceph-log(1)."

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:2001
msgid "Should ceph-log be enabled?"
msgstr "Faut-il activer ceph-log ?"

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:3001
msgid "ceph-info:"
msgstr "ceph-info :"

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:3001
msgid ""
"ceph-info shows Ceph cluster information as a HTML page, see ceph-info(1)."
msgstr ""
"ceph-info affiche les informations de la grappe Ceph sous la forme d'une page"
"HTML, voir ceph-info(1)."

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:3001
msgid "Should ceph-info be enabled?"
msgstr "Faut-il activer ceph-info ?"

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:4001
msgid "cephfs-snap:"
msgstr "cephfs-snap :"

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:4001
msgid "cephfs-snap creates CephFS snapshots periodically, see cephfs-snap(1)."
msgstr ""
"Cephfs-snap crée des instantanés CephFS de manière périodique, consulter "
"cephfs-snap(1)."

#. Type: boolean
#. Description
#: ../open-infrastructure-storage-tools.templates:4001
msgid "Should cephfs-snap be enabled?"
msgstr "Faut-il activer cephfs-snap ?"

#. Type: string
#. Description
#: ../open-infrastructure-storage-tools.templates:5002
msgid "cephfs-snap directories:"
msgstr "Répertoires de cephfs-snap :"

#. Type: string
#. Description
#: ../open-infrastructure-storage-tools.templates:5002
msgid ""
"Please specify the directories (space separated) where CephFS are mounted "
"that should be snapshoted."
msgstr ""
"Veuillez indiquer les répertoires (séparés par des espaces) où CephFS est "
"monté et qui seront intégrés dans les instantanés."

#. Type: string
#. Description
#: ../open-infrastructure-storage-tools.templates:5002
msgid "If unsure, leave empty."
msgstr "En cas de doute, laisser la ligne vide."

#. Type: string
#. Default
#: ../open-infrastructure-storage-tools.templates:6001
msgid "169"
msgstr "169"

#. Type: string
#. Description
#: ../open-infrastructure-storage-tools.templates:6002
msgid "cephfs-snap hourly:"
msgstr "cephfs-snap par heure :"

#. Type: string
#. Description
#: ../open-infrastructure-storage-tools.templates:6002
msgid "Please specify the number of hourly snapshots that should be kept."
msgstr "Veuillez indiquer le nombre d’instantanés conservés par heure."

#. Type: string
#. Description
#: ../open-infrastructure-storage-tools.templates:600

Bug#505857: debian-watch-file-should-mangle-version doesn't detect dversionmangle=auto

[Bertrand Marc]

Hi Chris,

Le 25/11/2018 à 09:42, Chris Lamb a écrit :
> Hi Bertrand,
>
>> Lintian also doesn't detect dversionmangle=auto in debian/watch and 
>> reports a warning for this (see [2]).
> Hm, can you quickly confirm you are using the latest Lintian? This should
> have been fixed via #913761 in:
>
>   
> https://salsa.debian.org/lintian/lintian/commit/b1308b369b98985c46d050fb7604f4272abd066b
>
> … which should probably be merged into this bug too (unless I'm
> missing something).
>
>
> Best wishes,
>
Indeed, this is fixed with lintian 2.5.113.

Cheers,
Bertrand

Bug#914540: [20181124] mirrors.ocf.berkeley.edu: out of date, ftpsync-version

[Jason Perrin]

Hi Peter,

Thanks a lot for letting us know we are out of date!

We've switched our upstream mirror and are syncing again now.

We'll make sure to update our ftpsync version too, it's been on our roadmap
for a while now but just hasn't been done yet, so we'll look into that as
soon as we can.

Cheers,
Jason

On Sat, Nov 24, 2018 at 7:39 AM Peter Palfrader  wrote:

> Package: mirrors
> User: mirr...@packages.debian.org
> Usertags: mirror-problems
>
> Hi!
>
> It seems http://mirrors.ocf.berkeley.edu/debian/
> is out of date
>
> https://mirror-master.debian.org/status/mirror-info/mirrors.ocf.berkeley.edu.html
>
> Please investigate.
>
> o If you sync off kernel.org, you might want to pick a different site
>   (do not use ftp.*.debian.org names, only http is guaranteed at
>those names and they do switch around.)
>   https://mirror-master.debian.org/status/mirror-hierarchy.html might help
>   you pick.
>
> o Also, maybe update your ftpsync version.
>   http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
>
> Cheers,
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
>

Bug#914562: lintian: please decide on Debian Enhancement Proposal spelling (harmonise)

[Chris Lamb]

tags 914562 + pending
thanks

Thorsten Glaser wrote:

> Personally I’d prefer DEP-3, but the http://dep.debian.net/ site
> uses “DEP 3” spelling (with ASCII space in between), except in
> the URLs which have “dep3”.

I believe Lintian should treat dep.debian.net as the canonical
acronymisation at this point and adopt that. If there is a
consensus and enough hunger for this to change "upstream" then
Lintian will very adopt to it.

In that light, I've (at least) made it consistent here:

  
https://salsa.debian.org/lintian/lintian/commit/26ac5017d3e18ab9bdd0b8bafee9dd38a878f3be

  checks/patch-systems.desc   | 6 +++---
  checks/source-copyright.desc| 4 ++--
  checks/source-copyright.pm  | 4 ++--
  debian/changelog| 4 
  .../patch-systems-dpatch-description/debian/patches/05_dep3.diff| 2 +-
  t/tests/source-copyright-boilerplate-uri/desc   | 2 +-
  t/tests/source-copyright-dep5-general/desc  | 2 +-
  t/tests/source-copyright-dep5-syntax-error/desc | 2 +-
  t/tests/source-copyright-ood-uri/desc   | 2 +-
  t/tests/source-copyright-typo-field/desc| 2 +-
  t/tests/source-copyright-unknown-uri/desc   | 2 +-
  t/tests/source-copyright-unversioned-uri/desc   | 2 +-
  t/tests/source-copyright-wiki-uri/desc  | 2 +-
  13 files changed, 20 insertions(+), 16 deletions(-)


Best wishes,

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

Bug#912779: [src:mumble] FTBFS with boost1.67

[Adrian Bunk]

Control: forwarded -1 https://github.com/mumble-voip/mumble/issues/3281
Control: fixed -1 1.3.0~2868~g44b9004+dfsg-1

On Wed, Nov 07, 2018 at 07:47:00AM +, Chris Knadle wrote:
> Giovanni Mascellani:
> > Dear Maintainer,
> > 
> > your package fails to build with boost1.67. You can find a build log
> > attached. If you want to attempt the build yourself, an updated version
> > of boost-defaults which brings in boost1.67 dependencies can be found
> > adding this line to your sources.list file:
> > 
> >   deb https://people.debian.org/~gio/reprepro unstable main
> > 
> > This bug has severity whishlist for the moment, but it will raised to RC
> > as soon as version 1.67 of Boost is promoted to default.
> > 
> > I have to say I do not completely understand why the package built fine
> > with previous version of boost (1.62): it seems to me that the problem
> > the attached patch fixes (the use of std::abs as a templated name, see
> > the path description for more details) should not depend at all from
> > boost. However, at least on my computer, the package builds with
> > boost1.62, fails with boost1.67 and build with boost1.67 and this patch.
> > 
> > Please consider applying the attached patch as soon as boost1.67 is made
> > default in order to avoid FTBFS.
> > 
> > Thanks and all the best, Giovanni.
> 
> Hello, Giovanni.
> 
> Thank you very much for your detailed bug report that includes build logs and 
> a
> patch.  :)
> 
> I reviewed the build logs and the patch.  I took some time to understand what
> static_cast does in the patch, because I think I haven't seen that 
> before.
> 
>https://stackoverflow.com/questions/28002/regular-cast-vs-static-cast-vs-
> dynamic-cast
>https://en.cppreference.com/w/cpp/language/static_cast
> 
> At least initially the patch looks right to me.  I'll include this patch in 
> the
> next upload.  Thanks.

The upstream fix for this bug is
https://github.com/mumble-voip/mumble/commit/ea861fe86743c8402bbad77d8d1dd9de8dce447e

>-- Chris

cu
Adrian

-- 

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

Bug#914513: TR : boost python

[Giovanni Mascellani]

Hi,

thanks for your suggestions, however...

Il 25/11/18 10:06, PICCA Frederic-Emmanuel ha scritto:
> 1) I think that it would be nice also to deal with the python-dbg interpreter.

I never used python-dbg and I don't really know what I can do here.

> 2) I do not know how, but in order to use boost_python and friends from 
> setup.py we need to code the naming scheme.
> someting like this in pytango
> 
> [...]
>
> So my question is it would be nice to have something upstreamed which allows
> to configure the boost_python name for a given interpreter. This would 
> simplify work for upstream and distributions.

I'd say that of all this script the only part that is meaningful to
retain in Debian is this:


directories['libraries'].append('boost_python-py{v[0]}{v[1]}'.format(v=PYTHON_VERSION))

If there is any sensible location I can put this for setup.py to
automatically pick it up, I can do this, but I am not an expert of
setup.py, so I do not know how to cook this up. I can also put this line
in an example file in the package, for easing the life of other Python
extension maintainers. Other than that, I do not really know what to do.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#912284:

[vitalijs grabovskijs]

Bug#914580: wsjtx: binary-any FTBFS

[Adrian Bunk]

Source: wsjtx
Version: 1.8.0+repack-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=wsjtx&suite=sid

...
   debian/rules override_dh_installdocs
make[1]: Entering directory '/<>/wsjtx-1.8.0+repack'
# Fix font-awesome from cloudflare
sed -i -e 
's/https:\/\/cdnjs.cloudflare.com\/ajax\/libs\/font-awesome\/4.7.0\/css\/font-awesome.min.css/\/usr\/share\/fonts-font-awesome\/css\/font-awesome.min.css/g'
 \
debian/wsjtx-doc/usr/share/doc/wsjtx/wsjtx-main-1.8.0.html
sed: can't read debian/wsjtx-doc/usr/share/doc/wsjtx/wsjtx-main-1.8.0.html: No 
such file or directory
make[1]: *** [debian/rules:33: override_dh_installdocs] Error 2


This can be reproduced with
  dpkg-buildpackage -B

Bug#914581: adios: use dh_auto_build/dh_auto_install for the C parts

[Pino Toscano]

Source: adios
Version: 1.13.1-10
Severity: wishlist
Tags: patch

Hi,

currently, the build/installation of the C components is done by
manually invoking 'make' in the build directories.  Let's just use
dh_auto_build, and dh_auto_install, so it respects more debhelper
configurations, such as the number of parallel jobs.

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -113,10 +113,10 @@ endif
 override_dh_auto_build:
# First do a build shared, with -fPIC, for the python lib.
 ifneq (,$(findstring $(ARCH),$(MPICHARCHS)))
-   $(MAKE) -C build-mpich CFLAGS='$(CFLAGS) -fPIC' VERBOSE=1 
+   dh_auto_build --builddirectory=build-mpich -- CFLAGS='$(CFLAGS) -fPIC' 
VERBOSE=1
 endif
 ifneq (,$(findstring $(ARCH),$(OMPIARCHS)))
-   $(MAKE) -C build-openmpi CFLAGS='$(CFLAGS) -fPIC' VERBOSE=1 
+   dh_auto_build --builddirectory=build-openmpi -- CFLAGS='$(CFLAGS) 
-fPIC' VERBOSE=1
 endif
# Need to hack the libs into the right place, to match adios_configs 
view
# as this is then used by setup.py
@@ -146,7 +146,7 @@ override_dh_auto_install:
mkdir -p $(BINDIR) debian/tmp/usr/lib/python3/dist-packages 
$(DESTDIR)/usr/etc
mkdir -p debian/tmp/usr/lib/python2.7/dist-packages
 ifneq (,$(findstring $(ARCH),$(MPICHARCHS)))
-   $(MAKE) -C build-mpich install VERBOSE=1 DESTDIR=$(TOP)/debian/tmp/mpich
+   dh_auto_install --builddirectory=build-mpich 
--destdir=$(TOP)/debian/tmp/mpich -- VERBOSE=1
install -D -m 644  build-mpich/adios.pc 
$(TOP)/debian/tmp/$(LIBDIR)/pkgconfig/adios-mpich.pc
for p in $(PY2VERS) $(PY3VERS) ; do \
( cd build-mpich/numpy && \
@@ -167,7 +167,7 @@ ifneq (,$(findstring $(ARCH),$(MPICHARCH
cp -a debian/tmp/mpich/usr/etc/skel $(DESTDIR)/usr/etc/skel.mpich
 endif
 ifneq (,$(findstring $(ARCH),$(OMPIARCHS)))
-   $(MAKE) -C build-openmpi install  VERBOSE=1 
DESTDIR=$(TOP)/debian/tmp/openmpi
+   dh_auto_install --builddirectory=build-openmpi 
--destdir=$(TOP)/debian/tmp/openmpi -- VERBOSE=1
install -D -m 644  build-openmpi/adios.pc 
debian/tmp/$(LIBDIR)/pkgconfig/adios-openmpi.pc
# Sort python stuff
for p in $(PY2VERS) $(PY3VERS) ; do \

Bug#914583: vim-pathogen: Depend on vim compiled with Python support

[Heinrich Schuchardt]

Package: vim-pathogen
Version: 2.4-1
Severity: normal

Dear Maintainer,

vim-pathogen requires vim to be compiled with Python support. Currently
this package has vim as dependency. But 'apt-get install vim' installs
a basic version of vim without Python support.

So we need a dependency like

vim-gnome || vim-gtk || vim-gtk3 || vim-athena || vin-nox

Best regards

Heinrich

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


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

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

Versions of packages vim-pathogen depends on:
ii  vim2:8.1.0320-1+b1
ii  vim-addon-manager  0.5.9
ii  vim-gtk [vim]  2:8.1.0320-1+b1

Versions of packages vim-pathogen recommends:
ii  vim-scripts  20180807

vim-pathogen suggests no packages.

-- no debconf information

Bug#914582: liblingua-en-fathom-perl: Fails to build due to unmet build dependecies

[Hans Joachim Desserud]

Package: liblingua-en-fathom-perl
Version: 1.22-1
Severity: serious
Tags: ftbfs

Dear Maintainer,

When attempting to build this package, installing build dependencies 
fails

because liblingua-en-sentence-perl doesn't seem to exist in Debian.

$ sudo apt build-dep liblingua-en-fathom-perl
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:liblingua-en-fathom-perl : Depends: 
liblingua-en-sentence-perl but it is not installable

E: Unable to correct problems, you have held broken packages.


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#904162: yubikey-luks: keyscript not run during boot

[Jordan Glover]

This bug is fixed upstream with:
https://github.com/cornelinux/yubikey-luks/commit/e6c20a349b0d7f3d02c69bf86ef2ab179691bb1e

which don't rely on cryptsetup package internals anymore but needs manual 
system config adjustment.

There are also couple more fixes in master, including debian downstream 
patches. You may consider syncing upstream master with debian if you want to 
make new release in debian.

Jordan

Bug#914419: debhelper mustn't set pass V to make

[Niels Thykier]

Adrian Bunk:
> Package: debhelper
> Version: 11.5.2
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apcupsd.html
> 
> ...
> dh clean --with autoreconf
>dh_auto_clean
>   make V=1 -j16 clean
> make[1]: Entering directory '/build/1st/apcupsd-3.14.14'
> 1find . -depth \
>   \( -name  -o -name  -o -name \*.a \) \
>   -exec  "  CLEAN" \{\} \; -exec  \{\} \;
> /bin/sh: 1: 1find: not found
> make[1]: *** [autoconf/targets.mak:98: clean] Error 127
> 
> 
> https://sources.debian.org/src/apcupsd/3.14.14-2/autoconf/targets.mak/#L98
> 
> 
> Using V=1 for getting verbose build output is a relatively
> recent convention followed by some software.
> 
> It is not something that is safe to use everywhere.
> 

Hi,

Adding Luca to this report as it affect a change by Luca.

@Luca: What is your take on this?  Should we roll back on this, guard it
by a compat level or something else?

Thanks,
~Niels

Bug#914373: octave-statistics: accessing installed functions is needlessly obscure

[Rafael Laboissière]

* James Van Zandt  [2018-11-24 18:03]:

I don't see why a Readme.DEBIAN file in each package would be 
difficult to manage.  If needed, it could be generic, with the 
same text in each package, such as:


   By default installed packages are not available from the Octave
   prompt.  The functions from this package can be added to the Octave
   path by typing

pkg load 

   at the Octave command line.


It is not a matter of *difficulty*, but a matter of *maintainability*. 
Currently in Debian, there are over 60 Octave-Forge packages [1] and all 
of tehm would be impacted by the change.  We, the developers of the DOG, 
do such distribution-wide changes only when it is extremely necessary.


At any rate, We have already changed the README.Debian file of the octave 
package [2].  We hope that it is enough, for now.


[1] https://qa.debian.org/developer.php?email=team%2Bpkg-octave-team%40tracker.debian.org 
[2] https://salsa.debian.org/pkg-octave-team/octave/commit/987627f214beabe6cc20df19227d4b960ac7ee3a


I note a discussion of autoloading packages here: 
http://octave.1599824.n4.nabble.com/package-autoload-td4676287.html


particularly a comment by LachlanA;

My personal belief is that the __unimplemented__ function, which 
currently tells us which package we should load, should just load 
the package and continue (unless the same function is implemented 
in multiple packages, in which case it should list all of those 
packages and give an error).


That would most closely emulate the Matlab experience, while 
avoiding the problems Carnë described.


I would appreciate that.  However, I'd be satisfied if the 
__unimplemented__ function simply knew about all the functions available in 
packages.  (Currently it doesn't - the subject of another bug).


This is an upstream issue.  Whatever default behavior the upstream 
authors decide to adopt, the DOG will follow.


Best,

Rafael

Bug#914584: [naev] Missing package relations

[Bruno Kleinert]

Package: naev
Version: 0.7.0-1
Severity: normal

--- Please enter the report below this line. ---
Hello Federico,

naev-data should suggest naev, while naev should depend on naev-data. I
fixed it in the attached dependencies.debdiff.

Cheers - Bruno

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-2-amd64

Debian Release: buster/sid
  500 unstable-debug  deb.debian.org 
  500 unstabledeb.debian.org 
1 experimental-debug deb.debian.org 
1 experimentaldeb.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
libbinutils (>= 2.31.1) | 2.31.1-8
libbinutils (<< 2.31.2) | 2.31.1-8
libc6 (>= 2.17) | 2.27-8
libfreetype6 (>= 2.2.1) | 2.9.1-3
libgl1  | 1.1.0-1
libglu1-mesa| 9.0.0-2.1
 OR libglu1 | 
liblua5.1-0 | 5.1.5-8.1+b2
libopenal1(>= 1.14) | 1:1.19.1-1
libpng16-16(>= 1.6.2-1) | 1.6.34-2
libsdl2-2.0-0(>= 2.0.8) | 2.0.8+dfsg1-6
libvorbis0a  (>= 1.1.2) | 1.3.6-1
libvorbisfile3   (>= 1.2.3) | 1.3.6-1
libxml2  (>= 2.7.4) | 2.9.4+dfsg1-7+b2
zlib1g (>= 1:1.1.4) | 1:1.2.11.dfsg-1
naev-data   (= 0.7.0-2) | 0.7.0-2


Package's Recommends field is empty.

Package's Suggests field is empty.



diff -Nru naev-0.7.0/debian/changelog naev-0.7.0/debian/changelog
--- naev-0.7.0/debian/changelog	2018-08-23 20:14:01.0 +0200
+++ naev-0.7.0/debian/changelog	2018-11-25 10:58:12.0 +0100
@@ -1,3 +1,9 @@
+naev (0.7.0-2) UNRELEASED; urgency=medium
+
+  * Add package relations between binary packages naev and naev-data
+
+ -- Bruno "Fuddl" Kleinert   Sun, 25 Nov 2018 10:58:12 +0100
+
 naev (0.7.0-1) unstable; urgency=medium
 
   * Initial release (Closes: #523834)
diff -Nru naev-0.7.0/debian/control naev-0.7.0/debian/control
--- naev-0.7.0/debian/control	2018-08-23 20:14:01.0 +0200
+++ naev-0.7.0/debian/control	2018-11-25 10:58:12.0 +0100
@@ -24,7 +24,8 @@
 
 Package: naev
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
+ naev-data (= ${source:Version})
 Description: 2D action/rpg space game
  2D space trading and combat game, in a similar vein to Escape Velocity. Naev
  is played from a top-down perspective, featuring fast-paced combat, many
@@ -34,6 +35,7 @@
 Package: naev-data
 Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Suggests: naev
 Description: 2D action/rpg space game - game data
  2D space trading and combat game, in a similar vein to Escape Velocity. Naev
  is played from a top-down perspective, featuring fast-paced combat, many


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

Bug#914373: octave-statistics: accessing installed functions is needlessly obscure

[Rafael Laboissière]

Control: found -1 4.4.1-2

Bug#914585: mathgl: qtwebengine5-dev is not available on all architectures

[Adrian Bunk]

Source: mathgl
Version: 2.4.2.1-2
Severity: serious
Tags: ftbfs

qtwebengine5-dev is only available on the following architectures:
  amd64 arm64 armhf i386 mipsel

mathgl tries qtwebengine5-dev first with a fallback to libqt5webkit5-dev,
which gives two possible solutions:

1. If using qtwebengine5-dev instead of libqt5webkit5-dev does
   not bring any significant improvements, it would be easiest
   to go back to using libqt5webkit5-dev on all architectures.

OR

2. Use qtwebengine5-dev where available and libqt5webkit5-dev
   everywhere else, by changing the build dependency to
 qtwebengine5-dev [amd64 arm64 armhf i386 mipsel]

Bug#914419: debhelper mustn't set pass V to make

[Luca Boccassi]

On Sun, 25 Nov 2018, 11:30 Niels Thykier  Adrian Bunk:
> > Package: debhelper
> > Version: 11.5.2
> > Severity: serious
> >
> >
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apcupsd.html
> >
> > ...
> > dh clean --with autoreconf
> >dh_auto_clean
> >   make V=1 -j16 clean
> > make[1]: Entering directory '/build/1st/apcupsd-3.14.14'
> > 1find . -depth \
> >   \( -name  -o -name  -o -name \*.a \) \
> >   -exec  "  CLEAN" \{\} \; -exec  \{\} \;
> > /bin/sh: 1: 1find: not found
> > make[1]: *** [autoconf/targets.mak:98: clean] Error 127
> >
> >
> >
> https://sources.debian.org/src/apcupsd/3.14.14-2/autoconf/targets.mak/#L98
> >
> >
> > Using V=1 for getting verbose build output is a relatively
> > recent convention followed by some software.
> >
> > It is not something that is safe to use everywhere.
> >
>
> Hi,
>
> Adding Luca to this report as it affect a change by Luca.
>
> @Luca: What is your take on this?  Should we roll back on this, guard it
> by a compat level or something else?
>
> Thanks,
> ~Niels
>

Hi Niels and Adrian,

Before considering other options, would using VERBOSE=1 instead of V=1
work? I'm afk until later today so I can't check right now if gmake accepts
it, iirc it does but I could be confusing it with other tools.

Kind regards,
Luca Boccassi

>

Bug#908890: developers-reference: As alioth is gone, replace references to Salsa

[Holger Wansing]

Control: tags -1 + pending

On Fri, 16 Nov 2018 20:31:18 +0100 Holger Wansing  wrote:
> 
> Tobias Frost created a merge request for this, under
> https://salsa.debian.org/debian/developers-reference/merge_requests/6
> 
> 
> Any objections against me merging this?

I have merged this now.

Tagging this bug as pending



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#914586: xfe FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: xfe
Version: 1.42.1-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

The patch for #892445 included in version 1.42.1-1 regressed cross
building of xfe. It now uses the wrong pkg-config. The attached patch
fixes that. Please consider applying it.

Helmut
--- xfe-1.42.1.orig/configure.ac
+++ xfe-1.42.1/configure.ac
@@ -29,6 +29,7 @@
 AC_PROG_INSTALL
 AC_PROG_LN_S
 AC_PROG_MAKE_SET
+PKG_PROG_PKG_CONFIG
 
 
 # Internationalization
@@ -119,11 +120,9 @@
 	  CPPFLAGS="$freetype_cflags $CPPFLAGS"
 	else
 		# On some systems freetype-config is deprecated and pkg-config should be used instead
-		pkg_config=''
-		AC_CHECK_PROGS(pkg_config,pkg-config,)
-		if test -n "$pkg_config"; then
-		  freetype_cflags=`$pkg_config --cflags freetype2`
-		  freetype_libs=`$pkg_config --libs  freetype2`
+		if test -n "$PKG_CONFIG"; then
+		  freetype_cflags=`$PKG_CONFIG --cflags freetype2`
+		  freetype_libs=`$PKG_CONFIG --libs  freetype2`
 		  LIBS="$LIBS $freetype_libs"
 		  CPPFLAGS="$freetype_cflags $CPPFLAGS"
 		fi
@@ -141,11 +140,9 @@
 	  CXXFLAGS="${CXXFLAGS} -DHAVE_XFT_H"
 	else
 		# On some systems xft-config is deprecated and pkg-config should be used instead
-		pkg_config=''
-		AC_CHECK_PROGS(pkg_config,pkg-config,)
-		if test -n "$pkg_config"; then
-		  xft_cflags=`$pkg_config --cflags xft`
-		  xft_libs=`$pkg_config --libs xft`
+		if test -n "$PKG_CONFIG"; then
+		  xft_cflags=`$PKG_CONFIG --cflags xft`
+		  xft_libs=`$PKG_CONFIG --libs xft`
 		  LIBS="$LIBS $xft_libs"
 		  CPPFLAGS="$xft_cflags $CPPFLAGS"
 		  CXXFLAGS="${CXXFLAGS} -DHAVE_XFT_H"

Bug#914419: debhelper mustn't set pass V to make

[Adrian Bunk]

On Sun, Nov 25, 2018 at 11:58:57AM +, Luca Boccassi wrote:
> On Sun, 25 Nov 2018, 11:30 Niels Thykier  
> > Adrian Bunk:
> > > Package: debhelper
> > > Version: 11.5.2
> > > Severity: serious
> > >
> > >
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apcupsd.html
> > >
> > > ...
> > > dh clean --with autoreconf
> > >dh_auto_clean
> > >   make V=1 -j16 clean
> > > make[1]: Entering directory '/build/1st/apcupsd-3.14.14'
> > > 1find . -depth \
> > >   \( -name  -o -name  -o -name \*.a \) \
> > >   -exec  "  CLEAN" \{\} \; -exec  \{\} \;
> > > /bin/sh: 1: 1find: not found
> > > make[1]: *** [autoconf/targets.mak:98: clean] Error 127
> > >
> > >
> > >
> > https://sources.debian.org/src/apcupsd/3.14.14-2/autoconf/targets.mak/#L98
> > >
> > >
> > > Using V=1 for getting verbose build output is a relatively
> > > recent convention followed by some software.
> > >
> > > It is not something that is safe to use everywhere.
> > >
> >
> > Hi,
> >
> > Adding Luca to this report as it affect a change by Luca.
> >
> > @Luca: What is your take on this?  Should we roll back on this, guard it
> > by a compat level or something else?
> >
> > Thanks,
> > ~Niels
> >
> 
> Hi Niels and Adrian,

Hi Luca,

> Before considering other options, would using VERBOSE=1 instead of V=1
> work? I'm afk until later today so I can't check right now if gmake accepts
> it, iirc it does but I could be confusing it with other tools.

make happily accepts them, but this misses the problem.

None of these options is supported directly by make.

make just passes such options to the package-specific
Makefile that might do something or nothing with them.

> Kind regards,
> Luca Boccassi

cu
Adrian

-- 

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

Bug#914587: blueman: broken package

[Stephan Lachnit]

Package: blueman
Version: 2.0.6-1
Severity: grave
Tags: newcomer
Justification: renders package unusable

Dear Maintainer,

this package has wrong python dependencies. It should depend on the python3.6
package or python3 (< 3.7), because it doesn't install on latest Debian Sid
(unstable).



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

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

Versions of packages blueman depends on:
ii  bluez 5.50-1
ii  bluez-obexd   5.50-1
ii  dbus  1.12.10-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-1
pn  gir1.2-appindicator3-0.1  
ii  gir1.2-gdkpixbuf-2.0  2.38.0+dfsg-6
ii  gir1.2-glib-2.0   1.58.0-1
ii  gir1.2-gtk-3.03.24.1-2
ii  gir1.2-notify-0.7 0.7.7-3
ii  gir1.2-pango-1.0  1.42.4-4
ii  gnome-icon-theme  3.12.0-3
ii  libbluetooth3 5.50-1
ii  libc6 2.27-8
ii  libglib2.0-0  2.58.1-2
ii  libpulse-mainloop-glib0   12.2-2
ii  libpython3.6  3.6.7-1
ii  librsvg2-common   2.44.9-1
ii  notification-daemon   3.20.0-3
ii  python3   3.7.1-2
ii  python3-cairo 1.16.2-1+b1
ii  python3-dbus  1.2.8-2+b1
ii  python3-gi3.30.2-1
ii  python3-gi-cairo  3.30.2-1
ii  xfce4-notifyd [notification-daemon]   0.4.2-1

Versions of packages blueman recommends:
ii  policykit-1  0.105-21
ii  pulseaudio-module-bluetooth  12.2-2

blueman suggests no packages.

Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"

[Didier 'OdyX' Raboud]

Le vendredi, 12 octobre 2018, 18.56:40 h CET Brian Potkin a écrit :
> The CreateIPPPrinterQueues works very nicely with remote print queues.
> A permanent local queue is created which can be printed to using lp or
> the GTK, Qt and Libreoffice dialogs.
> 
> When dealing with a remote IPP printer the situation is different, as
> described in #905850 and #908604:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905850
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908604
> 
> Unlike a print queue, the queue for an IPP printer is temporary and
> disappears within a minute from the 'lpstat -a' output and from a GTK
> dialog (but not from Qt and Libreoffice dialogs). Very confusing for
> a user, I would have thought. CreateIPPPrinterQueues is not sufficient
> for a permanent queue to be created.
> 
> The temporary nature of a printer queue is not documented and neither
> is the solution, setting UseCUPSGeneratedPPDs to "No".

My understanding is that the current default for UseCUPSGeneratedPPDs is
set to Yes; 


https://sources.debian.org/src/cups-filters/1.21.3-3/utils/cups-browsed.c/#L391

https://sources.debian.org/src/cups-filters/1.21.3-3/utils/cups-browsed.conf.in/#L347

Are you asking to swap it to be "No"?

@Till: would this make sense upstream?

Cheers,
OdyX

Bug#914514: atop: should use logrotate for log rotation

[Marc Haber]

severity #914514 wishlist
thanks

On Sat, Nov 24, 2018 at 12:53:13AM -0800, Jade McCormick wrote:
> Can this package use logrotate like other debian packages? It's confusing, 
> and then to discover that
> /usr/share/atop/atop.daily is executed from a shell script in the background, 
> made me think
> that atop log handling could be greatly improved.

I'd rather not open this can of worms again, there are many things to
get wrong. Please consider discussion this with upstream. I do see the
advantages of using logrotate, but there's no compelling reason to
deviate so far away from the way upstream does it yet.

Greetings
Marc

Bug#914588: normaliz FTCBFS: AC_RUN_IFELSE

[Helmut Grohne]

Source: normaliz
Version: 3.6.3+ds-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

normaliz fails to cross build from source, because it uses AC_RUN_IFELSE
to find a library. Normally, I'd just switch that to AC_LINK_IFELSE, but
the comments kindly explain thet AC_RUN_IFELSE is needed for Mac OS X.
Bummer. So let me propose a compromise: Use AC_RUN_IFELSE with a cross
branch that uses AC_LINK_IFELSE. So the native case continues working as
is and the cross case works everywhere but Mac OS X.

The patch doesn't completely fix the build. Running help2man still
breaks cross compilation. This one is difficult and there is no silver
bullet. The options essentially are:
 * Don't use help2man.
 * Move the manual page to an arch:all package.
 * Perform the build twice (native and cross).
 * Ship a precompiled manual page in the source.
 * Skip building a manual page with the nodoc profile.

Still applying my patch makes that problem visible, so please consider
applying it and close this bug when doing so.

Helmut
--- normaliz-3.6.3+ds.orig/configure.ac
+++ normaliz-3.6.3+ds/configure.ac
@@ -140,7 +140,20 @@
 	AC_MSG_RESULT([yes, using $SCIP_LIBS])
 	break
 	   ],
-	   [have_scip=no])
+	   [have_scip=no],
+	   [AC_LINK_IFELSE(
+	 [AC_LANG_PROGRAM([[#include 
+   ]],
+			[[ SCIP* scip = NULL;
+			   SCIPcreate(& scip);
+			   return 0;
+			 ]])],
+	 [have_scip=yes
+	  AC_MSG_RESULT([yes (cross guess), using $SCIP_LIBS])
+	  break
+	 ],
+	 [have_scip=no])
+	   ])
  done
  LIBS="$LIBS_SAVED"
  if test $have_scip != yes ; then

Bug#505857: debian-watch-file-should-mangle-version doesn't detect dversionmangle=auto

[Mattia Rizzolo]

Control: found -1 2.5.112
Control: notfound -1 2.5.113
Control: close -1 2.5.113

On Sun, Nov 25, 2018 at 10:46:19AM +0100, Bertrand Marc wrote:
> Indeed, this is fixed with lintian 2.5.113.

Then please try to pay attention to the bug metadata you write while
filing bugs, you explicitly wrote "Version: 2.5.113".

I'm closing this bug as fixed in 2.5.113.  I see it was open ten years
ago, and many things changed since then.  I believe the original report
was also taken care of, and if there are still false positives for this
specific tag I recommend people to open new bugs clarifying what syntax
they are using.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914589: [naev] Missing desktop menu icon

[Bruno Kleinert]

Package: naev
Version: 0.7.0-1
Severity: normal

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

in desktop environments' menus, no application icon is displayed for
Naev because the icon isn't installed. Please find attached a debdiff
that adds the icon to the naev binary package.

Additionally, I included a patch that adds a German translation to the
desktop file.

Cheers - Bruno

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-2-amd64

Debian Release: buster/sid
  500 unstable-debug  deb.debian.org 
  500 unstabledeb.debian.org 
1 experimental-debug deb.debian.org 
1 experimentaldeb.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
libbinutils (>= 2.31.1) | 2.31.1-8
libbinutils (<< 2.31.2) | 2.31.1-8
libc6 (>= 2.17) | 2.27-8
libfreetype6 (>= 2.2.1) | 2.9.1-3
libgl1  | 1.1.0-1
libglu1-mesa| 9.0.0-2.1
 OR libglu1 | 
liblua5.1-0 | 5.1.5-8.1+b2
libopenal1(>= 1.14) | 1:1.19.1-1
libpng16-16(>= 1.6.2-1) | 1.6.34-2
libsdl2-2.0-0(>= 2.0.8) | 2.0.8+dfsg1-6
libvorbis0a  (>= 1.1.2) | 1.3.6-1
libvorbisfile3   (>= 1.2.3) | 1.3.6-1
libxml2  (>= 2.7.4) | 2.9.4+dfsg1-7+b2
zlib1g (>= 1:1.1.4) | 1:1.2.11.dfsg-1
naev-data   (= 0.7.0-2) | 0.7.0-2


Package's Recommends field is empty.

Package's Suggests field is empty.



diff -Nru naev-0.7.0/debian/changelog naev-0.7.0/debian/changelog
--- naev-0.7.0/debian/changelog	2018-08-23 20:14:01.0 +0200
+++ naev-0.7.0/debian/changelog	2018-11-25 13:08:35.0 +0100
@@ -1,3 +1,11 @@
+naev (0.7.0-2) UNRELEASED; urgency=medium
+
+  * Install application icon for desktop menu entry.
+  * 002-desktop-file-german-translation.diff: Add German desktop file
+translation.
+
+ -- Bruno "Fuddl" Kleinert   Sun, 25 Nov 2018 13:08:35 +0100
+
 naev (0.7.0-1) unstable; urgency=medium
 
   * Initial release (Closes: #523834)
diff -Nru naev-0.7.0/debian/naev.install naev-0.7.0/debian/naev.install
--- naev-0.7.0/debian/naev.install	2018-08-23 20:14:01.0 +0200
+++ naev-0.7.0/debian/naev.install	2018-11-25 13:08:35.0 +0100
@@ -1,5 +1,6 @@
 debian/tmp/usr/bin/naev usr/games
 debian/tmp/usr/share/appdata/naev.appdata.xml usr/share/metainfo
+extras/logos/naev.png usr/share/pixmaps
 usr/share/applications/naev.desktop
 usr/share/doc/naev
 usr/share/man/man6
diff -Nru naev-0.7.0/debian/patches/002-desktop-file-german-translation.diff naev-0.7.0/debian/patches/002-desktop-file-german-translation.diff
--- naev-0.7.0/debian/patches/002-desktop-file-german-translation.diff	1970-01-01 01:00:00.0 +0100
+++ naev-0.7.0/debian/patches/002-desktop-file-german-translation.diff	2018-11-25 13:08:35.0 +0100
@@ -0,0 +1,15 @@
+Index: naev-0.7.0/naev.desktop
+===
+--- naev-0.7.0.orig/naev.desktop	2017-07-02 02:40:29.0 +0200
 naev-0.7.0/naev.desktop	2018-11-25 13:07:16.093676199 +0100
+@@ -3,8 +3,10 @@
+ Name=Naev
+ GenericName=Naev
+ Comment=2D action/rpg space trading combat game
++Comment[de]=2D Weltraum Action-/Rollenspiel mit Handels- und Kampfelementen
+ Icon=naev
+ Exec=naev
+ Categories=Game;AdventureGame;
+ Terminal=false
+ Keywords=2D;action;rpg;space;trading;combat;game;
++Keywords[de]=2D;Action;Rollenspiel;Weltraum;Handel;Kampf;Spiel;
diff -Nru naev-0.7.0/debian/patches/series naev-0.7.0/debian/patches/series
--- naev-0.7.0/debian/patches/series	2018-08-23 20:14:01.0 +0200
+++ naev-0.7.0/debian/patches/series	2018-11-25 13:08:35.0 +0100
@@ -1 +1,2 @@
 001-disable-zip
+002-desktop-file-german-translation.diff


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

Bug#914554: clxclient FTBFS: freetype-config not found

[Mattia Rizzolo]

On Sun, Nov 25, 2018 at 10:51:22AM +, Hugh McMaster wrote:
> clxclient (build-)depends on libxft-dev, which depends on libfreetype6-dev.
> So, it looks like clxclient used the secondary dependency to
> get access to freetype-config.

Even so, it tries to use stuff provided by libfreetype6-dev
directly, so it also should have a direct build-depdency.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914370: cups-daemon: AppArmor profile allows cupsd to create setuid binaries under /etc

[Didier 'OdyX' Raboud]

Control: tags -1 +confirmed +help

Le jeudi, 22 novembre 2018, 19.05:19 h CET deb...@dbwats.plus.com a écrit :
> The AppArmor profile supplied with cupsd isn't much use against local
> attackers, as it allows cupsd to create setuid binaries at paths it
> can write to (e.g. under /etc/cups).  Since cupsd is run as root by
> default, these binaries can be setuid root.
> 
> (…)
> 
> In default installations /etc is not on a nosuid mount, so provided
> that they have a suitable exploit, local attackers who are unconfined
> but non-root can use cupsd to create a setuid binary, then run the
> binary themselves to gain unconfined root privileges.

As I only have vague understanding of AppArmor; I'll welcome help / patches.

@Intri: any insight in how to address this?

Cheers,
OdyX

Bug#914591: stretch-pu: package python-cryptography/1.7.1-3

[Sebastian Andrzej Siewior]

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

With the intention of pushing OpenSSL 1.1.0j into Stretch here is the
proposed change for python-cryptography.
The package python-cryptography fails to build due to an API change of
BIO_callback_ctrl() in OpenSSL. While this is a no-no in a stable
release, it has been explained [0] that the function / callback was
always used with a different prototype. I fixed this by removing the
function / prototype from the python wrapper while upstream removed the
almost all BIO related wrappers [1].
I did a rebuild of python-cryptography's rdeps in Stretch against OpenSSL
1.1.0i and the proposed package with no fallout [2].

Any feedback from the python team is welcome.

[0] https://github.com/openssl/openssl/pull/4493#discussion_r143505277
[1] https://github.com/pyca/cryptography/pull/4220
[2] 
https://breakpoint.cc/openssl-rebuild/2018-09-02-rebuild-stretch-python-cryptography/

Sebastian
diff -Nru python-cryptography-1.7.1/debian/changelog python-cryptography-1.7.1/debian/changelog
--- python-cryptography-1.7.1/debian/changelog	2017-05-28 04:20:33.0 +0200
+++ python-cryptography-1.7.1/debian/changelog	2018-09-02 15:17:35.0 +0200
@@ -1,3 +1,11 @@
+python-cryptography (1.7.1-3+deb9u1) unstable; urgency=medium
+
+  * Remove BIO_callback_ctrl: The prototype differs with the OpenSSL's
+definition of it after it was changed (fixed) within OpenSSL. It has no
+users.
+
+ -- Sebastian Andrzej Siewior   Sun, 02 Sep 2018 15:17:35 +0200
+
 python-cryptography (1.7.1-3) unstable; urgency=medium
 
   * Apply patch 6e7ea2e7 from upstream to fix compilation against OpenSSL
diff -Nru python-cryptography-1.7.1/debian/patches/Remove-BIO_callback_ctrl.patch python-cryptography-1.7.1/debian/patches/Remove-BIO_callback_ctrl.patch
--- python-cryptography-1.7.1/debian/patches/Remove-BIO_callback_ctrl.patch	1970-01-01 01:00:00.0 +0100
+++ python-cryptography-1.7.1/debian/patches/Remove-BIO_callback_ctrl.patch	2018-09-02 15:17:35.0 +0200
@@ -0,0 +1,52 @@
+From: Sebastian Andrzej Siewior 
+Date: Sun, 2 Sep 2018 15:00:43 +0200
+Subject: [PATCH] Remove BIO_callback_ctrl()
+
+This removes BIO_callback_ctrl(), bio_info_cb and its two users.
+This is the small version of #4220 ("Remove unused BIO bindings.").
+OpenSSL changed this type because it was wrong and the (now) different
+prototype fails to build.
+There should be users which rely on this function.
+
+Link: https://github.com/pyca/cryptography/pull/4220
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ src/_cffi_src/openssl/bio.py | 8 
+ 1 file changed, 8 deletions(-)
+
+diff --git a/src/_cffi_src/openssl/bio.py b/src/_cffi_src/openssl/bio.py
+index a134d9b605b0..c4aa88c5b075 100644
+--- a/src/_cffi_src/openssl/bio.py
 b/src/_cffi_src/openssl/bio.py
+@@ -10,7 +10,6 @@ INCLUDES = """
+ 
+ TYPES = """
+ typedef struct bio_st BIO;
+-typedef void bio_info_cb(BIO *, int, const char *, int, long, long);
+ typedef ... bio_st;
+ typedef ... BIO_METHOD;
+ typedef ... BUF_MEM;
+@@ -69,11 +68,6 @@ BIO *BIO_new_fp(FILE *, int);
+ BIO *BIO_new_fd(int, int);
+ BIO *BIO_new_socket(int, int);
+ long BIO_ctrl(BIO *, int, long, void *);
+-long BIO_callback_ctrl(
+-BIO *,
+-int,
+-void (*)(struct bio_st *, int, const char *, int, long, long)
+-);
+ long BIO_int_ctrl(BIO *, int, long, int);
+ size_t BIO_ctrl_pending(BIO *);
+ size_t BIO_ctrl_wpending(BIO *);
+@@ -125,8 +119,6 @@ int BIO_set_close(BIO *,long);
+ int BIO_get_close(BIO *);
+ int BIO_pending(BIO *);
+ int BIO_wpending(BIO *);
+-int BIO_get_info_callback(BIO *, bio_info_cb **);
+-int BIO_set_info_callback(BIO *, bio_info_cb *);
+ long BIO_get_buffer_num_lines(BIO *);
+ long BIO_set_read_buffer_size(BIO *, long);
+ long BIO_set_write_buffer_size(BIO *, long);
+-- 
+2.11.0
+
diff -Nru python-cryptography-1.7.1/debian/patches/series python-cryptography-1.7.1/debian/patches/series
--- python-cryptography-1.7.1/debian/patches/series	2017-05-28 04:20:33.0 +0200
+++ python-cryptography-1.7.1/debian/patches/series	2018-09-02 15:17:12.0 +0200
@@ -1,2 +1,3 @@
 0001-add-memory-limit-check-for-scrypt.patch
 0002-fix-compilation-on-1.1.0f-3603.patch
+Remove-BIO_callback_ctrl.patch

Bug#914590: regression: parsing known_hosts is slow

[Timo Weingärtner]

Package: bash-completion
Version: 1:2.8-4
Severity: normal

Hi,

with the last upgrade of bash-completion completing hostnames has become
slow (takes more than two seconds). My /etc/ssh/ssh_known_hosts file has
quite some size (23084 lines / 12 MB), but this was not a problem with the 
previous
implementation.

I guess the problem is the while read … done < known_hosts_file loop, where
the shell has to read() one byte at a time, causing a massive amount of
syscalls (which have become even more costly this year).


Regards,
Timo

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

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

-- no debconf information

Bug#913517: hplip: patch to support IPv6

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix +upstream
Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1724089

Le dimanche, 11 novembre 2018, 20.47:12 h CET Christopher Martin a écrit :
> Please see https://bugs.launchpad.net/hplip/+bug/1724089 for the
> original report, which includes a patch that adds IPv6 support to
> libhpmud.
> 
> The patch ensures that libhpmud properly resolves IPv6 addresses and
> hostnames. I've tested it against the latest hplip (3.18.10) and it
> works well.
> 
> Please consider merging it into Debian's package.

This is really fondamentally something of upstream's realm, and (also given 
the remarks) I am not going to carry such a patch as distribution-specific 
patch, sorry.

Hereby marking as wontfix to make this decision clear.

Cheers,
OdyX

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone!

We the Qt maintainers have reached a decision with respect to this topic. We 
reached debian-devel in order to get an idea of what other fellow Debian users 
and developers think of this subject. We would *really* like to thank you all 
for chiming in and discussing this in quite a nice way. Yes, most of us have 
strong positions, but even then the discussion was both civil and fruitful. So 
again, thanks to you all!

It seems now clear that the general consensus seems to expect:

= Qt available for both Desktop and ES OpenGL flavours

As we tried hard to explain this is really not easy nor even supported by 
upstream. But of course, if someone thinks [s]he wants to take the effort then 
[s]he's more than welcomed to joining the team. You will certainly need C++ 
library packaging skills and a *whole lot* of free time and build power. Due 
to the nature of this change, if the goal is achieved, it will be certainly 
targeted for Buster+1.

= If no change is possible, keep arm64 with Desktop OpenGL support

That seems to be what most of you want, and to say the truth, the easiest for 
us: we just keep status quo, no transition needed. We just package the next 
point release, check for bugs and mostly be done for Buster. So this is the 
approach we will take.

Both Dmitry and I just learned that the RPI has the VC4 driver which enables 
it to do hardware acceleration for Desktop OpenGL, we must admit that this is 
a game changer in many ways, even if we are talking on just one board (but 
quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use 
Ubuntu.

For the Qt side of the Qt/KDE Team,

Lisandro

People reading the bug: please see

  

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


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

Bug#914592: Please consider to keep a 3.X version of python-pytest in Debian

[Ole Streicher]

Package: python-pytest
Version: 3.10-1
Severity: wishlist

Hi,

one of the central astronomy packages (python-astropy) just decided that
their Python 2 legacy branch 2.0.X will have a dependency on Pytest 3.x,
but remain incompatible to 4.0.

https://github.com/astropy/astropy/pull/8173

When pytest is upgraded to 4.0, I therefore have only the options to
disable testing in the Python 2 branch, or to remove the whole Astronomy
Python 2 ecosystem.

I could imagine that similar things happen to other Python 2 package
branches. This bug is therefore to discuss the possible choices and take
a general decision. I'll also send a ping to the mailing list.

Best

Ole

Bug#914593: mosquitto FTCBFS: uses the wrong compiler

[Helmut Grohne]

Source: mosquitto
Version: 1.5.4-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mosquitto fails to cross build from source, because it uses the build
architecture compiler as a make default. Using dh_auto_build fixes that
when using the makefile buildsystem, but mosquitto defaults to the cmake
build system. After passing --buildsystem=makefile to dh, dh_auto_build
does the right thing and the override_dh_auto_configure becomes
redundant. The attached patch makes mosquitto cross buildable. Please
consider applying it.

Helmut
diff --minimal -Nru mosquitto-1.5.4/debian/changelog 
mosquitto-1.5.4/debian/changelog
--- mosquitto-1.5.4/debian/changelog2018-11-08 14:34:59.0 +0100
+++ mosquitto-1.5.4/debian/changelog2018-11-25 13:56:45.0 +0100
@@ -1,3 +1,10 @@
+mosquitto (1.5.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Nov 2018 13:56:45 +0100
+
 mosquitto (1.5.4-1) unstable; urgency=medium
 
   * New upstream release (Closes: #911104).
diff --minimal -Nru mosquitto-1.5.4/debian/rules mosquitto-1.5.4/debian/rules
--- mosquitto-1.5.4/debian/rules2018-11-08 14:34:59.0 +0100
+++ mosquitto-1.5.4/debian/rules2018-11-25 13:56:43.0 +0100
@@ -5,16 +5,14 @@
 export libdir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-   dh $@
+   # Don't process CMake rules, CMakeLists.txt is only included for 
Windows/Mac support.
+   dh $@ --buildsystem=makefile
 
 override_dh_installchangelogs:
dh_installchangelogs ChangeLog.txt
 
-override_dh_auto_configure:
-   # Don't process CMake rules, CMakeLists.txt is only included for 
Windows/Mac support.
-
 override_dh_auto_build:
-   make WITH_BUNDLED_DEPS=no WITH_ADNS=yes WITH_WRAP=yes 
WITH_WEBSOCKETS=yes WITH_STRIP=no WITH_SYSTEMD=yes
+   dh_auto_build -- WITH_BUNDLED_DEPS=no WITH_ADNS=yes WITH_WRAP=yes 
WITH_WEBSOCKETS=yes WITH_STRIP=no WITH_SYSTEMD=yes
 
 override_dh_auto_test:
 

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Peter Lebbing]

Hi,

On 21/11/2018 17:46, Guilhem Moulin wrote:
> Peter last poked Werner on Nov 09 but there wasn't any reply from him.
> (At least not on the gnupg-users list.)

Nope, no reply, unfortunately.

> Hmm on second thought the offer is tempting; if you're also attending
> 35c3 then shipping won't even be necessary ;-)

I have once programmed GnuK into a very cheap Maple Mini clone for
somebody. He hasn't tried to use it yet, but I don't expect any issues.
It's not a really practical form-factor for mobile use (it needs a USB
cable, it's not a "stick" form), but for development on a desktop, it
should be fine.

I'll bring one programmed with GnuK to the 35C3. I also ordered another
ten; if they come over from China in time, I'll program them as well,
give you another one and pass them around to interested people.

These are the boards:


If you want to protect them a bit, just put some shrink tube around it.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature

Bug#880047: postgrey: Regression - Postgrey doesn't start after installing new stable proposed-update

[Adrian Bunk]

On Sat, Nov 10, 2018 at 01:37:20PM +, Roger Lynn wrote:
> On 08/11/18 19:34, Adrian Bunk wrote:
> > Tanks a lot for trying stretch-proposed-updates and reproting bugs you find!
> > 
> > This is a regression that is also in 1.36-5 in unstable.
> > 
> > The proposed 1.36-3+deb9u1 update has now been dropped from the upcoming
> > stretch point release.
> 
> Thank you for your work on this package. I think the reason my system was
> badly affected by the new release is because I had used the example unix
> socket location given in /usr/share/doc/postgrey/README.exim, which
> conflicted with the new directory created in the init script (although to be
> fair, the README does warn that the socket location might need to be
> changed).

I'd guess for stretch this just means that I'll prepare a 1.36-3+deb9u2
update that will revert to the situation 1.36-3 - I don't see any way
to make this change in a safe way for stable then.

> Regards,
> 
> Roger

Thanks again for reporting this issue
Adrian

-- 

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

Bug#914591: stretch-pu: package python-cryptography/1.7.1-3

[Sebastian Andrzej Siewior]

On 2018-11-25 13:49:15 [+0100], To sub...@bugs.debian.org wrote:

diff -Nru python-cryptography-1.7.1/debian/changelog 
python-cryptography-1.7.1/debian/changelog
--- python-cryptography-1.7.1/debian/changelog  2017-05-28 04:20:33.0 
+0200
+++ python-cryptography-1.7.1/debian/changelog  2018-09-02 15:17:35.0 
+0200
@@ -1,3 +1,11 @@
+python-cryptography (1.7.1-3+deb9u1) unstable; urgency=medium

Okay. This needs to be stretch and not unstable.

Sebastian

Bug#914594: stretch-pu, jessie-pu: package ssh-agent-filter/0.4.2-1,0.4-2

[Timo Weingärtner]

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

bug with potential security implications, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914501
diff -Nru ssh-agent-filter-0.4.2/debian/changelog ssh-agent-filter-0.4.2/debian/changelog
--- ssh-agent-filter-0.4.2/debian/changelog	2016-08-27 23:36:56.0 +0200
+++ ssh-agent-filter-0.4.2/debian/changelog	2018-11-24 01:46:12.0 +0100
@@ -1,3 +1,9 @@
+ssh-agent-filter (0.4.2-1+deb9u1) stretch; urgency=medium
+
+  * backport fix for two-byte out-of-bounds stack write (Closes: #914501)
+
+ -- Timo Weingärtner   Sat, 24 Nov 2018 01:46:12 +0100
+
 ssh-agent-filter (0.4.2-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru ssh-agent-filter-0.4.2/debian/gbp.conf ssh-agent-filter-0.4.2/debian/gbp.conf
--- ssh-agent-filter-0.4.2/debian/gbp.conf	2016-08-27 23:36:56.0 +0200
+++ ssh-agent-filter-0.4.2/debian/gbp.conf	2018-11-24 01:46:12.0 +0100
@@ -1,5 +1,5 @@
 [DEFAULT]
 upstream-branch=master
 upstream-tag=%(version)s
-debian-branch=debian
+debian-branch=debian-stretch
 pristine-tar=true
diff -Nru ssh-agent-filter-0.4.2/debian/patches/914501_fix_two-byte_oob_stack_write ssh-agent-filter-0.4.2/debian/patches/914501_fix_two-byte_oob_stack_write
--- ssh-agent-filter-0.4.2/debian/patches/914501_fix_two-byte_oob_stack_write	1970-01-01 01:00:00.0 +0100
+++ ssh-agent-filter-0.4.2/debian/patches/914501_fix_two-byte_oob_stack_write	2018-11-24 01:46:12.0 +0100
@@ -0,0 +1,26 @@
+Description: fix two-byte out-of-bounds stack write
+ BASE64_ENCODE_LENGTH() calculates the encoded size without padding
+Author: Timo Weingärtner 
+Origin: upstream, https://git.tiwe.de/ssh-agent-filter.git/commit/?id=87f2de93a6522bbcf17d1960e78641df8ecd85d3
+Bug-Debian: https://bugs.debian.org/914501
+Forwarded: not-needed
+Last-Update: 2018-11-24
+
+--- ssh-agent-filter-0.4.2.orig/ssh-agent-filter.C
 ssh-agent-filter-0.4.2/ssh-agent-filter.C
+@@ -116,12 +116,9 @@ string md5_hex (string const & s) {
+ }
+ 
+ string base64_encode (string const & s) {
+-	struct base64_encode_ctx ctx;
+-	base64_encode_init(&ctx);
+-	uint8_t b64[BASE64_ENCODE_LENGTH(s.size())];
+-	auto len = base64_encode_update(&ctx, b64, s.size(), reinterpret_cast(s.data()));
+-	len += base64_encode_final(&ctx, b64 + len);
+-	return {reinterpret_cast(b64), len};
++	uint8_t b64[BASE64_ENCODE_RAW_LENGTH(s.size())];
++	base64_encode_raw(b64, s.size(), reinterpret_cast(s.data()));
++	return {reinterpret_cast(b64), sizeof(b64)};
+ }
+ 
+ void cloexec (int fd) {
diff -Nru ssh-agent-filter-0.4.2/debian/patches/series ssh-agent-filter-0.4.2/debian/patches/series
--- ssh-agent-filter-0.4.2/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ ssh-agent-filter-0.4.2/debian/patches/series	2018-11-24 01:46:12.0 +0100
@@ -0,0 +1 @@
+914501_fix_two-byte_oob_stack_write
diff -Nru ssh-agent-filter-0.4/debian/changelog ssh-agent-filter-0.4/debian/changelog
--- ssh-agent-filter-0.4/debian/changelog	2014-10-21 17:40:14.0 +0200
+++ ssh-agent-filter-0.4/debian/changelog	2018-11-24 02:01:09.0 +0100
@@ -1,3 +1,9 @@
+ssh-agent-filter (0.4-2+deb8u1) jessie; urgency=medium
+
+  * backport fix for two-byte out-of-bounds stack write (Closes: #914501)
+
+ -- Timo Weingärtner   Sat, 24 Nov 2018 02:01:09 +0100
+
 ssh-agent-filter (0.4-2) unstable; urgency=medium
 
   * add debian/patches/0001-workaround-FTBFS-caused-by-doko:
diff -Nru ssh-agent-filter-0.4/debian/gbp.conf ssh-agent-filter-0.4/debian/gbp.conf
--- ssh-agent-filter-0.4/debian/gbp.conf	2014-10-21 17:40:14.0 +0200
+++ ssh-agent-filter-0.4/debian/gbp.conf	2018-11-24 02:01:09.0 +0100
@@ -1,5 +1,5 @@
 [DEFAULT]
 upstream-branch=master
 upstream-tag=%(version)s
-debian-branch=debian
+debian-branch=debian-jessie
 pristine-tar=true
diff -Nru ssh-agent-filter-0.4/debian/patches/914501_fix_two-byte_oob_stack_write ssh-agent-filter-0.4/debian/patches/914501_fix_two-byte_oob_stack_write
--- ssh-agent-filter-0.4/debian/patches/914501_fix_two-byte_oob_stack_write	1970-01-01 01:00:00.0 +0100
+++ ssh-agent-filter-0.4/debian/patches/914501_fix_two-byte_oob_stack_write	2018-11-24 02:01:09.0 +0100
@@ -0,0 +1,26 @@
+Description: fix two-byte out-of-bounds stack write
+ BASE64_ENCODE_LENGTH() calculates the encoded size without padding
+Author: Timo Weingärtner 
+Origin: upstream, https://git.tiwe.de/ssh-agent-filter.git/commit/?id=87f2de93a6522bbcf17d1960e78641df8ecd85d3
+Bug-Debian: https://bugs.debian.org/914501
+Forwarded: not-needed
+Last-Update: 2018-11-24
+
+--- ssh-agent-filter-0.4.2.orig/ssh-agent-filter.C
 ssh-agent-filter-0.4.2/ssh-agent-filter.C
+@@ -116,12 +116,9 @@ string md5_hex (string const & s) {
+ }
+ 
+ string base64_encode (string const & s) {
+-	struct base64_encode_ctx ctx;
+-	base64_encode_init(&ctx);
+-	uint8_t b64[BASE64_ENCODE_LENGTH(s.size())];
+-	auto len = base64_encode_update(&ctx, b64, 

Bug#914592: Upcoming pytest-4 problems

[Mattia Rizzolo]

On Sun, Nov 25, 2018 at 02:08:52PM +0100, Ole Streicher wrote:
> Pytest 4 is however the upcoming version, and I could imagine that
> others may have similar problems with Python 2 legacy. Therefore, my
> question is how these problems should be solved:
> 
> * creating a legacy version package for pytest

This means yet another split.
It feels to me that too many packages are going this route.

> * remove the tests for these packages
> 
> * remove the legacy packages in question completely

I'd follow these two options.  For now, disable the tests when pytest 4
will land in Debian, and be ready to remove the legacy packages as a
whole soon.

After all, we are going to remove python2 itself in the upcoming years,
it doesn't really feel worth of anybody's time to work on yet other
splits, especially in cases like this where you are "only" talking about
tests for legacy and deprecated versions.

> For us, the third option would basically mean to remove the whole Python
> 2 astronomy ecosystem, and we would need to hurry in making some general
> packages Python 3 compatible (mainly astrometry.net).

I recommend you urge that ecosystem to migrate their codebases.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914594: stretch-pu, jessie-pu: package ssh-agent-filter/0.4.2-1,0.4-2

[Adam D. Barratt]

Control: tags -1 - jessie
Control: retitle -1 stretch-pu: package ssh-agent-filter/0.4.2-1

On Sun, 2018-11-25 at 14:26 +0100, Timo Weingärtner wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: stretch jessie
> Severity: normal
> 
> bug with potential security implications, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914501

The Release Team hasn't handled updates to jessie for nearly 6 months
now - see https://www.debian.org/News/2018/20180623 (and even when it
did, updates to multiple suites have always required separate bugs).

Regards,

Adam

Bug#914587: blueman: broken package

[Adrian Bunk]

On Sun, Nov 25, 2018 at 01:17:57PM +0100, Stephan Lachnit wrote:
> Package: blueman
> Version: 2.0.6-1
> Severity: grave
> Tags: newcomer
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> this package has wrong python dependencies. It should depend on the python3.6
> package or python3 (< 3.7), because it doesn't install on latest Debian Sid
> (unstable).

Thanks for your report.

The rebuild scheduling will be handled in #913069.

cu
Adrian

-- 

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

Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"

[Brian Potkin]

On Fri 12 Oct 2018 at 17:56:40 +0100, Brian Potkin wrote:

> Package: cups-browsed
> Version: 1.21.3-1
> Severity: normal
> Tags: upstream
> 
> 
> The CreateIPPPrinterQueues works very nicely with remote print queues.
> A permanent local queue is created which can be printed to using lp or
> the GTK, Qt and Libreoffice dialogs.
> 
> When dealing with a remote IPP printer the situation is different, as
> described in #905850 and #908604:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905850
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908604
> 
> Unlike a print queue, the queue for an IPP printer is temporary and
> disappears within a minute from the 'lpstat -a' output and from a GTK
> dialog (but not from Qt and Libreoffice dialogs). Very confusing for
> a user, I would have thought. CreateIPPPrinterQueues is not sufficient
> for a permanent queue to be created.
> 
> The temporary nature of a printer queue is not documented and neither
> is the solution, setting UseCUPSGeneratedPPDs to "No".

Further researching this behaviour with CreateIPPPrinterQueues set
to "All" as before, I obtained the dnssd URI for the printer from
'lpinfo -v and set up a queue for it with

lpadmin -p 4500 -v dnssd://... -E -m 
driverless:ipp://envy4500.local:631/ipp/print

(Later on, -m everywhere was used with the same outcome as described
below).

'lpstat -l -e' shows the 4500 queue as permanent. Restarting
cups-browsed brings back the ENVY4500 queue. Far from disappearing
after a minute, this queue persists and is shown as permanent.

All well and good as an alternative workaround to previously, but I
do not really want two queues for the same printer. So the 4500 one
was deleted. This leads to ENVY4500 losing its permanent status.
However, the queue now persists and does not disappear after 1 min!
Until, that is, cups-browsed is restarted. Then it is back to the
going away behaviour.

Regards,

Brian.

Bug#914582: liblingua-en-fathom-perl: Fails to build due to unmet build dependecies

[gregor herrmann]

Control: tag -1 + pending

On Sun, 25 Nov 2018 11:46:25 +0100, Hans Joachim Desserud wrote:

> When attempting to build this package, installing build dependencies fails
> because liblingua-en-sentence-perl doesn't seem to exist in Debian.

It's already in the NEW queue, waiting for ftp-master approval:
https://ftp-master.debian.org/new/liblingua-en-sentence-perl_0.31-1.html
 
Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bettina Wegner: Der Fuehrer


signature.asc
Description: Digital Signature

Bug#749317: reassign to piuparts

[Holger Levsen]

control: reassign -1 src:piuparts
control: tags -1 + pending
thanks

/var/lib/debian-security-support is the home directory of the
debian-security-support user which rightfully is not removed on purge,
thus piuparts should ignore it.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#914595: ITP: fathom -- Library for probing Syzygy tablebases

[Jose G . López]

Package: wnpp
Severity: wishlist
Owner: Jose G. López 

* Package name: fathom
  Version : 1.0
  Upstream Author : basil00
* URL : https://github.com/basil00/Fathom
* License : MIT
  Programming Lang: C
  Description : Library for probing Syzygy tablebases

Fathom is a stand-alone Syzygy tablebase probing tool.
The aims of Fathom are:
- To make it easy to integrate the Syzygy tablebases into existing
chess engines.
- To make it easy to create stand-alone applications that use the
Syzygy tablebases.

It's a reqirement for packaging some current chess engines as they
are embedding this probe tool (arasan, ethereal for exmaple).

Bug#914596: python-casacore ftbfs with new casacore

[Matthias Klose]

Package: src:python-casacore
Version: 2.2.1-1
Severity: serious
Tags: sid buster

different error on amd64:

see
https://buildd.debian.org/status/fetch.php?pkg=python-casacore&arch=amd64&ver=2.2.1-1%2Bb2&stamp=1542542922&raw=0

pybuild --test -i python{version} -p "3.7 3.6"
I: pybuild base:217: cd /<>/.pybuild/cpython3_3.7_casacore/build;
python3.7 -m unittest discover -v
Segmentation fault
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=139: cd
/<>/.pybuild/cpython3_3.7_casacore/build; python3.7 -m unittest
discover -v
dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit code 
13
make: *** [debian/rules:8: build-arch] Error 25


all others:

powerpc64le-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-wz4KDq/python2.7-2.7.15=.
-fstack-protector-strong -Wformat -Werror=format-security -fexceptions
-Wl,-z,relro -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 build/temp.linux-ppc64el-2.7/src/fit.o
build/temp.linux-ppc64el-2.7/src/fitting.o -lcasa_scimath -lcasa_scimath_f
-lboost_python-py27 -lcasa_python -o
/<>/.pybuild/cpython2_2.7_casacore/build/casacore/fitting/_fitting.so
/usr/bin/ld: cannot find -lboost_python-py27
collect2: error: ld returned 1 exit status
error: command 'powerpc64le-linux-gnu-g++' failed with exit status 1
E: pybuild pybuild:338: build: plugin distutils failed with: exit code=1:
/usr/bin/python setup.py build
dh_auto_build: pybuild --build -i python{version} -p 2.7 returned exit code 13
make: *** [debian/rules:8: build-arch] Error 25

Bug#470706: xfsprogs: xfs_repair crashes during attempted repair

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out where this given backtrace points to.

I think that following would be the location
where the invalid pointer was tried to be freed.

Attached file contains some details on how it was retrieved.

Upstream removed/replaced function teardown_ag_bmap in [1],
therefore this bug might be just closed.

Kind regards,
Bernhard



Phase 5 - rebuild AG headers and trees...
*** glibc detected *** xfs_repair: munmap_chunk(): invalid pointer: 0xb092c008 
***
=== Backtrace: =
/lib/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7de24ab]| 0xb7de24ab | 
xfs_repair[0x8061f2d]| 0x08061f2d | 
:   call   
xfs_repair[0x806b311]| 0x0806b311 | 
: call   
xfs_repair[0x807cb28]| 0x0807cb28 | 
:  call   
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d89450] | 0xb7d89450 | 
<__libc_start_main+226>: call   *0x8(%ebp)
xfs_repair[0x8049541]| 0x08049541 | 
<_start+28>: call   <__libc_start_main@plt>
=== Memory map: 



[1] 
https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/repair?id=c1f7a46c4d6403e3313c13487e2f2174f92db670



Phase 5 - rebuild AG headers and trees...
*** glibc detected *** xfs_repair: munmap_chunk(): invalid pointer:
0xb092c008 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7de24ab]| 0xb7de24ab | 
xfs_repair[0x8061f2d]| 0x08061f2d | 
:   call   0x80492c4 
xfs_repair[0x806b311]| 0x0806b311 | 
: call   0x8061d60 
xfs_repair[0x807cb28]| 0x0807cb28 | 
:  call   0x806ae60 
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d89450] | 0xb7d89450 | 
<__libc_start_main+226>: call   *0x8(%ebp)
xfs_repair[0x8049541]| 0x08049541 | 
<_start+28>: call   0x8049254 <__libc_start_main@plt>
=== Memory map: 
08048000-080ce000 r-xp  03:01 195863 /sbin/xfs_repair
080ce000-080cf000 rw-p 00085000 03:01 195863 /sbin/xfs_repair
080cf000-0aadc000 rw-p 080cf000 00:00 0  [heap]




##



deb [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
deb-src [check-valid-until=no] 
http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main

apt-get update
apt-get install debian-archive-keyring gdb xfsprogs devscripts dpkg-dev 
build-essential uuid-dev autoconf debhelper gettext libtool libreadline5-dev 
gcc-4.1


wget 
http://snapshot.debian.org/archive/debian/20060822T00Z/pool/main/x/xfsprogs/xfsprogs_2.8.11-1_i386.deb
dpkg -i xfsprogs_2.8.11-1_i386.deb


https://buildd.debian.org/status/fetch.php?pkg=xfsprogs&arch=amd64&ver=2.8.11-1&stamp=1156139624&raw=0
# Unfortunately no log for i386
# -> was built with gcc-4.1


ln -sf gcc-4.1 /usr/bin/gcc



mkdir xfsprogs/orig -p
cdxfsprogs/orig
dget 
http://snapshot.debian.org/archive/debian/20060822T00Z/pool/main/x/xfsprogs/xfsprogs_2.8.11-1.dsc
dpkg-source -x xfsprogs_2.8.11-1.dsc
cd ../..



cd xfsprogs
cp orig try1 -a
cd try1/xfsprogs-2.8.11/
dpkg-buildpackage -b





benutzer@debian:~$ objdump -D /sbin/xfs_repair > objdump.txt




debian:~/xfsprogs/try1/xfsprogs-2.8.11# file /sbin/xfs_repair 
/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair
/sbin/xfs_repair:  ELF 32-bit LSB 
executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically 
linked (uses shared libs), for GNU/Linux 2.4.1, stripped
/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair: ELF 32-bit LSB 
executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically 
linked (uses shared libs), for GNU/Linux 2.6.8, not stripped




debian:~/xfsprogs/try1/xfsprogs-2.8.11# gdb -q --args 
/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair
(gdb) set width 0
(gdb) set pagination off
(gdb) disassemble main




debian:~# gdb -q --args /sbin/xfs_repair 
(no debugging symbols found)
(gdb) set width 0
(gdb) set pagination off
(gdb) b __libc_start_main
















   --- original binary ---  
|  --- rebuild with debug info ---

| 
(gdb) info target   
| (gdb) info target
Symbols from "/sbin/xfs_repair".
| Symbols from "/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair".
Local exec file:
| Local exec file:
`/sbin/xfs_repair', file type elf32-i386.   
| `/root/xfsprogs/try1/xfsprogs-2.8.11/repair/xfs_repair', file typ

Bug#914597: libendless-bin: uninstallable on s390x

[Jeremy Bicha]

Source: eos-sdk
Version: 0~git20180727+ds-1

gjs is no longer available on s390x (and some other
non-release-architectures). There is some discussion of that on
https://bugs.debian.org/913077 and https://bugs.debian.org/906016

libendless-bin is an arch:any package that depends on gjs which makes
it uninstallable on s390x.

In fact, libendless-bin has been removed on s390x as part of the gjs
transition but I believe that the binary package will try to come back
the next time eos-sdk is built.

For some packages (like gdm3), we added a Build-Depends on gjs. That
would mean that none of the eos-sdk binary packages would be available
on s390x. That might be acceptable for you.

It looks to me like all of the file libendless-bin ships are actually
architecture-independent except for eos-profile. So another solution
is to make libendless-bin arch:all and move eos-profile and its
manpage to a new binary package. That new binary package would not
need to have a gjs dependency since eos-profile doesn't need gjs.

Thanks,
Jeremy Bicha

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Fabian Greffrath]

Hi James,

Am Dienstag, den 20.11.2018, 09:22 -0800 schrieb James Godfrey-Kittle:
> with some component of fontmake; it's worth posting an issue on Github
> to have it triaged (I was planning to do this soon when I have time).

yes, please!

Thanks,

 - Fabian


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

Bug#914590: regression: parsing known_hosts is slow

[Gabriel F. T. Gomes]

Hi, thanks for the report.

On 25 Nov 2018, Timo Weingärtner wrote:

>with the last upgrade of bash-completion completing hostnames has
>become slow (takes more than two seconds). My /etc/ssh/ssh_known_hosts
>file has quite some size (23084 lines / 12 MB), but this was not a
>problem with the previous implementation.

OK, sounds like a lot of time.

>I guess the problem is the while read … done < known_hosts_file loop,
>where the shell has to read() one byte at a time, causing a massive
>amount of syscalls (which have become even more costly this year).

I have backported a patch [1] from the upstream master branch, in order
to fix bug #848125 [2].  Running the following command against current
upstream sources shows that there are no newer patches related to this
(lines 1479 to 1665 contain the function, _known_hosts_real, that
parses the known_hosts file):

  git log --stat -L1479,1665:bash_completion
  (lastest commit is the patch that I backported [1])

I think we need to forward this problem report upstream.  Do you have
more information that I could add to it (maybe the syscall trace you
ran)?

PS: I don't want to remove the patch from Debian, because it would only
solve the problem you are reporting until bash-completion 2.9 is
released.

[1] 
https://github.com/scop/bash-completion/commit/71ac42b98c0eba39819fb8478d6443032c6ef6f1
[2] https://bugs.debian.org/848125

Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"

[Brian Potkin]

On Sun 25 Nov 2018 at 13:28:44 +0100, Didier 'OdyX' Raboud wrote:

> Le vendredi, 12 octobre 2018, 18.56:40 h CET Brian Potkin a écrit :
> > The CreateIPPPrinterQueues works very nicely with remote print queues.
> > A permanent local queue is created which can be printed to using lp or
> > the GTK, Qt and Libreoffice dialogs.
> > 
> > When dealing with a remote IPP printer the situation is different, as
> > described in #905850 and #908604:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905850
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908604
> > 
> > Unlike a print queue, the queue for an IPP printer is temporary and
> > disappears within a minute from the 'lpstat -a' output and from a GTK
> > dialog (but not from Qt and Libreoffice dialogs). Very confusing for
> > a user, I would have thought. CreateIPPPrinterQueues is not sufficient
> > for a permanent queue to be created.
> > 
> > The temporary nature of a printer queue is not documented and neither
> > is the solution, setting UseCUPSGeneratedPPDs to "No".
> 
> My understanding is that the current default for UseCUPSGeneratedPPDs is
> set to Yes; 
> 
>   
> https://sources.debian.org/src/cups-filters/1.21.3-3/utils/cups-browsed.c/#L391
>   
> https://sources.debian.org/src/cups-filters/1.21.3-3/utils/cups-browsed.conf.in/#L347
> 
> Are you asking to swap it to be "No"?

Indeed - that was my intention, but I messed it up. Thanks for querying.

The bug title isn't the best but at the time it seemed a not unreasonable
request (set to "No") if it stopped the disappearing after 1 minute IPP
printer queue. I am, of course, happy to see it fixed in another, perhaps
more fundamental, way and the pre-1.20.4 behaviour restored.

Regards,

Brian.

Bug#858142: #858142 xterm: ASCII underscore does not render when using -fa DejaVuSansMono-14

[Thomas Dickey]

I think this is a bug in fontconfig, as suggested.
I can reproduce the problem with Debian 9, but not with Debian testing.
(that's with the same version of xterm of course).

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


signature.asc
Description: Digital signature

Bug#914598: ITP: ethereal -- UCI-compliant chess engine

[Jose G . López]

Package: wnpp
Severity: wishlist
Owner: Jose G. López 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ethereal
  Version : 11.00
  Upstream Author : Andrew Grant 
* URL : https://github.com/AndyGrant/Ethereal
* License : GPL3+
  Programming Lang: C
  Description : UCI-compliant chess engine

Ethereal is a UCI-compliant chess engine. It uses the traditional alpha-beta
framework in addition to a variety of pruning, reduction, extension, and other
improvements. It's greatly influenced from Crafty, Stockfish, TSCP,
MadChess and Fruit.

Needs fathom probing tool (ITP #914595) wich I plan to package first.
CCing Debian Games Team as I will need a sponsor and think it should be under
their umbrella.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEErjybAXQDiUP1e5CQB1rixSTQ0UIFAlv6tykACgkQB1rixSTQ
0UK75Q//T8dNyPqF192rGo57/h2h168pxBM8NLiIziSmJsA61GSzUYy3TrNPogGu
vn2Cm+xkC4B+SsHxqjN/H4nY0zQRjuSfDX4/8bMKHfOcpq5TX/oHs2e/s8VaHZZe
O5Kf85PdIpN3LMVHDzlgK+vYi9OvbiXVrHdwhhI6axGvu/DopncqghHSJhQFG69f
fAIvt2BSMPF4L//OdEDViAwe143PSmX4zEhj8gCGeyP+d5Ug0Bj64btAO+kMp4aV
HbWq+Ew7eIQKnSJ91vl50XIF0BHZzdQ5pV1mpq+Yx1kPenY0Tnl6HqEsm2HfvqmW
t+GdQAJOL51nOOztRf1A6mQPkvKP9NogsCGe1y08P28pEpN4wr3Xi7CCPbPKvHst
AIRw8T7QndxXkDFGXbgl4HMli/G/Em7nKtJVJdAk80v5+2YSh1536o+hj4IoitMV
bHeHTYA+7G4qT4OufDC8y4MN7ymMNt2jfYpE+QTqOie7s6omlb3tCIRRTI1O3hDQ
1cPTYaA7yz9Ly1sO+Qfb0K+eg5UUrVtsUoucTygTcjOjZgsMMtdzJ+hR2qaldPsk
hku4kaYTBwGtbrYUUt7mipo6z3wrg8W/I7/UgEhfqCiBs836wLmh+wQ7wNWFFmcb
PGxkAExG4D+TbzOXbj4JjuBcJycmMmro99/74rzG2x3i48zIcBU=
=wEy1
-END PGP SIGNATURE-

Bug#914599: qemu: CVE-2018-19364: Use-after-free due to race condition while updating fid path

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.12+dfsg-3
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for qemu.

CVE-2018-19364[0]:
Use-after-free due to race condition while updating fid path

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-2018-19364
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19364
[1] https://www.openwall.com/lists/oss-security/2018/11/20/1
[2] 
https://git.qemu.org/?p=qemu.git;a=commit;h=5b76ef50f62079a2389ba28cacaf6cce68b1a0ed
[2] 
https://git.qemu.org/?p=qemu.git;a=commit;h=5b3c77aa581ebb215125c84b0742119483571e55

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#914597: libendless-bin: uninstallable on s390x

[Jeremy Bicha]

I didn't look closely enough.

/usr/bin/eos-application-manifest has this line:
const commandSearchPath =
"/usr/lib/x86_64-linux-gnu/eos-application-manifest/commands";

Maybe those could be installed to an arch-independent location though.

Thanks,
Jeremy Bicha

Bug#473996: promptconfaction should offer vimdiff too

[Paul "LeoNerd" Evans]

On Fri, 23 Nov 2018 13:09:13 -0500
"Chris Lamb "  wrote:

> [Adding guil...@debian.org to CC]
> [Adding 473...@bugs.debian.org to CC]
> 
> Hi Paul,
>   
> > In order for this bug not to sit idle for yet another five years,
> > attached is my attempt at a patch.
> 
> Alas, I don't think that this will merged simply because it hard-
> codes vimdiff.   

Oh absolutely. I was fully expecting that exact objection - I just
wrote a minimal "works for me" on the hopes someone else would know how
to make that part.

> Knowing the answers there here the next step here I think, or we
> should just mark all of these bugs as wontfix with a suitable
> justification to ameliorate any frustration.  

I hope it does get fixed. I'd love to be able to type

  V

instead of

  Z
  vimdiff /etc/ssh/sshd_config{,.dpkg-new}

every time.

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Bug#910059: RFH: gnucash -- personal and small-business financial-accounting software

[Raphael Hertzog]

Hello Jason,

a good start would be to include Dmitry in your recipient list. The
Debian bug tracker does not include the bug submitter by default.

I have cced him so hopefully he will be able to reply to you.

Cheers,

On Wed, 24 Oct 2018, Jason Vigil wrote:
> Hello Dmitry,
> 
> I'd be interested in helping to maintain gnucash. I am looking to get 
> involved in Debian and use gnucash personally. Do you have any advice on how 
> to get started?
> 
> Thank you,
> Jason

-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#914600: poppler: CVE-2018-19149: NULL pointer dereference in _poppler_attachment_new

[Salvatore Bonaccorso]

Source: poppler
Version: 0.69.0-2
Severity: normal
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/664

Hi,

The following vulnerability was published for poppler.

CVE-2018-19149[0]:
| Poppler before 0.70.0 has a NULL pointer dereference in
| _poppler_attachment_new when called from
| poppler_annot_file_attachment_get_attachment.

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-2018-19149
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19149
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/664
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1649457

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#914601: ITP: triod-postnaja -- Latin+Cyrillic font based on Old Church Slavonic service books

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: triod-postnaja
  Version : 20130809
  Upstream Author : Daniel Johnson
* URL : https://fontlibrary.org/en/font/triod-postnaja [1]
* License : SIL OFL 1.1
  Programming Lang: sfd
  Description : Latin+Cyrillic font based on Old Church Slavonic service 
books
 Triod Postnaja attempts to mimic the typefaces used to publish Old Church
 Slavonic service books prior to the 20th century.  It also provides a
 range of Latin letters in the same style, sufficient for the needs of
 central, northern and western European languages.
 .
 Unlike most Old Church Slavonic fonts that provide Latin ranges, this
 font imitates the uncial style, especially in lowercase letters with
 ascenders or descenders.  Triod Postnaja is something of a
 stylistic mishmash of various period styles — those seeking a more
 period-authentic face for setting Church Slavonic should have a look
 at other fonts such as Hirmos Ponomar.

[1]. That's just a random font collection site, but it's where the author's
fonts page (http://danieljohnson.name/fonts) points to.

Bug#914602: Blueman python version constrains prevents other packages from upgrading without clear reason

[Braiam Peguero]

package: blueman
Version: 2.1~alpha2-1
Sevirity: minor

According to bug #804075, blueman was switched from python2 to 3 but for some
reason, it was restricted to versions 3.6 to 3.7, while upstream only recommends
>3.2 [1] since support for python 3 was achieved. There isn't any clear reason 
>why
blueman depends on <3.7 if upstream supports it. Triggering a rebuild
should update
python dependencies.

[1]: 
https://github.com/blueman-project/blueman/commit/a9711d1274bfef8311a7398e7a23d0faf5177f71#diff-04c6e90faac2675aa89e2176d2eec7d8


-- 
Braiam

Bug#910731: kaddressbook: crashes at startup

[Bernhard Übelacker]

Hello Francesco,
can you still observe the crash, or got it fixed by updates
in mid October? (Like mentioned in #910581)

If it is fixed that bug might be closed.

Kind regards,
Bernhard

Bug#914603: nmu: mpich_3.3-1

[Adrian Bunk]

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

nmu mpich_3.3-1 . ANY . unstable . -m "Merged /usr considered harmful"

$ mpicc.mpich
bash: /usr/bin/mpicc.mpich: /usr/bin/bash: bad interpreter: No such file or 
directory
$

Multi-Arch: same, so needs rebuild on all architectures.

Bug#914604: qemu: CVE-2018-18954: ppc64: Out-of-bounds r/w stack access in pnv_lpc_do_eccb

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.12+dfsg-3
Severity: important
Tags: patch security upstream
Control: found -1 1:2.8+dfsg-6
Control: found -1 1:2.8+dfsg-6+deb9u5

Hi,

The following vulnerability was published for qemu.

CVE-2018-18954[0]:
| The pnv_lpc_do_eccb function in hw/ppc/pnv_lpc.c in Qemu before 3.1
| allows out-of-bounds write or read access to PowerNV memory.

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-2018-18954
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18954
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1526029
[2] https://www.openwall.com/lists/oss-security/2018/11/06/6

Regards,
Salvatore

Bug#914190: yaml-cpp: diff for NMU version 0.5.3-0.2

[073plan]

X-Debbugs-CC: j...@debian.org

在 2018-11-21三的 17:37 +0100，Julian Andres Klode写道：
> Actually, I missed a bit in the diff.

Hi Julian,

By making the NMU, you actually started an uncoordinated transition [1]. Since
you initiated it, do you have time registering this transition with the
Release Team so that the rebuild could be finished in time?

Thanks,
Boyuan Yang

[1] https://release.debian.org/transitions/html/auto-yaml-cpp.html

Bug#914605: task-japanese-gnome-desktop: Icedove is now back to Thunderbird

[Tetsutaro KAWADA]

Package: task-japanese-gnome-desktop
Version: 3.48
Severity: normal

Dear Maintainer,

Icedove is now back to Thunderbird.

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

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

Versions of packages task-japanese-gnome-desktop depends on:
ii  tasksel  3.48

Versions of packages task-japanese-gnome-desktop recommends:
pn  icedove  
pn  icedove-l10n-ja  

task-japanese-gnome-desktop suggests no packages.

-- no debconf information
diff --git a/debian/control b/debian/control
index 65290fbe..f22b8ef1 100644
--- a/debian/control
+++ b/debian/control
@@ -1438,9 +1438,9 @@ Depends: ${misc:Depends},
 Recommends:
 # evolution has a problem for Japanese, for example it uses always UTF-8
 # subject instead of iso-2022-jp used Japanese de-facto. I recommend
-# icedove as default mailer for Japanese desktop users.
-   icedove,
-   icedove-l10n-ja
+# thunderbird as default mailer for Japanese desktop users.
+   thunderbird,
+   thunderbird-l10n-ja
 
 Package: task-japanese-kde-desktop
 Architecture: all

Bug#914607: plaso depends on cruft package python-dfwinreg

[peter green]

Package: plaso
Version: 1.5.1+dfsg-4
Severity: serious

plaso depends on python-dfwinreg which is no longer built by the dfwinreg 
source package.

Bug#914606: apache2 setup-instance (apache-multi) logrotation

[Horst Platz]

Package: apache2
Version: 2.4.25-3+deb9u6
Severity: normal

Dear Maintainer,

there is a problem with the setup-instance script for apache-multi
installation. The logrotation for the copyied instance is not working.
It looks like it is in debian stretch and buster/sid, in a kind of the
same way. In my fokus it's comming up with an installation from Ubuntu 18.04

What i did (stretch; buster/sid; ubuntu 18.04)

:~# apt-get install apache2
[...]

:~# sh /usr/share/doc/apache2/examples/setup-instance multi-xxx
Setting up /etc/apache2-multi-xxx ...
systemd is in use, no init script installed
use the 'apache2@multi-xxx.service' service to control your new instance
sample commands:
systemctl start apache2@multi-xxx.service
systemctl enable apache2@multi-xxx.service
Setting up symlinks: a2enmod-multi-xxx a2dismod-multi-xxx
a2ensite-multi-xxx a2dissite-multi-xxx a2enconf-multi-xxx
a2disconf-multi-xxx apache2ctl-multi-xxx


HINT "no init script installed"


:~# ls -la /etc/init.d/apache*
-rwxr-xr-x 1 root root 8181 Nov  3 12:34 /etc/init.d/apache2
-rwxr-xr-x 1 root root 2489 Nov  3 12:34 /etc/init.d/apache-htcacheclean

-> No init.d for the new multi-xxx apache


With in Debian 9.6 stretch

:~# cat /etc/logrotate.d/apache2-multi-xxx
/var/log/apache2-multi-xxx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if /etc/init.d/apache2-multi-xxx status > /dev/null ; then \
/etc/init.d/apache2-multi-xxx reload > /dev/null; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}

:~# /etc/init.d/apache2-multi-xxx status
-su: /etc/init.d/apache2-multi-xxx: Datei oder Verzeichnis nicht gefunden

:~# /etc/init.d/apache2-multi-xxx reload
-su: /etc/init.d/apache2-multi-xxx: Datei oder Verzeichnis nicht gefunden



With in Debian buster/sid

:~$ cat /etc/logrotate.d/apache2-multi-xxx
/var/log/apache2-multi-xxx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
if invoke-rc.d apache2-multi-xxx status > /dev/null
2>&1; then \
invoke-rc.d apache2-multi-xxx reload > /dev/null 2>&1; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}


:~# invoke-rc.d apache2-multi-xxx status
Unit apache2-multi-xxx.service could not be found.
invoke-rc.d: initscript apache2-multi-xxx, action "status" failed.

:~# invoke-rc.d apache2-multi-xxx reload
/usr/sbin/invoke-rc.d: 527: /usr/sbin/invoke-rc.d:
/etc/init.d/apache2-multi-xxx: not found
invoke-rc.d: initscript apache2-multi-xxx, action "reload" failed.



In both cases the logrotation will fail because the reload is not
working. Also in the both cases the logrotate.d script for the multi-xxx
apache is a copy from the original logrotate.d apache2 script.

:~$ cat /usr/share/doc/apache2/examples/setup-instance
[...]
echo Setting up /etc/logrotate.d/apache2-$SUFFIX and
/var/log/apache2-$SUFFIX ...
cp -a /etc/logrotate.d/apache2 /etc/logrotate.d/apache2-$SUFFIX
perl -p -i -e s,apache2,apache2-$SUFFIX,g /etc/logrotate.d/apache2-$SUFFIX
[...]

As shown above the original apache has a init.d script installed and the
logrotation is working.


In that Ubuntu 18.04 installation i changed the
/etc/logrotate.d/apache2-multi-xxx in that way that i changed the reload
to systemd

from

[...]
if invoke-rc.d apache2-multi-xxx status > /dev/null
2>&1; then \
invoke-rc.d apache2-multi-xxx reload > /dev/null 2>&1; \
[...]


in to

[...]

if systemctl status apache2@multi-xxx.service >
/dev/null 2>&1; then \
systemctl reload apache2@multi-xxx.service >
/dev/null 2>&1; \
[...]

Looks like some day's after the logrotation is now workings as expected
for the multi-instance.

And in that case i think the upstream package for ubuntu 18.04 is
comming from Debian buster/sid.

Kind regards

 Horst

Bug#293454: Qjackctl: Won't fix?

[Ross Gammon]

tag 293454 - upstream + wontfix
notforwarded 293454
thanks

The fowarded address is no longer valid. Tickets on the current
Sourceforge tracker date from 2012.

According to the upstream maintainer's comments on this bug, the problem
won't be fixed. SO I have tagged the bug with this status for now.

If it is still a problem, a new ticket should probably be created upstream.

Ross




signature.asc
Description: OpenPGP digital signature

Bug#914391: octave: "unimplemented function" helper overlooks functions in package subdirectories

[Rafael Laboissière]

Control: tags -1 + upstream
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?55094

* James Van Zandt  [2018-11-22 17:14]:


Package: octave
Version: 4.4.1-2+b1
Severity: normal
Tags: upstream

Dear Maintainer,

Octave now has a very helpful feature which points the user to 
functions available in packages:


   octave:1> help random
   error: help: the 'random' function belongs to the statistics package
from Octave 
   Forge which you have installed but not loaded.  To load the package, run 
   'pkg load statistics' from the Octave prompt.


However, the feature overlooks some functions.  These are also 
provided in the statistics package:


   octave:1> help chi2inv
   error: help: 'chi2inv' not found
   octave:1> help logit
   error: help: 'logit' not found
   octave:1> help regression
   error: help: 'regression' not found

The problem appears to be that the overlooked functions are in 
subdirectories of the package.


The message is printed by __unimplemented__.m, in the directory 
/usr/share/octave/4.4.1/m/help, which has hard-coded lists of the 
functions in each package.  I see nothing in the source package that 
generates those lists, so I assume one of the upstream maintainers has 
code for that.


Some directories should still be omitted (e.g., self-testing 
functions).  I suggest functions in these directories be added to the 
lists in __unimplemented__.m:


   bsltl/mfiles
   geometry/geom2d
   geometry/geom3d
   geometry/graphs
   geometry/io
   geometry/meshes3d
   geometry/polygons2d
   geometry/polynomialCurves2d
   geometry/shape2d
   geometry/utils
   ltfat/auditory
   ltfat/blockproc
   ltfat/comp
   ltfat/demos
   ltfat/deprecated
   ltfat/filterbank
   ltfat/fourier
   ltfat/frames
   ltfat/gabor
   ltfat/mulaclab
   ltfat/nonstatgab
   ltfat/operators
   ltfat/quadratic
   ltfat/signals
   ltfat/sigproc
   ltfat/thirdparty
   ltfat/wavelets
   statistics/base
   statistics/distributions
   statistics/models


This is an upstream issue.  I am hereby tagging this bug report 
accordingly.  I have also forwarded the report to the upstream bug 
tracking system.


Rafael

Bug#914495: linux-image-4.18.0-3-amd64: does not boot here

[Amy Kos]

Could be graphics related, boot stops at:

 fb: switching to inteldrmfb from EFI VGA

Disabling kernel mode setting with parameter nomodeset boots to tty.

Bug#914608: ITP: perl6-readline -- Perl 6 interface to libreadline

[Robert Lemmen]

Package: wnpp
Severity: wishlist
Owner: Robert Lemmen 

* Package name: perl6-readline
  Version : 0.1.4
  Upstream Author : Jeffrey Goff 
* URL : https://github.com/drforr/perl6-readline
* License : Artistic License 2.0
  Programming Lang: Perl 6
  Description : Perl 6 interface to libreadline

This package provides a binding to the realine library. Amongst other
uses, this makes the Perl 6 REPL more convenient to work with.

The package will be maintained collectively by the perl 6 folks.

Bug#914605: task-japanese-gnome-desktop: Icedove is now back to Thunderbird

[Holger Wansing]

Control: tags -1 + pending

Tetsutaro KAWADA  wrote:
> Package: task-japanese-gnome-desktop
> Version: 3.48
> Severity: normal
> 
> Dear Maintainer,
> 
> Icedove is now back to Thunderbird.

Committed to GIT. Thanks for the patch.

Tagging this bug as pending


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#588411: Need help dealing with this l10n bug?

[Helge Kreutzmann]

Hello Andreas,
this German l10n bug is open for more than 8 years. Do you need help
dealing with it? I could provide a NMU, but of course a maintainer
upload is (much) preferred.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#575482: Need help dealing with this l10n bug?

[Helge Kreutzmann]

Hello Colin,
this German l10n bug is open for more than 8 years. Do you need help
dealing with it? I could provide a NMU, but of course a maintainer
upload is (much) preferred.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#577157: Need help dealing with this l10n bug?

[Helge Kreutzmann]

Hello Junichi,
this German l10n bug is open for more than 8 years. Do you need help
dealing with it? I could provide a NMU, but of course a maintainer
upload is (much) preferred.

Greetings

Helge
~

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#547292: Need help dealing with this l10n bug?

[Helge Kreutzmann]

Hello Emfox,
this German l10n bug is open for more than 9 years. Do you need help
dealing with it? I could provide a NMU, but of course a maintainer
upload is (much) preferred.

Greetings

Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#576914: Need help dealing with this l10n bug?

[Helge Kreutzmann]

Hello Dirk,
this German l10n bug is open for more than 8 years. Do you need help
dealing with it? I could provide a NMU, but of course a maintainer
upload is (much) preferred.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#783261: Need help dealing with this l10n bug?

[Helge Kreutzmann]

Hello Martin,
hello Simon,
hello Michael,
this German l10n bug is open for more than 3 years. Do you need help
dealing with it? I could provide a NMU, but of course a maintainer
upload is (much) preferred.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#914538: lintian: false positives with make prefixes on dh

[Chris Lamb]

tags 914538 + pending
thanks

Stephen Kitt wrotE:

> When debian/rules includes a make prefix in front of dh, the use of dh
> isn’t recognised and lintian reports package-does-not-use-debhelper-or-cdbs

Thanks for the report and patch which I have applied in Git (see
below).

FYI I could simplify your patch by removing the control.in files
(preventing any tags from being emitted) as well as the boilerplate at
the top of the debian/rules files. In addition, I had to move the
files under "debian/debian" to just "debian/" due to testsuite
reorganisation work.

Thanks again.


  
https://salsa.debian.org/lintian/lintian/commit/134c687ef93a076238165b713db12495ad4f8477

  checks/debhelper.pm | 4 ++--
  debian/changelog| 4 
  .../debhelper-package-uses-debhelper-with-prefix-minus/debian/rules | 4 
  t/tests/debhelper-package-uses-debhelper-with-prefix-minus/desc | 6 ++
  t/tests/debhelper-package-uses-debhelper-with-prefix-minus/tags | 0
  .../debhelper-package-uses-debhelper-with-prefix-plus/debian/rules  | 4 
  t/tests/debhelper-package-uses-debhelper-with-prefix-plus/desc  | 6 ++
  t/tests/debhelper-package-uses-debhelper-with-prefix-plus/tags  | 0
  8 files changed, 26 insertions(+), 2 deletions(-)


Regards,

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

Bug#914609: godot FTBFS on 32bit

[Adrian Bunk]

Source: godot
Version: 3.0.6-1
Severity: important
Tags: ftbfs

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

...
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
install -D -m 400 /<>/bin/godot.x11.opt.tools.64   
/<>/debian/godot3/usr/bin/godot3
install: cannot stat '/<>/bin/godot.x11.opt.tools.64': No such 
file or directory
make[1]: *** [debian/rules:64: override_dh_auto_install] Error 1

Bug#912113: harvest-tools: diff for NMU version 1.3-2.1

[Adrian Bunk]

Control: tags 912113 + pending

Dear maintainer,

I've prepared an NMU for harvest-tools (versioned as 1.3-2.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru harvest-tools-1.3/debian/changelog harvest-tools-1.3/debian/changelog
--- harvest-tools-1.3/debian/changelog	2018-07-17 18:00:34.0 +0300
+++ harvest-tools-1.3/debian/changelog	2018-11-25 18:48:23.0 +0200
@@ -1,3 +1,10 @@
+harvest-tools (1.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix a frequent parallel FTBFS. (Closes: #912113)
+
+ -- Adrian Bunk   Sun, 25 Nov 2018 18:48:23 +0200
+
 harvest-tools (1.3-2) unstable; urgency=medium
 
   [ Steffen Moeller ]
diff -Nru harvest-tools-1.3/debian/patches/parallel.patch harvest-tools-1.3/debian/patches/parallel.patch
--- harvest-tools-1.3/debian/patches/parallel.patch	1970-01-01 02:00:00.0 +0200
+++ harvest-tools-1.3/debian/patches/parallel.patch	2018-10-28 12:51:06.0 +0200
@@ -0,0 +1,22 @@
+Description: Fix a frequent parallel FTBFS
+Author: Adrian Bunk 
+
+--- harvest-tools-1.3.orig/Makefile.in
 harvest-tools-1.3/Makefile.in
+@@ -37,10 +37,14 @@ harvesttools : $(OBJECTS)
+ %.o : %.cc
+ 	$(CXX) -c $(CXXFLAGS) $(CPPFLAGS) -o $@ $<
+ 
+-src/harvest/pb/harvest.pb.cc src/harvest/pb/harvest.pb.h : src/harvest/pb/harvest.proto
++src/harvest/pb/harvest.pb.cc : src/harvest/pb/harvest.pb.h
++
++src/harvest/pb/harvest.pb.h : src/harvest/pb/harvest.proto
+ 	cd src; @protobuf@/bin/protoc --cpp_out . harvest/pb/harvest.proto
+ 
+-src/harvest/capnp/harvest.capnp.c++ src/harvest/capnp/harvest.capnp.h : src/harvest/capnp/harvest.capnp
++src/harvest/capnp/harvest.capnp.c++ : src/harvest/capnp/harvest.capnp.h
++
++src/harvest/capnp/harvest.capnp.h : src/harvest/capnp/harvest.capnp
+ 	cd src/harvest/capnp;export PATH=@capnp@/bin/:${PATH};capnp compile -I @capnp@/include -oc++ harvest.capnp
+ 
+ install : harvesttools
diff -Nru harvest-tools-1.3/debian/patches/series harvest-tools-1.3/debian/patches/series
--- harvest-tools-1.3/debian/patches/series	2018-07-17 18:00:34.0 +0300
+++ harvest-tools-1.3/debian/patches/series	2018-10-28 12:50:02.0 +0200
@@ -2,3 +2,4 @@
 dynamic_linking.patch
 hardening.patch
 remove_memwrap.patch
+parallel.patch

Bug#576914: Need help dealing with this l10n bug?

[Dirk Eddelbuettel]

On 25 November 2018 at 17:30, Helge Kreutzmann wrote:
| Hello Dirk,
| this German l10n bug is open for more than 8 years. Do you need help
| dealing with it? I could provide a NMU, but of course a maintainer
| upload is (much) preferred.

In R land, it is _much_ preferred to give this to the _upstream package
author_ which is why I have refused to create a Debian-only delta.

Detlef (CC'ed) is still quite involved with i18n/i10n, he may have pointers.

Tschoe mit oe aus Chicago,  Dirk
 
| Greetings
| 
| Helge
| 
| -- 
|   Dr. Helge Kreutzmann deb...@helgefjell.de
|Dipl.-Phys.   http://www.helgefjell.de/debian.php
| 64bit GNU powered gpg signed mail preferred
|Help keep free software "libre": http://www.ffii.de/
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#914527: dwarves: update package description

[Philip Hands]

Holger Levsen  writes:

...
> I'd suggest you update this to
>
> Description-en: set of advanced DWARF utilities
>  This package contains tools that use the DWARF debugging information
>  inserted in ELF binaries by the compiler. This information is used by
>  debuggers (e.g. GDB), and other tools such as systemtap.

To save people having to look at the long description to know what
they're looking at, might I suggest something like this:

Description-en: set of advanced DWARF (ELF debugging) utilities
 This package contains tools that use the DWARF debugging information
 inserted in ELF binaries by the compiler. This is the information that
 is used by debuggers (e.g. GDB), and other tools such as systemtap.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#911957: [src:rquantlib] FTBFS with boost1.67

[Dirk Eddelbuettel]

On 28 October 2018 at 09:31, Dirk Eddelbuettel wrote:
| 
| On 26 October 2018 at 17:13, Giovanni Mascellani wrote:
| | Package: src:rquantlib
| | Version: 0.4.5-1
| | Severity: wishlist
| | Tags: patch
| | User: team+bo...@tracker.debian.org
| | Usertags: boost1.67
| | 
| | Dear Maintainer,
| | 
| | your package fails to build with boost1.67. You can find a build log
| | attached. If you want to attempt the build yourself, an updated version
| | of boost-defaults which brings in boost1.67 dependencies can be found
| | adding this line to your sources.list file:
| | 
| |   deb https://people.debian.org/~gio/reprepro unstable main
| | 
| | This bug has severity whishlist for the moment, but it will raised to RC
| | as soon as version 1.67 of Boost is promoted to default.
| | 
| | More specifically, your package fails building because
| | boost::posix_time::minutes and similar calls now require an integral
| | argument. The attached patch should fix this issue.
| | 
| | Please consider applying the attached patch as soon as boost1.67 is made
| | default in order to avoid FTBFS.
| 
| Patch works great, thank you. I tested under your Boost 1.67 as well as the
| standard older Boost packages and applied it to my upstream repo. I will cut
| a new release of this R package in the next few days and then also update the
| Debian package.

Package is now on CRAN, Debian upload to follow.

Dirk

| 
| Thanks again,  Dirk
|  
| | Thanks and all the best, Giovanni.
| | -- 
| | Giovanni Mascellani 
| | Postdoc researcher - Université Libre de Bruxelles
| | x[DELETED ATTACHMENT 0001-Fix-build-with-Boost-1.67.patch, text/x-patch]
| | x[DELETED ATTACHMENT build-rquantlib.log, text/x-log]
| | x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
| 
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#914612: python-astropy: Please drop unnecessary dh_strip_nondeterminism override

[Chris Lamb]

Source: python-astropy
Version: 2.0.9-1
Severity: minor
Tags: patch
X-Debbugs-CC: reproducible-b...@lists.alioth.debian.rg

Hi,

Noticed via #779627, I saw:

override_dh_strip_nondeterminism:
dh_strip_nondeterminism -Xinvalid.dat.gz

… but the package no long ships this file so this can be safely removed.

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index 7e42fd6..864c3d3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -36,6 +36,3 @@ ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test:
python setup.py test -vv --args "-vv --mpl"
 endif
-
-override_dh_strip_nondeterminism:
-   dh_strip_nondeterminism -Xinvalid.dat.gz

Bug#914610: The priority of pam_mkhomedir.so is too low

[Jon Severinsson]

Package: libpam-modules
Version: 1.1.8-3.8
Severity: normal

Because /usr/share/pam-configs/mkhomedir specifies "Priority: 0", if you
enable it using `sudo pam-auth-update` pam_mkhomedir.so will become the
last module listed in /etc/pam.d/common-session, meaning it will run after
all other enabled modules.

This can cause problems if any of the other session modules assume that
the home directory already exists. Even worse, if another session module
recursively creates a directory in the home directory it needs,
pam_mkhomedir.so will believe that the home directory was set up already,
and no files will be copied from the skeleton directory.

In my case I hit the problem with libpam-mount, which has "Priority: 128",
so changing /usr/share/pam-configs/mkhomedir to anything above that would
solve the issue for me. However, after looking at the "Priority" field of
all pam-configs with "Session-Type: Additional" in Debian [1] I found that
the module with the highest priority which should propably run after
mkhomedir is libpam-script with "Priority: 257"...

I also found that "plinth" include /usr/share/pam-configs/mkhomedir-freedombox
with "Priority: 900". Maybe that is a suitable priority for mkhomedir as well.


[1]:
libpam-afs-session: /usr/share/pam-configs/afs-session
Priority: 64
libpam-cgfs: /usr/share/pam-configs/cgfs
Priority: 0
libpam-cgm: /usr/share/pam-configs/cgm
Priority: 0
libpam-ck-connector: /usr/share/pam-configs/consolekit
Priority: 0
ecryptfs-utils: /usr/share/pam-configs/ecryptfs-utils
Priority: 0
debian-edu-config: /usr/share/pam-configs/edu-umask
Priority: 0
libpam-fscrypt: /usr/share/pam-configs/fscrypt
Priority: 0
libpam-heimdal: /usr/share/pam-configs/krb5
Priority: 704
libpam-krb5: /usr/share/pam-configs/krb5
Priority: 704
libpam-ldap: /usr/share/pam-configs/ldap
Priority: 128
libpam-ldapd: /usr/share/pam-configs/ldap
Priority: 128
libpam-mount: /usr/share/pam-configs/libpam-mount
Priority: 128
libpam-modules: /usr/share/pam-configs/mkhomedir
Priority: 0
plinth: /usr/share/pam-configs/mkhomedir-freedombox
Priority: 900
libpam-mklocaluser: /usr/share/pam-configs/mklocaluser
Priority: 0
libpam-script: /usr/share/pam-configs/pam_script
Priority: 257
libpam-snapper: /usr/share/pam-configs/snapper
Priority: 0
libpam-ssh: /usr/share/pam-configs/ssh
Priority: 64
libpam-sss: /usr/share/pam-configs/sss
Priority: 128
libpam-systemd: /usr/share/pam-configs/systemd
Priority: 0
libpam-tacplus: /usr/share/pam-configs/tacplus
Priority: 257
libpam-tmpdir: /usr/share/pam-configs/tmpdir
Priority: 0
libpam-runtime: /usr/share/pam-configs/unix
Priority: 256
libpam-winbind: /usr/share/pam-configs/winbind
Priority: 192

Bug#914611: transition: yaml-cpp

[Julian Andres Klode]

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

After discussion in #debian-release last week, I NMUed yaml-cpp with an SONAME
bump to fix bug #914190. 

We need to binNMU the reverse dependencies listed in the transition tracker for 
that:

https://release.debian.org/transitions/html/auto-yaml-cpp.html

Ben file:

title = "yaml-cpp";
is_affected = .depends ~ /\b(libyaml\-cpp0\.5v5)\b/ | .depends ~ 
/\b(libyaml\-cpp0\.5d1)\b/;
is_good = .depends ~ /\b(libyaml\-cpp0\.5d1)\b/;
is_bad = .depends ~ /\b(libyaml\-cpp0\.5v5)\b/;


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

Kernel: Linux 4.18.0-11-generic (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)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#914190: yaml-cpp: diff for NMU version 0.5.3-0.2

[Julian Andres Klode]

On Sun, Nov 25, 2018 at 10:51:56AM -0500, 073p...@gmail.com wrote:
> X-Debbugs-CC: j...@debian.org
> 
> 在 2018-11-21三的 17:37 +0100，Julian Andres Klode写道：
> > Actually, I missed a bit in the diff.
> 
> Hi Julian,
> 
> By making the NMU, you actually started an uncoordinated transition [1]. Since
> you initiated it, do you have time registering this transition with the
> Release Team so that the rebuild could be finished in time?

Well, 'uncoordinated' is a bit of a stretch, given that this was the result
of a discussion on #debian-release.

That said, I did open a tracking bug now so it's not forgotten.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#914598: ITP: ethereal -- UCI-compliant chess engine

[Dominik George]

Hi,

>* Package name: ethereal

I find this name unfortunate - the original ethereal has been known as 
wireshark for 10 years now, but you might still want to choose ethereal-chess 
or something.

https://tracker.debian.org/pkg/ethereal

-nik

Bug#914613: xdg-screensaver: Does nothing for many DEs (lxde, dde, enlightenment etc.)

[Teemu Ikonen]

Package: xdg-utils
Version: 1.1.3-1
Severity: normal
Tags: upstream patch

xdg-screensaver detects the running desktop environment and then runs
DE-specific commands to reset or turn on / off the screensaver.  If the
DE is not detected, it uses 'xset s' to control the X server screen
saver extension.

The problem is that xdg-screensaver can recognize more DEs than it has
the code to handle. The generic X server screensaver code is not called
at all when using, for example LXDE. The attached 'sh -x xdg-screensaver
reset' output shows what happens when 'xdg-screensaver reset' is run in
LXDE (nothing useful).

The attached patch makes the 'xset s' codepath the default. It is now
run if the DE is detected, but there is no specialized code to handle
its screensaver.


-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=LXDE

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

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

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.27-1
ii  libnet-dbus-perl   1.1.0-4+b1
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+3+b1
ii  x11-xserver-utils  7.7+7+b1

xdg-utils suggests no packages.

-- no debconf information
+ check_common_commands reset
+ [ 1 -gt 0 ]
+ parm=reset
+ shift
+ [ 0 -gt 0 ]
+ [ -z  ]
+ unset XDG_UTILS_DEBUG_LEVEL
+ [ 0 -lt 1 ]
+ xdg_redirect_output= > /dev/null 2> /dev/null
+ mv -T ... ...
+ grep \.\.\.
+ DEBUG 1 mv -T available
+ [ -z  ]
+ return 0
+ MV=mv -T
+ echo :0.0
+ sed s/:/-/g
+ screensaver_file=/tmp/xdg-screensaver-tpikonen--0.0
+ which lockfile
+ lockfile_command=/usr/bin/lockfile
+ which xprop
+ XPROP=/usr/bin/xprop
+ [ xreset != x ]
+ action=
+ window_id=
+ action=reset
+ detectDE
+ unset GREP_OPTIONS
+ [ -n LXDE ]
+ DE=lxde
+ [ xlxde = x ]
+ [ xlxde = x ]
+ [ xlxde = x ]
+ [ xlxde = xgnome ]
+ [ -f /run/user/1000/flatpak-info ]
+ xscreensaver-command -version
+ grep XScreenSaver
+ dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus 
org.freedesktop.DBus.GetNameOwner string:org.gnome.ScreenSaver
+ dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus 
org.freedesktop.DBus.GetNameOwner string:org.mate.ScreenSaver
+ xautolock -enable
+ [ reset = resume ]
+ perform_action reset
+ result=1
+ [ reset = resume ]
+ [ reset = reset ]
+ grep DPMS is Enabled
+ xset -q
+ [ -n :0.0 -a reset = suspend ]
+ [ reset = suspend ]
+ [ 1 -eq 0 ]
+ exit_failure_operation_failed
+ [ 0 -gt 0 ]
+ exit 4
--- xdg-screensaver.orig2018-05-20 01:18:48.0 +0300
+++ xdg-screensaver 2018-11-25 18:30:09.197525065 +0200
@@ -623,7 +623,7 @@
   [ -n "$DISPLAY" ] && screensaver_xserver "$1"
   ;;
 
-''|generic)
+*|generic)
   [ -n "$DISPLAY" ] && screensaver_xserver "$1"
   ;;
   esac

Bug#914614: [node-promise] contains unnecessary embedded copy of node-asap

[Paolo Greppi]

Package: node-promise
Version: 8.0.1-1
Severity: normal

--- Please enter the report below this line. ---
This package contains an embedded copy of node-asap:
https://sources.debian.org/src/node-promise/8.0.1-1/debian/node_modules/asap/
which is unnecessary now that we have it in the archive:
https://packages.debian.org/sid/node-asap

The embedded copy should be removed and a dependency on node-asap added.

--- System information. ---
Architecture: 
Kernel:   Linux 4.18.0-2-amd64

Debian Release: buster/sid
  500 testing-debug   debug.mirrors.debian.org 
  500 testing mi.mirror.garr.it 
  500 stable  packages.microsoft.com 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
nodejs | 8.11.2~dfsg-1


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#914562: lintian: please decide on Debian Enhancement Proposal spelling (harmonise)

[Thorsten Glaser]

Chris Lamb dixit:

>I believe Lintian should treat dep.debian.net as the canonical
>acronymisation at this point and adopt that. If there is a
>consensus and enough hunger for this to change "upstream" then
>Lintian will very adopt to it.
>
>In that light, I've (at least) made it consistent here:

Agreed, thanks!

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)