Bug#930299: apt: A warning "Ignoring Provides line with non-equal DepCompareOp for package" for two packages

[jim_p]

Package: apt
Version: 1.8.2
Severity: normal

Dear Maintainer,

After yesterday's apt-get update, I get this message everytime I run it

W: Ignoring Provides line with non-equal DepCompareOp for package
firefox-l10n-bn-bd
W: Ignoring Provides line with non-equal DepCompareOp for package
firefox-l10n-bn-in

And I am pretty sure I saw it on some output of apt-cache.
Everything else works fine however, so it is just a minor issue for these 2
packages I guess.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Default-Release "testing";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::AutoRemove::RecommendsImportant "false";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:

Bug#930297: unblock: fastforward/1:0.51-6

[Andreas Beckmann]

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

Please unblock package fastforward

diff -Nru fastforward-0.51/debian/changelog fastforward-0.51/debian/changelog
--- fastforward-0.51/debian/changelog   2019-01-13 00:29:15.0 +0100
+++ fastforward-0.51/debian/changelog   2019-05-28 09:09:15.0 +0200
@@ -1,3 +1,13 @@
+fastforward (1:0.51-6) unstable; urgency=medium
+
+  * QA upload.
+  * Bump version to 1:0.51-6 to not reuse a version number that was used
+before the epoch was added (last pre-epoch upload was 0.51-5.1). This
+avoids clashes on filenames in the archive (versions in filenames don't
+include the epoch).
+
+ -- Andreas Beckmann   Tue, 28 May 2019 09:09:15 +0200
+
 fastforward (1:0.51-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru fastforward-0.51/debian/.gitlab-ci.yml 
fastforward-0.51/debian/.gitlab-ci.yml
--- fastforward-0.51/debian/.gitlab-ci.yml  1970-01-01 01:00:00.0 
+0100
+++ fastforward-0.51/debian/.gitlab-ci.yml  2019-05-28 09:09:15.0 
+0200
@@ -0,0 +1,5 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+variables:
+  RELEASE: experimental

The .gitlab-ci.yml was already committed in the git repository.


unblock fastforward/1:0.51-6

Bug#930298: unblock: dot-forward/1:0.71-5

[Andreas Beckmann]

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

Please unblock package dot-forward

diff -Nru dot-forward-0.71/debian/changelog dot-forward-0.71/debian/changelog
--- dot-forward-0.71/debian/changelog   2019-01-11 21:46:13.0 +0100
+++ dot-forward-0.71/debian/changelog   2019-05-28 01:50:05.0 +0200
@@ -1,3 +1,13 @@
+dot-forward (1:0.71-5) unstable; urgency=medium
+
+  * QA upload.
+  * Bump version to 1:0.71-5 to not reuse a version number that was used
+before the epoch was added (last pre-epoch upload was 0.71-4). This avoids
+clashes on filenames in the archive (versions in filenames don't include
+the epoch).
+
+ -- Andreas Beckmann   Tue, 28 May 2019 01:50:05 +0200
+
 dot-forward (1:0.71-3) unstable; urgency=medium
 
   * QA upload.
diff -Nru dot-forward-0.71/debian/.gitlab-ci.yml 
dot-forward-0.71/debian/.gitlab-ci.yml
--- dot-forward-0.71/debian/.gitlab-ci.yml  1970-01-01 01:00:00.0 
+0100
+++ dot-forward-0.71/debian/.gitlab-ci.yml  2019-05-28 01:50:05.0 
+0200
@@ -0,0 +1,5 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+variables:
+  RELEASE: experimental


unblock dot-forward/1:0.71-5

Andreas

Bug#930296: RM: git-core [all] -- RoQA; NBS; obsolete arch:all package; provided by git

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please clean up the obsolete transitional git-core package.
All rdepends are satisfied by the Provides in git.

Thanks.

Andreas

Bug#930005: regina-rexx: rexxutil error

[Ben Longbons]

Package: libregina3
Version: 3.6-2.1
Followup-For: Bug #930005

Dear Maintainer,

I took a look at this since I thought it would be a simple `-ltinfo`
fix, but it's more complicated than that.

As it is, the package can't possibly run on 64-bit platforms.

There are a *lot* of dangerous warnings; somebody needs to build with
-Werror and fix all of them. This would be a very invasive patch.

If upstream is dead, perhaps the package should simply be removed
from Debian.

-Ben

Bug#902174: #902174: RFP: mes

[Jan Nieuwenhuizen]

Vagrant Cascadian writes:

Hi!

> Mes itself still fails to build, but I updated to 0.19, and made a
> branch based off of janneke's wip branch as well
> (debian/master-wip). configure fails to detect nyacc. It may be an issue
> with multi-arch paths (e.g. /usr/lib/guile/2.2
> vs. /usr/lib/x86_64-linux-gnu/guile/2.2).

Oops, that looks like a bug, thanks.  I hope it's harmless...

> Many of the '#! /bin/sh' scripts contain bashisms which may not be
> compatible with Debian's (usual) /bin/sh, dash after a quick check with
> "checkbashisms". I could patch all the #! headers and audit all the
> calls to "sh" directly, but that seems a bit unmaintainable in the
> long-run.

Sure, this needs to be fixed; I'll look into it, thanks.

> Will need to do some better troubleshooting later... but this appears to
> be the last build failure i tried based on the wip branch:
>
> ../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
> ../include -I ../include/linux/x86_64 -static -o crt1.o
> ../lib/linux/x86_64-mes-mescc/crt1.c
> unhandled exception:unbound-variable:(move-specl-attr)
> Backtrace:
> /<>/scripts/mescc: line 56: 24904 Segmentation fault
> ${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
> /usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
> make[1]: *** [GNUmakefile:95: build] Error 139

This could be a problem with Nyacc 0.93.0, find a patch attached for
that.

Thank you,
Greetings, janneke

>From b3fa6273210200cf2694491b07ed5a328e9a4e62 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Sun, 9 Jun 2019 19:42:42 +0200
Subject: [PATCH] mes: Update to Nyacc 0.93.

* mes/module/nyacc/lang/c99/util.mes: New file.
* mes/module/nyacc/lang/c99/parser.mes: Use it.
* module/mescc/compile.scm (ast->info): Update for Nyacc 0.93.0.
* module/mescc/preprocess.scm (need-progress):  Likewise.
(ast-strip-comment): Likewise.
---
 mes/module/nyacc/lang/c99/parser.mes |  3 +-
 mes/module/nyacc/lang/c99/util.mes   | 45 
 module/mescc/compile.scm |  4 +++
 module/mescc/preprocess.scm  |  3 +-
 4 files changed, 53 insertions(+), 2 deletions(-)
 create mode 100644 mes/module/nyacc/lang/c99/util.mes

diff --git a/mes/module/nyacc/lang/c99/parser.mes b/mes/module/nyacc/lang/c99/parser.mes
index 1a9aaf732..9fbb5fd1e 100644
--- a/mes/module/nyacc/lang/c99/parser.mes
+++ b/mes/module/nyacc/lang/c99/parser.mes
@@ -1,7 +1,7 @@
 ;;; -*-scheme-*-
 
 ;;; GNU Mes --- Maxwell Equations of Software
-;;; Copyright © 2016,2017 Jan (janneke) Nieuwenhuizen 
+;;; Copyright © 2016,2017,2019 Jan (janneke) Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Mes.
 ;;;
@@ -35,5 +35,6 @@
 (mes-use-module (nyacc lang sx-util))
 (mes-use-module (nyacc lang util))
 (mes-use-module (nyacc lang c99 cpp))
+(mes-use-module (nyacc lang c99 util))
 
 (include-from-path "nyacc/lang/c99/parser.scm")
diff --git a/mes/module/nyacc/lang/c99/util.mes b/mes/module/nyacc/lang/c99/util.mes
new file mode 100644
index 0..b4e24885a
--- /dev/null
+++ b/mes/module/nyacc/lang/c99/util.mes
@@ -0,0 +1,45 @@
+;;; -*-scheme-*-
+
+;;; GNU Mes --- Maxwell Equations of Software
+;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen 
+;;;
+;;; This file is part of GNU Mes.
+;;;
+;;; GNU Mes is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Mes is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Mes.  If not, see .
+
+;;; Commentary:
+
+;;; Code:
+
+(mes-use-module (mes guile))
+(mes-use-module (mes catch))
+(mes-use-module (mes fluids))
+(mes-use-module (mes pretty-print))
+(mes-use-module (mes optargs))
+(mes-use-module (srfi srfi-1))
+(mes-use-module (srfi srfi-9))
+(mes-use-module (sxml xpath))
+
+;; FIXME: Nyacc 0.93.0:
+;; FIXME: (mes-use-module (srfi srfi-2))
+;; FIXME: (mes-use-module (sxml fold))
+;; FIXME: (ice-9 popen)
+;; FIXME: (ice-9 rdelim)
+(define (export . rest) #t)
+(define (close-port port) #t)
+
+(mes-use-module (nyacc lang util))
+(mes-use-module (nyacc lang sx-util))
+
+(include-from-path "nyacc/lang/c99/util.scm")
diff --git a/module/mescc/compile.scm b/module/mescc/compile.scm
index 74a2defff..39b352c09 100644
--- a/module/mescc/compile.scm
+++ b/module/mescc/compile.scm
@@ -1713,6 +1713,10 @@
   ((asm-expr ,gnuc (,null ,arg0 . string))
(append-text info (wrap-as (asm->m1 arg0
 
+  ;; Nyacc 0.90.2
+  ((asm-expr ,gnuc (string ,arg0))
+   (append-text info (wrap-as (asm->m1 arg0
+
   ((expr-stmt (fctn-call (p-expr (ident ,name))

Bug#927267: nitroshare: Nitroshare on pc is undiscoverable by nitroshare on mobile, and vice versa, due to old version

[jim_p]

Package: nitroshare
Version: 0.3.3-1.1
Followup-For: Bug #927267

I think its severity should be raised to grave, since it does make the package
unsusable.

There is also a issue report on the project's github page by a kubuntu user who
has exactly the same issue.



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nitroshare depends on:
ii  libappindicator1 0.4.92-7
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbusmenu-glib418.10.20180917~bzr490+repack1-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libqhttpengine0  0.1.0+dfsg1-1+b2
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libqt5network5   5.11.3+dfsg1-1
ii  libqt5svg5   5.11.3-2
ii  libqt5widgets5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6

nitroshare recommends no packages.

Versions of packages nitroshare suggests:
pn  nitroshare-nautilus  

-- no debconf information

Bug#930295: apt: no bash-completion rules for autopurge and reinstall

[Christopher Bayliss]

Package: apt
Version: 1.8.2
Severity: normal

Dear Maintainer,

When you type 'apt autop' 'autopurge' is not completed. The same
applies to 'reinstall'.

Add to that, if you type 'apt reinstall ' you get a list of apt
commands not packages.

bash-completion version:

cjb@aster ~ $ dpkg-query -l 'bash-completion' | grep ii
ii  bash-completion 1:2.8-6  all  programmable completion for the 
bash shell

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

Kernel: Linux 4.19.48 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1
ii  libapt-pkg5.0   1.8.2
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-3
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.7
pn  gnupg | gnupg2 | gnupg1  
pn  powermgmt-base   

-- no debconf information

Bug#930294: Nautilus slow to respond and consumes 100% CPU resource

[Vikram Vincent]

Package: nautilus
Version: 3.32.1-1
Followup-For: Bug #930294

Updated the sources.list and did
~$ sudo apt-get -t experimental install nautilus

Problem reported before persists



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nautilus depends on:
ii  bubblewrap  0.3.1-4
ii  desktop-file-utils  0.23-4
ii  gsettings-desktop-schemas   3.28.1-1
ii  gvfs1.38.1-4
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libgexiv2-2 0.10.9-1
ii  libglib2.0-02.58.3-2
ii  libglib2.0-data 2.58.3-2
ii  libgnome-autoar-0-0 0.2.3-2
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libnautilus-extension1a 3.32.1-1
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  libseccomp2 2.3.3-4
ii  libselinux1 2.8-1+b1
ii  libtracker-sparql-2.0-0 2.1.8-2
ii  nautilus-data   3.32.1-1
ii  shared-mime-info1.10-1
ii  tracker 2.1.8-2
ii  tracker-extract 2.1.6-1
ii  tracker-miner-fs2.1.6-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-4
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3
ii  nautilus-extension-brasero  3.12.2-5
ii  nautilus-sendto 3.8.6-3
ii  totem   3.32.0-1
ii  vlc [mp3-decoder]   3.0.6-1
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#908868: RFH: docker.io // Would like to maintain Docker.io package

[Manas Kashyap]

Awesome, thanks!
So , till the package is in Buster , i will clone it and try to build it
Thank you.

On Mon, Jun 10, 2019 at 10:33 AM Arnaud Rebillout <
arnaud.rebill...@collabora.com> wrote:

>   Hi Manas,
>
> you're very welcome to join the Docker packaging effort!
>
> At the very moment, what you can do to get started is to get familiar with
> the package, git clone from salsa, and build it. Make your setup ready,
> whatever your tools you use to build the package (schroot, pbuilder,
> containers, none?, etc...). If you have issues with that please get in
> touch.
>
> Regarding Buster release, we're almost there, there's nothing you can do.
>
> Once Buster is out, there will be plenty of work, mainly bumping the
> package to latest upstream versions. I also want to try to unbundle
> containerd from the docker package, I've seen that Shengjing Zhu uploaded
> an up-to-date version to experimental. But it depends on how much
> containerd reduced their dependency on docker, and how much docker uses
> release versions of containerd rather than snapshot.
>
> Cheers,
>
>   Arnaud
>
>
> On 6/9/19 12:19 PM, Manas Kashyap wrote:
>
> Will do, thanks!
> I think he is connected to this Mailing thread .
>
> On Sun, Jun 9, 2019 at 10:47 AM Dmitry Smirnov  wrote:
>
>> On Monday, 7 January 2019 1:32:34 AM AEST Manas Kashyap wrote:
>> > I am Manas Kashyap an active Debian contributor and i have knowledge
>> about
>> > Debian packaging and i would like to maintain the package .
>>
>> Thank you. Please speak with Arnaud who is de-facto maintainer of this
>> package.
>>
>> Arnaud, please promote yourself to Maintainer. I'll stay around as
>> Uploader
>> for some time but probably won't be doing any significant work.
>> Please feel free to upgrade this bug report to RFA if you wish.
>>
>> --
>> Cheers,
>>  Dmitry Smirnov.
>>
>> ---
>>
>> It is a mistake to try to look too far ahead. The chain of destiny can
>> only
>> be grasped one link at a time.
>> -- Winston Churchill
>>
>

Bug#930294: Nautilus slow to respond and consumes 100% CPU resource

[Vikram Vincent]

Package: nautilus
Version: 3.30.5-2
Severity: important

Greetings,
With the latest upgrade of Nautilus I find Nautilus hanging

Running Nautilus from the terminal gives:
$ nautilus

(nautilus:15529): Gtk-WARNING **: 10:11:36.857: Duplicate child name in
GtkStack: Thumbnails
(nautilus:15529): Gtk-WARNING **: 10:11:36.859: Duplicate child name in
GtkStack: Thumbnails
(nautilus:15529): Gtk-WARNING **: 10:11:36.861: Duplicate child name in
GtkStack: META-INF
(nautilus:15529): Gtk-WARNING **: 10:11:36.865: Duplicate child name in
GtkStack: Thumbnails
(nautilus:15529): Gtk-WARNING **: 10:11:36.867: Duplicate child name in
GtkStack: Pictures
(nautilus:15529): Gtk-WARNING **: 10:11:36.869: Duplicate child name in
GtkStack: Thumbnails
(nautilus:15529): Gtk-WARNING **: 10:11:36.870: Duplicate child name in
GtkStack: Pictures
(nautilus:15529): Gtk-WARNING **: 10:11:36.872: Duplicate child name in
GtkStack: META-INF
(nautilus:15529): Gtk-WARNING **: 10:11:36.874: Duplicate child name in
GtkStack: Thumbnails
(nautilus:15529): Gtk-WARNING **: 10:11:36.876: Duplicate child name in
GtkStack: META-INF

I tried removing the ~/.cache/tracker folder and then hard reseting the tracker
but to no
improvement.

htop show nautilus using close to 100% of a processor core.
Do let me know if I can provide more specific info to diagonise the problem
Thanks
Vikram



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

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

Versions of packages nautilus depends on:
ii  bubblewrap 0.3.1-4
ii  desktop-file-utils 0.23-4
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-4
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgexiv2-20.10.9-1
ii  libglib2.0-0   2.58.3-2
ii  libglib2.0-data2.58.3-2
ii  libgnome-autoar-0-00.2.3-2
ii  libgtk-3-0 3.24.5-1
ii  libnautilus-extension1a3.30.5-2
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.1.8-2
ii  nautilus-data  3.30.5-2
ii  shared-mime-info   1.10-1
ii  tracker2.1.8-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-4
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3
ii  nautilus-extension-brasero  3.12.2-5
ii  nautilus-sendto 3.8.6-3
ii  totem   3.30.0-4
ii  vlc [mp3-decoder]   3.0.6-1
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#908868: RFH: docker.io // Would like to maintain Docker.io package

[Arnaud Rebillout]

  Hi Manas,

you're very welcome to join the Docker packaging effort!

At the very moment, what you can do to get started is to get familiar
with the package, git clone from salsa, and build it. Make your setup
ready, whatever your tools you use to build the package (schroot,
pbuilder, containers, none?, etc...). If you have issues with that
please get in touch.

Regarding Buster release, we're almost there, there's nothing you can do.

Once Buster is out, there will be plenty of work, mainly bumping the
package to latest upstream versions. I also want to try to unbundle
containerd from the docker package, I've seen that Shengjing Zhu
uploaded an up-to-date version to experimental. But it depends on how
much containerd reduced their dependency on docker, and how much docker
uses release versions of containerd rather than snapshot.

Cheers,

  Arnaud


On 6/9/19 12:19 PM, Manas Kashyap wrote:
> Will do, thanks! 
> I think he is connected to this Mailing thread . 
>
> On Sun, Jun 9, 2019 at 10:47 AM Dmitry Smirnov  > wrote:
>
> On Monday, 7 January 2019 1:32:34 AM AEST Manas Kashyap wrote:
> > I am Manas Kashyap an active Debian contributor and i have
> knowledge about
> > Debian packaging and i would like to maintain the package .
>
> Thank you. Please speak with Arnaud who is de-facto maintainer of
> this
> package.
>
> Arnaud, please promote yourself to Maintainer. I'll stay around as
> Uploader
> for some time but probably won't be doing any significant work.
> Please feel free to upgrade this bug report to RFA if you wish.
>
> -- 
> Cheers,
>  Dmitry Smirnov.
>
> ---
>
> It is a mistake to try to look too far ahead. The chain of destiny
> can only
> be grasped one link at a time.
>         -- Winston Churchill
>

Bug#927913: Second chromium kills the first one, and we see "Restore pages?"

[Jürgen Göricke]

Dear Maintainer,

why don't you create binary packages of chromium and publish them in the 
unstable branch?
Did I miss something important?

I see this Chromium version as a required bugfix release.

I'm asking for clarification.

Thank you!

best regards


pgpDCbBSWtlER.pgp
Description: Digitale Signatur von OpenPGP

Bug#929662: docker.io: CVE-2018-15664 - upstream backport of patch for 18.09

[Arnaud Rebillout]

  Hi,

thanks for reaching out. I applied the patch, that is no problem.
However the new tests that were added makes my machine go crazy and
reach the maximum number of process. Right now I'm configured like that:

    $ ulimit -u
    62688

I will bumb this number but I also want to check a bit more in details
what's happening and report that upstream, as I don't know if this is
expected behavior or not.

You can checkout the branch at
https://salsa.debian.org/docker-team/docker/tree/arnaudr/cve-2018-15664
and try it by yourself if you're curious.

In the meantime, I reached out to the release team at #930293 to prepare
for the next unblock.

So things are in progress, no need for help on this particular issue,
but in general if you're interested in the docker package, then help
with the packaging is more than welcome :)

  Arnaud


On 6/9/19 9:31 AM, Afif Elghraoui wrote:
> Hello,
>
> Is any help needed on this? Upstream has a backport of the patch for the
> 18.09 series (same as Unstable):
>
>   https://github.com/docker/engine/pull/253
>
> Hopefully it won't be too much work to incorporate it.
>
> thanks and regards
> Afif
>

Bug#930293: unblock: docker.io/18.09.1+dfsg1-7

[Arnaud Rebillout]

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

  Hi,

I'm about to upload a fix for #929662 "docker.io: CVE-2018-15664", but
before I do that I'd like to ask a question to the release team.

For now in testing we have docker.io 18.09.1, and on top of that I've
been importing upstream patches to fix RC bugs, because from what I
understand from the Policy, that's what I should do.

The 18.09 series of docker is a so-called "LTS", and that's exactly why
it's THIS release in particular that I targeted for Buster, rather than
a more recent release. Every now and then upstream releases a new dot
release, the latest to date is 18.09.6 (released in May).

According to the upstream changelog, these are mostly fixes. And to get
an idea of the volume, between 18.09.1 to 18.09.6, there was 142
commits, which is rather small compared to the size of docker's codebase.

So it seems to me that upstream really only adds fixes to the 18.09
series, and I also think that our users would be better served if they
could have the latest version of this series in Buster, rather than what
I'm doing now: only patching 18.09.1 with whatever bug was reported in
Debian and marked RC, and ignoring all the other bugs that were reported
and fixed upstream.

Hence I'd like to ask the release team if they think it would be
suitable to unblock docker.io to allow the version 18.09.6 to be
uploaded in Buster? Or, better, wait for the next 18.09.7 that will
include the CVE fix, probably in the next days?

Or should I just stick to 18.09.1, and only upload a new debian version
that only includes the CVE fix?

Thanks,

  Arnaud

unblock docker.io/18.09.1+dfsg1-7

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

[Ryutaroh Matsumoto]

Hi Hilmar,

Thank you for your suggestion.
I filed "6GB real memory is used by lualatex even with small input"
issue at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930292

It is independent of Japanese localization of lualatex.

Best regards,
Ryutaroh

From: Hilmar Preuße 
Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until 
mktexlsr
Date: Mon, 10 Jun 2019 00:02:00 +0200

> Am 26.05.2019 um 03:52 teilte Ryutaroh Matsumoto mit:
> 
> Matsumoto-san,
> 
>> You are right. The way to reproduce this issue (not related to
>> mktexlsr)
>> is
>> (1) Install texlive-full and fonts-noto-cjk from experimental.
>> (2) Run lualatex with the below LaTeX source and have error
>> "Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be
>> found."
>> (3) Installation of fonts-noto-cjk-extra fixes the issue even though
>> no font from
>> fonts-noto-cjk-extra is used. XeLaTeX (with
>> \usepackage[noto]{zxjafont}) and
>> uplatex (with \usepackage[unicode,noto-otc]{pxchfon}) produce the
>> desired
>> PDF without fonts-noto-cjk-extra.
>>
> I'm able to process your file using lualatex right now. Then I tried
> to
> process it using uplatex and xelatex and both did not work. I always
> get
> messages like
> 
> (/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja.sty
> ! Undefined control sequence.
> l.46 \directlua
>{require('ltj-unicode-ccfix.lua')}% catcode of ideographs
> 
> I guess the document class needs luatex. ;-)
> 
> Hilmar
> --
> #206401 http://counter.li.org

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Ryutaroh Matsumoto]

Package: texlive-luatex
Version: 2019.20190605-1
Severity: minor
Tags: upstream l10n

Dear Maintainer,

This report contains UTF-8 encoded text in the latex example.

lualatex uses 6 GB of real memory with a small input (see below)
when the Noto CJK fonts used in the first time.

This is an upstream issue, but I file it here by a suggestion
at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929128#61

A procedure to reproduce this is as follows:

1. Install the Noto CJK fonts, e.g. by apt-get install fonts-noto-cjk 
fonts-noto-cjk-extra

2. If one has already used the Noto CJK fonts by luatex, clear the cache by rm 
-rf $HOME/.texlive201?

3. Process the following file by lualatex

\documentclass{minimal}
\usepackage{fontspec}
\setmainfont{Noto Serif CJK JP}
\setsansfont{Noto Sans CJK JP}
\setmonofont{Noto Sans Mono CJK JP}
\begin{document}
\noindent
{日本語test \bfseries 日本語test}\\
{\sffamily 日本語test \bfseries 日本語test}\\
{\ttfamily 日本語test \bfseries 日本語test}
\end{document}

I believe that the same issue should arise with the Chinese and
the Korean texts, but have not verified it.

Noto CJK Super OTC font (everything is included in the single file)
does not increase the memory usage (= 6GB). Debian Noto CJK package
does not employ super OTC.

Best regards,
Ryutaroh Matsumoto

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2887 Jun 10 12:23 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 23:28 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jun  5 12:18 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jun  5 12:18 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Apr 15 12:58 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jun  5 12:18 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jun  5 12:18 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 Jun 10 12:22 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Apr 15 12:58 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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 texlive-luatex depends on:
ii  libjs-jquery  3.3.1~dfsg-3
ii  tex-common6.11
ii  texlive-base  2019.20190605-1
ii  texlive-binaries  2019.20190605.51237-1

texlive-luatex recommends no packages.

texlive-luatex suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
pn  debhel

Bug#916649: /lib/cryptsetup/cryptdisks-functions: Re: `/etc/init.d/cryptdisks stop` should ignore devices holding / and /usr

[Christopher Bayliss]

Package: cryptsetup-run
Version: 2:2.1.0-4
Followup-For: Bug #916649

G'day!

[NOTE:: I was going to submit a new bug, wrote this up, then found the issue
was already reported in #918008, then merged into this bug (#916649). So I'm
adding a comment to confirm that the issue occurs in debian buster]

When I power off my luks encrypted debian buster system, I get this message:

Stopping remaining crypto disks... sda3_crypt busy...

And 'sda3_crypt busy...' repeats multiple times for about 30 seconds, then a
fail message in red is shown too quickly for me to see and the system halts.

I'm running sysvinit (from the sysvinit-core package) and sysv-rc. This system
is a fresh install I did over the weekend, and due to other unrelated issues,
I reinstalled twice. Each install had the same issue under sysvinit at
shutdown, I have not tested under systemd.

To replicate the issue:

1. Install debian buster with the multi-boot netinst buster RC1 
installer.[1]
2. During installation partition with the luks auto partitioner with "all 
files in one partition" option
3. During installation unselect all tasksel options, including standard 
utilities.
4. After installation install sysvinit-core with: apt install sysvinit-core 
--no-install-recommends
5. Reboot, then purge systemd with: apt purge systemd

Maintainer, I apologise I'm unable to test this in a qemu where I can get a
screen recording I could playback slowly to see the fail message, I just don't
have enough internet data to install debian for the fourth time time :/

I can't find anything meaningful in /var/log/syslog:

Jun  9 23:42:44 aster acpid: client 1625[1000:1000] has disconnected
Jun  9 23:42:48 aster shutdown[2333]: shutting down for system halt
Jun  9 23:42:48 aster init: Switching to runlevel: 0
Jun  9 23:42:48 aster shutdown[2353]: shutting down for system halt

and /var/log/faillog is useless data:

root@aster:~# file /var/log/faillog
/var/log/faillog: data
root@aster:~#

[1] https://cdimage.debian.org/cdimage/buster_di_rc1/multi-arch/iso-cd/

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.19.48 root=/dev/mapper/aster--vg-root ro video=SVIDEO-1:d

-- /etc/crypttab
sda3_crypt UUID=f8bdb1d3-81ca-43ef-af5d-25d073184cdd none luks,discard

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/aster--vg-root /   ext4errors=remount-ro 0   1
# /boot was on /dev/sda2 during installation
UUID=39e8ceff-d65a-429b-9b64-f9816213a583 /boot   ext2defaults  
  0   2
# /boot/efi was on /dev/sda1 during installation
UUID=FCD6-C461  /boot/efi   vfatumask=0077  0   1
/dev/mapper/aster--vg-swap_1 noneswapsw  0   0

-- lsmod
Module  Size  Used by


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

Kernel: Linux 4.19.48 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_RANDSTRUCT
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cryptsetup-run depends on:
ii  cryptsetup-bin 2:2.1.0-4
ii  debconf [debconf-2.0]  1.5.71
ii  dmsetup2:1.02.155-2
ii  libc6  2.28-10

cryptsetup-run recommends no packages.

Versions of packages cryptsetup-run suggests:
pn  dosfstools  
pn  keyutils
ii  liblocale-gettext-perl  1.07-3+b4

-- debconf information:
  cryptsetup/prerm_active_mappings: true

Bug#929715: strace: FTBFS: open: /dev/kvm: No such file or directory

[Sergio Durigan Junior]

Control: severity -1 important

Hi there,

On Saturday, June 01 2019, Steve McIntyre wrote:

> On Wed, May 29, 2019 at 04:30:05PM +0200, Lucas Nussbaum wrote:
>>Hi,
>>
>>During a rebuild of all packages in buster (in a buster chroot, not a
>>sid chroot), your package failed to build on amd64.
>
> Hmmm, that's odd. I've just built the current package in fresh amd64
> and i386 chroots here, with no errors.

I can also confirm building strace on a fresh sid chroot without errors.

> Checking your log, the /dev/kvm error is not fatal and some tests are
> skipped without KVM access.

Also confirming this.

> The actual failures that you're seeing are from 4 stat functions,
> reported several times due to the build setup:
>
> $ grep ^FAIL: strace_4.26-0.2_testing.log  | less
> FAIL: lstat.gen.test
> FAIL: stat.gen.test
> FAIL: lstat.gen.test
> FAIL: trace_lstat.gen.test
> FAIL: stat.gen.test
> FAIL: trace_stat.gen.test
> FAIL: trace_lstat.gen.test
> FAIL: trace_stat.gen.test
> FAIL: lstat.gen
> FAIL: stat.gen
> FAIL: trace_lstat.gen
> FAIL: trace_stat.gen
> FAIL: lstat.gen
> FAIL: stat.gen
> FAIL: trace_lstat.gen
> FAIL: trace_stat.gen
>
> so I've updated the bug title. Checking the log for more details, I'm
> just seeing what *looks* like whitespace differences in the test
> output. But I don't see it here on my system, which is surprising. Is
> there anything at all special about your test setup that I should ba
> aware of? I'm pondering if there's maybe a locale setup difference or
> something, but that's just a guess OTTOMH...!

Yeah, I agree with Steve here; these failures seem strange, but they are
the apparent result of whitespace differences, and not real failures.
For example:

  -lstat("/dev/full", 0xf7544fc0) = -1 EOVERFLOW (Value too large for defined 
data type)
  +lstat("/dev/full", 0xf7544fc0)  = -1 EOVERFLOW (Value too large for defined 
data type)

I spent some time looking into how strace prints these lines, and found
that there is a specific function responsible for calculating the amount
of whitespace that should go between the close parenthesis and the equal
sign (on strace.c):

  void
  tabto(void)
  {
  if (current_tcp->curcol < acolumn)
  tprints(acolumn_spaces + current_tcp->curcol);
  }

Here, "acolumn" is 40 (this value actually comes from a define in
defs.h, "DEFAULT_ACOLUMN"), and "tprints" actually calls
"fputs_unlocked", which is thread-unsafe according to its manpage.  Not
that it matters much, since strace is single-threaded, but these are the
data points I gathered so far.

These functions don't seem to be affected by locale.  I also noticed
that the test is actually comparing the output of "./lstat", which uses
a static way to generate the syscall information lines (i.e., it doesn't
have any mechanism for dynamically generating whitespaces according to
the number of columns printed -- take a look at tests/{xstatx,lstatx}.c
for more info), against the output generated by the compiled strace
binary, which, as stated above, is much more dynamic when printing
whitespaces.  It seems to me that the testcase(s) should be adjusted to
account for possible differences in whitespace.

Having said all that, I believe this bug's severity should be reduced
from "serious" to (at most) "important", at least until Lucas can
provide more information about it.  I've taken the liberty to do that;
feel free to bump it back to "serious" if needed, of course.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#930291: hplip-gui unable to see hp plugin and fails to add printer

[Timothy L. Miller]

Package: hplip-gui
Version: 3.18.12+dfsg0-2

When launching hplip-gui to add a printer, it successfully detects 
printer, launches plugin installer, installs plugin, then says that it 
cannot install printer because it requires a plugin (that was installed 
on prior step).  Does same thing if you run hp-plugin from a CLI to 
install plugin (pluin install succeeds, printer install fails due to 
needing plugin).


Linux duskblade 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 (2019-05-15) 
x86_64 GNU/Linux

Bug#850249: ITP: node-speedometer -- simple speed measurement in javascript

[Gaelan Steele]

Alright, I put together a package for this and put it on mentors 
(https://mentors.debian.net/package/node-speedometer 
), but I’m a little 
confused as to what to do next. I know I need to push it to salsa somehow, but 
I’m not sure how—I created a guest account there, but requesting access to the 
js team results in an error.

Bug#930290: Add the play module to the signed grub-efi build

[Steve McIntyre]

On Mon, Jun 10, 2019 at 02:19:57AM +0100, Steve McIntyre wrote:
>Source: grub2
>Version: 2.02+dfsg1-18
>Severity: minor
>
>Hey Colin,
>
>Please add "play" to the list of modules in the monolithic image that
>we sign. It's a minor thing for most people, but the lack of this will
>mean that blind people using the installer on SB systems won't get the
>beep-beep noise that they're expecting.
>
>Patch shortly...

MR on salsa for this and a couple of other modules:

  https://salsa.debian.org/grub-team/grub/merge_requests/8

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

[Norbert Preining]

Hi

> (2) Run lualatex with the below LaTeX source and have error
> "Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be found."

Yes, because luatexja preloads all the fonts defined in the noto-otf
preset:
\ltjpreset_declare_preset:nx{noto-otf}{
mc-m =  Noto~Serif~CJK~JP~Regular,
mc-bx = Noto~Serif~CJK~JP~Bold,
gt-d =  Noto~Sans~CJK~JP~Regular,
gt-bx = Noto~Sans~CJK~JP~Bold,
gt-u =  Noto~Sans~CJK~JP~Medium,
gt-eb = Noto~Sans~CJK~JP~Black,
mg-m =  Noto~Sans~CJK~JP~Black,
mc-l =  Noto~Serif~CJK~JP~Light,
__custom = false, __office = false, __noembed = false,
}

Thus it fails if the font is not installed.

I haven't seen the uplatex version of your document, but I guess you
load the fonts with the otf package. There the fonts are only necessary
when calling dvipdfmx, and thus only the actually needed fonts are
loaded.

> This seems a feature or a bug in TeXLive 2019 upstream, which should not have
> been filed in BTS. So I close this issue.

I think this is neither a feature nor a bug, it is just that the two
systems work differently.

You can ask the luatexja maintainers to implement on-demand loading of
fonts, but I am not sure how feasible this is.


All the best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

[Norbert Preining]

> (/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja.sty

Yes, luatexja needs lualatex, you cannot use anything else.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#930290: Add the play module to the signed grub-efi build

[Steve McIntyre]

Source: grub2
Version: 2.02+dfsg1-18
Severity: minor

Hey Colin,

Please add "play" to the list of modules in the monolithic image that
we sign. It's a minor thing for most people, but the lack of this will
mean that blind people using the installer on SB systems won't get the
beep-beep noise that they're expecting.

Patch shortly...

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#930289: therion quietly uses the wrong coordinate system

[Olly Betts]

Package: therion
Version: 5.4.3ds1-5
Severity: important
Tags: upstream patch fixed-upstream

Therion 5.4.3 uses the wrong coordinate system if more than one
coordinate system is specified using an EPSG or ESRI code (the function
in question returns a pointer to a static variable which gets
overwritten if called again).

This bug is a regression introduced upstream in 5.4.3 (as an unfortunate
side-effect of eliminating an embedded copy of PROJ, which is something
I'd been encouraging upstream to do)

The bug can be worked around by specifying coordinate systems in a
different way, but is rather problematic because there's usually no
indication that wrong coordinate system has been used apart from getting
incorrect answers out.

It's fixed upstream in 5.4.4 by:
https://github.com/therion/therion/commit/7a30b61b64223602c428e1ba2f70d3f84e52843c

Cheers,
Olly

Bug#908774: grub-common: Update to buster breaks booting

[Steve McIntyre]

Hi Michael,

Apologies for the delayed response to your bug report. I'm going
through trying to help triage older Grub/EFI bug reports, and this
stands out...

On Thu, Sep 13, 2018 at 09:23:13PM +0200, Michael Kesper wrote:
>Package: grub-common
>Version: 2.02+dfsg1-6
>Severity: important
>Tags: d-i
>
>Dear Maintainer,
>
>*** Reporter, please consider answering these questions, where appropriate ***
>
>   * What led up to the situation?
>
>updating grub-common from stretch to buster
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
>sudo apt upgrade (after adding buster to apt sources and
>setting buster as default release)
>
>   * What was the outcome of this action?
>
>After a reboot the system did not boot from ssd at all
>
>   * What outcome did you expect instead?
>
>A system that's able to reboot
>
>- System was on legacy boot before upgrading
>- Upgrading installs grub-efi-amd64, setting boot to EFI
>- grub-efi-amd64 fails because it tries to write to NVRAM / EFI partition
>- there will only be a small error message "system may be unbootable"
>- After reboot, it's not possible to boot

Are you 100% sure you didn't do anything else here to change system
configuration? There's *nothing* in the grub packaging that should be
trying to automatically switch from grub-pc to grub-efi-amd64 on a
straight upgrade!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#930240: ncbi-blast+ FTCBFS: configures for the build architecture

[Aaron M. Ucko]

Helmut Grohne  writes:

> The attached patch fixes the issues above, but does not make ncbi-blast+
> cross buildable. It seems to build a project_tree_builder with the host
> compiler and then fails running it. I didn't figure out how to fix this.

It's possible to point the build system at prebuilt native copies of
project_tree_builder and another helper named datatool, so adding a
preliminary configure+build round for these two tools should do the
trick.  I'll take care of it when I get a chance.

Thanks for the report and initial patch!

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

Bug#921808: grub-efi-amd64 / grub-pc-bin version 2.02+dfsg1-10 fail to boot from mdraid

[Steve McIntyre]

On Sat, Feb 09, 2019 at 01:38:10AM +0100, Robert Senger wrote:
>Package: grub-efi-amd64
>Version: 2.02+dfsg1-10
>Severity: important
>
>Dear Maintainer,
>
>
>   * What led up to the situation?
>Installed Debian Buster on mdraid 1 (2 disks) system using debootstrap. Disks
>are partitioned to allow both UEFI and legacy boot. Configured things in
>chroot. Installed grub-efi-amd64 and grub-pc-bin package.
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>Ran "grub-install --target=i386-pc /dev/sda", "grub-install --target=i386-pc
>/dev/sdb" to install grub in bios-grub partition, "grub-install
>--target=x86_64-efi --no-nvram --removable" to install grub into efi partition,
>done in chroot on laptop with disks attached via usb and mdraid started. Moved
>disks to target system. Tried to boot up.
>
>   * What was the outcome of this action?
>System does not boot, neither UEFI nor legacy mode. GRUB drops to shell.
>
>   * What outcome did you expect instead?
>Expected to get to GRUB menu.
>
>   * Workaround
>Downgraded all GRUB packages to current Debian Stretch versions. No other
>changes. Ran "grub-install ..." in chroot as above. Moved disks to target
>system. Result: System boots fine in both UEFI and legacy mode.
>Upgraded GRUB to Buster versions on running target system, reinstalled GRUB
>(both legacy and efi). After that, system does not boot any more, as above.
>
>   * Note
>System information is not from affected server system, it's from the laptop
>that's running reportbug.

Hi Robert,

Can you please show the output from your grub-install command lines
please? I'm surprised that this ever worked for you even in Stretch,
I'll be honest!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#926178: grub2 efi boot installs grub.cfg file that seems to be ignored (just stays at prompt)

[Steve McIntyre]

Hi Norbert,

On Sat, May 11, 2019 at 12:00:41PM +0200, Norbert Lange wrote:
>I got newer versions to work by adding the "--no-uefi-secure-boot" switch,
>so apparently uefi-secure-boot is not working for me.
>
>older versions might have defaulted to not using it,
>or I did not have the shim packages installed.

I'm curious how you got here. Did you install with Recommends
disabled? There's a Recommends: chain from grub-efi-amd64-bin to
grub-efi-amd64-signed to shim-signed which should cause shim-signed to
be installed.

Does installing shim-signed fix your problem?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#930288: ITP: libminion-backend-sqlite-perl -- SQLite backend for Minion job queue

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : libminion-backend-sqlite-perl
  Version  : 4.002
  Upstream Author  : Dan Book
* URL  : https://github.com/Grinnz/Minion-Backend-SQLite
* License  : Artistic-2.0
  Programming Lang : Perl
  Description  : SQLite backend for Minion job queue

 Minion::Backend::SQLite is a backend for Minion based on Mojo::SQLite. All
 necessary tables will be created automatically with a set of migrations
named
 minion.
 .
 If no connection string or :temp: is provided, the database will be
 created in a temporary directory.


Best,
Utkarsh

Bug#902174: #902174: RFP: mes

[Vagrant Cascadian]

On 2019-05-19, Vagrant Cascadian wrote:
> I made another pass at the Debian packaging needed for Mes.
>
> mescc-tools 0.6.1 builds fine for me:
>
>   https://salsa.debian.org/vagrant/mescc-tools

And uploaded, waiting in NEW:

  https://ftp-master.debian.org/new/mescc-tools_0.6.1-1.html


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#930287: fail2ban: With Postfix, "lost connection after AUTH" never matches because the warn log is used

[Christopher David Howie]

Package: fail2ban
Version: 0.9.6-2

fail2ban provides the following configuration, which does not work on 
Debian by default.


In /etc/fail2ban/filter.d/postfix.conf:

^%(__prefix_line)slost connection after AUTH from \S+\[\]$

In /etc/fail2ban/paths-common.conf:

postfix_log = %(syslog_mail_warn)s

However, Postfix does not log "lost connection after AUTH" messages at 
warn severity by default on Debian.  Replacing the log source line with 
this corrects the issue:


postfix_log = %(syslog_mail)s

--
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document: 
http://www.chrishowie.com/email-preferences/


PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is 
addressed.  If you have received this message it was obviously addressed 
to you and therefore you can read it.


Additionally, by sending an email to ANY of my addresses or to ANY 
mailing lists to which I am subscribed, whether intentionally or 
accidentally, you are agreeing that I am "the intended recipient," and 
that I may do whatever I wish with the contents of any message received 
from you, unless a pre-existing agreement prohibits me from so doing.


This overrides any disclaimer or statement of confidentiality that may 
be included on your message.

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[tony mancill]

On Sun, Jun 09, 2019 at 09:54:50PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 05-06-2019 22:28, Paul Gevers wrote:
> > I really want bug 900912 and 925071 fixed. It seems that is missing from
> > your second approach. Let me sleep on it. What are the chances of you
> > agreeing on doing the +really upstream version dance such that we can
> > get some testing done in unstable?
> 
> Hmm, I forgot I hinted at a follow up from me while I was waiting for a
> response from you.
> 
> Let's get this thing moving. We are running out of time (I do want to
> have some time where the package is actually used before the release). I
> still prefer a version via unstable that I can approve from there, but
> if this is too difficult because of version mangling (hinted in
> private), than please upload to tpu. You asked my preference for two
> versions by you, I suggest to go with the version based on the highest
> one that has been in unstable already.

Hi Paul,

I thought perhaps there was a side conversation going on, so thank you
for resuming the thread.  Of the two debdiffs I included before, neither
was based on the current version in unstable, 11.0.4+4-1.  I will start
with that package and patch upstream back to 11.0.3+7.

For an upload to unstable the version will be: 

  11.0.4+4+really11.0.3+7-1

which will also roll unstable back to the upstream GA release.

More soon - thank you,
tony


signature.asc
Description: PGP signature

Bug#930286: unblock: rclone/1.45-3

[Shengjing Zhu]

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

Please unblock package rclone

(explain the reason for the unblock here)

binNMU rclone/1.45-2 on mips and mipsel FTBFS, the reason is that

 Test killed with quit: ran too long (10m0s).

So just to increase the timeout.

It's now built on all release architectures.

(include/attach the debdiff against the package in testing)

diff -Nru rclone-1.45/debian/changelog rclone-1.45/debian/changelog
--- rclone-1.45/debian/changelog2018-12-12 16:40:34.0 +0800
+++ rclone-1.45/debian/changelog2019-06-10 02:22:04.0 +0800
@@ -1,3 +1,10 @@
+rclone (1.45-3) unstable; urgency=medium
+
+  * d/rules: increase test timeout.
+Some architectures like mips are slow to run test
+
+ -- Shengjing Zhu   Mon, 10 Jun 2019 02:22:04 +0800
+
 rclone (1.45-2) unstable; urgency=medium

   * Add versioned Build-Depends.
diff -Nru rclone-1.45/debian/rules rclone-1.45/debian/rules
--- rclone-1.45/debian/rules2018-12-06 04:52:25.0 +0800
+++ rclone-1.45/debian/rules2019-06-10 02:22:04.0 +0800
@@ -14,3 +14,6 @@

 %:
dh $@ --buildsystem=golang --with=golang,bash-completion
+
+override_dh_auto_test:
+   dh_auto_test -- -timeout 20m

unblock rclone/1.45-3

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

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

Bug#927792: new upstream (8.0)

[Colin Watson]

On Tue, Apr 23, 2019 at 02:36:16PM +0200, Daniel Baumann wrote:
> On 4/23/19 2:32 PM, Colin Watson wrote:
> > to converge our GSSAPI key exchange patches
> 
> oh.. that's nice to hear, we're using that at work.
> 
> guess it doesn't make sense to upload 8.0 without it in the meanwhile
> then..

Indeed, that would have been hard to rip out.

> will patiently wait.. thanks for sharing.

Sorry for the delay, but it's on its way into experimental now.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Reinhard Tartler]

Agreed!

In this case, the bug was reported on Aug 24 2018 by Adrian Bunk. It was
removed about a months later, namely on September 23, for failing to build
from source. Four weeks is arguably quite fast. Or quite slow, depending on
whom you talk to.

I probably could have reacted by disabling the test suite. Or by prodding
you in those four weeks harder. Or at last have the bug fixed by end of
last year, which would have left enough time to re-migrate to testing. In
the future, I'll know better.

Again, sorry. I'm happy to help with getting the package to
buster-backports once it opens.

-rt

On Sun, Jun 9, 2019 at 5:29 PM Chris Wilson 
wrote:

> Hi all,
>
> It seems a bit egregious to kick out packages that were broken by a minor
> version upgrade in one of their dependencies (which after all is not
> supposed to break anything), without any warning, let alone time to fix
> such a complex issue properly.
>
> I hope that Debian will consider carefully whether this course of action
> was really in the best interests of its users.
>
> Thanks, Chris.
>

-- 
regards,
Reinhard

Bug#930285: dgit: the contents of refs/heads/ in dgit repos is confusing

[Colin Watson]

Package: dgit
Version: 8.5
Severity: normal

After starting to use dgit for my uploads recently, I've uploaded grub2
2.02+dfsg1-18 to unstable and grub2 2.04~rc1-1 to experimental.  So far
so good.

However, https://browse.dgit.debian.org/grub2.git/ looks a bit confusing
in light of this.  Firstly, it doesn't list refs/dgit/*, although that's
understandable since IIRC it's hard to persuade cgit to do that sort of
thing.  Less understandably (to me at least), it shows that the dgit
repository has a refs/heads/master that corresponds to the contents of
unstable, but there is no corresponding refs/heads/
corresponding to the contents of experimental.  I realise that dgit
probably doesn't care about refs/heads/ here, but the net effect is
misleading and confusing when just glancing at the web UI.

I have no idea whether it makes more sense to have dgit push something
like refs/heads/experimental to the dgit repositories or to customise
cgit so that it shows refs/dgit/* instead of refs/heads/* (I guess the
latter is less invasive), but it definitely looks odd as it stands.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

[Hilmar Preuße]

Am 26.05.2019 um 03:52 teilte Ryutaroh Matsumoto mit:

Matsumoto-san,


You are right. The way to reproduce this issue (not related to mktexlsr)
is
(1) Install texlive-full and fonts-noto-cjk from experimental.
(2) Run lualatex with the below LaTeX source and have error
"Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be found."
(3) Installation of fonts-noto-cjk-extra fixes the issue even though
no font from
fonts-noto-cjk-extra is used. XeLaTeX (with \usepackage[noto]{zxjafont}) and
uplatex (with \usepackage[unicode,noto-otc]{pxchfon}) produce the desired
PDF without fonts-noto-cjk-extra.


I'm able to process your file using lualatex right now. Then I tried to
process it using uplatex and xelatex and both did not work. I always get
messages like

(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja.sty
! Undefined control sequence.
l.46 \directlua
   {require('ltj-unicode-ccfix.lua')}% catcode of ideographs

I guess the document class needs luatex. ;-)

Hilmar
--
#206401 http://counter.li.org

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

[Hilmar Preuße]

Am 27.05.2019 um 04:09 teilte Ryutaroh Matsumoto mit:

Matsumoto-san,


thanks for your interest and comment. It is (in my opinion) a
well-known issue among Japanese LuaLaTeX users, and I can show a
even worse example (for your fun), which needs 6 GB of real RAM and
10 minutes to compile three lines, in the first time you process a
CJK tex source as below :-)



OK, after re-configuring my VM (put more RAM into it) and stopping a RAM
eating process I was able to compile your document. I guess your comment in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929128#40

is completely valid. The font needed by the document is
"NotoSerifCJKJPLight" and this font is provided by fonts-noto-cjk-extra,
not by fonts-noto-cjk. I just checked the package from experimental.

root@sid:~# dpkg -L fonts-noto-cjk|grep opentype
/usr/share/fonts/opentype
/usr/share/fonts/opentype/noto
/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-Bold.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-Regular.ttc
root@sid:~# dpkg -L fonts-noto-cjk-extra|grep opentype
/usr/share/fonts/opentype
/usr/share/fonts/opentype/noto
/usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-DemiLight.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Light.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Medium.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Thin.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-Black.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-ExtraLight.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-Light.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-Medium.ttc
/usr/share/fonts/opentype/noto/NotoSerifCJK-SemiBold.ttc



Once lualatex complies it, the same file is compiled
in much shorter time and much smaller memory.
(So one needs "rm -rf ~/.texlive201?" to see long compilation time.)





I am a bit reluctant to file the above issue to
texlive-lang-japanese (or texlive-luatex??) because
it does not seem a packaging problem by the Debian TeX team and
they tell us in "reportbug" that


Yes, I'm aware that our reportbug scripts tell this. The reason is that
the Debian TeX team is currently quite small (just Norbert and me) and
we have to push as much as possible work back to the submitter. However
I'm willing to submit and track serious upstream bugs if I have time.

Hilmar
--
#206401 http://counter.li.org

Bug#930284: pipewire: new upstream release 0.2.6

[Simon McVittie]

Package: pipewire
Version: 0.2.5-1
Severity: wishlist

pipewire 0.2.6 is available. The recently-released xdg-desktop-portal
1.4.0 requires that version, which according to the git log changes
the way the permissions work - I'm not sure whether this only affects
xdg-desktop-portal, or whether a more general transition will be needed
when bullseye opens.

smcv

Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys

[Chris Wilson]

Hi all,

It seems a bit egregious to kick out packages that were broken by a minor 
version upgrade in one of their dependencies (which after all is not supposed 
to break anything), without any warning, let alone time to fix such a complex 
issue properly.

I hope that Debian will consider carefully whether this course of action was 
really in the best interests of its users. 

Thanks, Chris. 

Sent from my iPhone

> On 7 Jun 2019, at 22:26, Reinhard Tartler  wrote:
> 
> 
> 
>> On Wed, Jun 5, 2019 at 7:46 PM Chris Wilson  wrote:
>> Hi Reinhard,
>> 
>> Could you have a look at this patch (documented here) to see if it's 
>> something like what you were hoping for?
>> 
> 
> Hi Chris,
> 
> I've uploaded this patch now to unstable, looks good, thanks for the patch. 
> It is still about 80k big, thoguh :-( - quite a lot to review manually. Most 
> of it is actually test code though!
> 
> Unfortunately, I have bad news. I totally missed that boxbackup has already 
> been removed on 23 Sep 2018: 
> https://tracker.debian.org/news/989096/boxbackup-removed-from-testing/
> That's a bummer, because the freeze guidelines rule out migration of packages 
> that aren't part of testing since beginning of February (cf. 
> https://release.debian.org/buster/freeze_policy.html).
> 
> Sorry about that, that's totally on me, I should have been more vocal about 
> this end of last year and totally dropped the ball here.
> 
> I guess we'll have to go the backports route then.
> 
> Best,
> -rt
> -- 
> regards,
> Reinhard

Bug#930283: task-cinnamon-desktop: metapackage should include gnome-terminal

[Leon Gehling]

Package: task-cinnamon-desktop
Version: 3.53
Severity: normal

Please include the gnome-terminal to the cinnamon-desktop metapackage.
This makes the System more likely to be what somebody expects installing the
metapackage



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.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-cinnamon-desktop depends on:
ii  cinnamon-desktop-environment  3.8
ii  task-desktop  3.53
ii  tasksel   3.53

task-cinnamon-desktop recommends no packages.

task-cinnamon-desktop suggests no packages.

-- no debconf information

Bug#930162: unblock: vlc/3.0.7-1

[Salvatore Bonaccorso]

Hi,

On Fri, Jun 07, 2019 at 08:49:31PM +0200, Sebastian Ramacher wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package vlc. The update is the latest bug fix release of
> the 3.0.x branch. As with jessie and stretch, we intend to keep vlc
> update to date with the latest bug fix release for security support.

Just to confirm, this is the case and for stretch(-security) there is
as well already a 3.0.7-0+deb9u1 in the works to be released as DSA,
so it would be great to start in buster right with a 3.0.7-1.

Thank you already and thanks for your hard work towards the buster
release!

Regards,
Salvatore

Bug#929318: unblock: papi/5.7.0+dfsg-1

[Andreas Beckmann]

Followup-For: Bug #929318
Control: tag -1 - moreinfo
Control: retitle -1 unblock: papi/5.7.0+dfsg-2

Hi,

after a re-iteration w.r.t. debian/copyright the package quickly went
through NEW and is now in experimental.

The diffstat looks huge since it records all the (unused) convenience
copies being removed along the non-dfsg bits.

The attached diff between 5.7.0-1 (buster) and 5.7.0+dfsg-1
(experimental) is a git diff because this better copes with the
renames. It also excludes all the deletions (-D).
All that is missing for 5.7.0+dfsg-2 is an "Upload to unstable."
changelog entry.

The transition from libpapi5 to libpapi5.7 will require only a single
binNMU: eztrace.


Andreas


papi-5.7.0+dfsg-1.patch.xz
Description: application/xz

Bug#930282: gnuplot: demote latex2html to Build-Depends-Indep

[Helmut Grohne]

Source: gnuplot
Version: 5.2.6+dfsg1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

gnuplot fails to satisfy its cross Build-Depends for multiple reasons.
One of them is depending on latex2html. While this may be fixable in
latex2html, it is not actually required for performing an arch-only
build. Moving it to Build-Depends-Indep is feasible. The attached patch
demonstrates that.

I compared the -b, -B and -A builds using reproducible builds after
applying the patch. The results are *not* reproducible. In the full
build, gnuplot-doc contains
/usr/share/doc/gnuplot/examples/binary{1,2,3}. These files are missing
in the indep-only build. I checked that this difference is also present
in the unmodified package. You may want to investigate this.

Please consider applying the attached patch. If you happen to know that
more dependencies are only relevant to indep builds, please consier
moving them as well. I only looked into latex2html here, because it
poses a problem to cross building.

Helmut
diff --minimal -Nru gnuplot-5.2.6+dfsg1/debian/changelog 
gnuplot-5.2.6+dfsg1/debian/changelog
--- gnuplot-5.2.6+dfsg1/debian/changelog2019-01-05 23:07:07.0 
+0100
+++ gnuplot-5.2.6+dfsg1/debian/changelog2019-06-09 13:19:34.0 
+0200
@@ -1,3 +1,10 @@
+gnuplot (5.2.6+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote latex2html to Build-Depends-Indep. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Jun 2019 13:19:34 +0200
+
 gnuplot (5.2.6+dfsg1-1) unstable; urgency=medium
 
   * [132187c] New upstream version 5.2.6+dfsg1
diff --minimal -Nru gnuplot-5.2.6+dfsg1/debian/control 
gnuplot-5.2.6+dfsg1/debian/control
--- gnuplot-5.2.6+dfsg1/debian/control  2019-01-05 23:06:15.0 +0100
+++ gnuplot-5.2.6+dfsg1/debian/control  2019-06-09 13:19:33.0 +0200
@@ -16,7 +16,6 @@
qtbase5-dev,
qtbase5-dev-tools,
qttools5-dev-tools,
-   latex2html,
libqt5webkit5-dev,
libqt5opengl5-dev,
libqt5svg5-dev,
@@ -32,6 +31,7 @@
libwxgtk3.0-dev,
zlib1g-dev,
emacs25-nox | emacs25 | emacs24
+Build-Depends-Indep: latex2html,
 Standards-Version: 4.2.1
 Vcs-Browser: https://salsa.debian.org/science-team/gnuplot
 Vcs-Git: https://salsa.debian.org/science-team/gnuplot.git
diff --minimal -Nru gnuplot-5.2.6+dfsg1/debian/rules 
gnuplot-5.2.6+dfsg1/debian/rules
--- gnuplot-5.2.6+dfsg1/debian/rules2017-11-09 05:39:18.0 +0100
+++ gnuplot-5.2.6+dfsg1/debian/rules2019-06-09 13:19:34.0 +0200
@@ -48,10 +48,12 @@
mkdir -p $(BUILDDIR_QT)
cd $(BUILDDIR_QT); CONFIG_SHELL=/bin/sh ../../configure $(conf_opts)  
--enable-qt
 
-override_dh_auto_build:
+override_dh_auto_build-arch:
dh_auto_build -a -- -C $(BUILDDIR_NOX)/src
dh_auto_build -a -- -C $(BUILDDIR_X11) pkglibexecdir='$$(libexecdir)'
dh_auto_build -a -- -C $(BUILDDIR_QT) pkglibexecdir='$$(libexecdir)'
+
+override_dh_auto_build-indep:
cd $(BUILDDIR_X11)/docs; $(MAKE) pdf; $(MAKE) ps; $(MAKE) html; $(MAKE) 
info; ls
cd $(BUILDDIR_X11)/tutorial; $(MAKE) pdf; $(MAKE) ps; ls
sed -i '//,/<\/ADDRESS>/{//!d}' 
$(BUILDDIR_X11)/docs/htmldocs/index.html

Bug#929637: unblock: cross-toolchain-base{,-ports,-mipsen} - rebuilt using glibc 2.28-10

[Paul Gevers]

Control: tags -1 moreinfo

Hi Matthias,

On Mon, 27 May 2019 20:32:48 +0200 Matthias Klose  wrote:
> please unblock the three cross-toolchain-base* packages, rebuilt using glibc
> 2.28-10, which was already accepted for testing.
> 
> cross-toolchain-base 35
> cross-toolchain-base-ports 29
> cross-toolchain-base-mipsen 4

Why would such a rebuild be needed for buster? Does it fix any important
or release critical bug? Sorry if this is obvious to you, but it isn't
to me.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#928185: unblock: openjdk-11/11.0.3+7-4

[Paul Gevers]

Hi,

On 05-06-2019 22:28, Paul Gevers wrote:
> I really want bug 900912 and 925071 fixed. It seems that is missing from
> your second approach. Let me sleep on it. What are the chances of you
> agreeing on doing the +really upstream version dance such that we can
> get some testing done in unstable?

Hmm, I forgot I hinted at a follow up from me while I was waiting for a
response from you.

Let's get this thing moving. We are running out of time (I do want to
have some time where the package is actually used before the release). I
still prefer a version via unstable that I can approve from there, but
if this is too difficult because of version mangling (hinted in
private), than please upload to tpu. You asked my preference for two
versions by you, I suggest to go with the version based on the highest
one that has been in unstable already.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930281: PDF which fails to index with TypeError: object of type 'NoneType' has no len()

[Anthony DeRobertis]

Package: recoll
Version: 1.24.3-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I a bunch of PDFs which fail to index with a Python exception. A bunch
are confidential, but this one isn't.

Traceback (most recent call last):
  File "/usr/share/recoll/filters/rclpdf.py", line 523, in 
rclexecm.main(proto, extract)
  File "/usr/share/recoll/filters/rclexecm.py", line 330, in main
proto.mainloop(extract)
  File "/usr/share/recoll/filters/rclexecm.py", line 257, in mainloop
self.processmessage(processor, params)
  File "/usr/share/recoll/filters/rclexecm.py", line 237, in processmessage
self.answer(data, ipath, eof)
  File "/usr/share/recoll/filters/rclexecm.py", line 176, in answer
self.senditem("Document", docdata)
  File "/usr/share/recoll/filters/rclexecm.py", line 168, in senditem
l = len(data)
TypeError: object of type 'NoneType' has no len()

I'm attaching (a) complete output of it run with loglevel=7; (b) the
PDF; (c) recoll.conf; (d) fields file

- -- System Information:
Debian Release: 10.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (130, 
'unstable-debug'), (130, 'unstable'), (120, 'experimental-debug'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages recoll depends on:
ii  recollcmd  1.24.3-3
ii  recollgui  1.24.3-3

recoll recommends no packages.

recoll suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXP1XtxUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf78iACfYnW4XiezE2mKKpWWB1xVIv0t48gA
oITYXzhoAgrB3ej/h4sOGJlmn1F7
=be9G
-END PGP SIGNATURE-
Script started on 2019-06-09 14:59:23-04:00 [TERM="xterm" TTY="/dev/pts/21" 
COLUMNS="162" LINES="59"]
Running scope as unit: run-r947e58c5876741de815297dad38b0b6e.scope
:3:common/rclinit.cpp:312::Configuration directory: /home/anthony/.recoll
:4:common/rclconfig.cpp:558::RclConfig::initThrConf: autoconf requested. 8 
concurrent threads available.
:4:common/rclconfig.cpp:604::RclConfig::initThrConf: chosen config (ql,nt): (2, 
5) (2, 3) (2, 1) 
:5:common/rclinit.cpp:351::rclinit: will use vfork() for starting commands
:3:index/recollindex.cpp:667::recollindex: changing current directory to [/tmp]
:4:utils/execmd.cpp:469::ExecCmd::startExec: (0|0) 
/usr/share/recoll/filters/rclcheckneedretry.sh 
:4:utils/execmd.cpp:993::ExecCmd::wait: got status 0x256
:3:index/recollindex.cpp:700::recollindex: starting up
:4:utils/execmd.cpp:469::ExecCmd::startExec: (0|0) /usr/bin/ionice {-c} {3} 
{-p} {29047} 
:4:utils/execmd.cpp:993::ExecCmd::wait: got status 0x0
:4:rcldb/rcldb.cpp:917::Db::open: m_isopen 0 m_iswritable 0 mode 1
:5:rcldb/stoplist.cpp:35::StopList::StopList: 
file_to_string(/home/anthony/.recoll/stoplist.txt) failed: open/stat: errno: 2 
: 
:4:rcldb/rcldb.cpp:249::RclDb:: threads: haveWriteQ 1, wqlen 2 wqts 1
:4:rcldb/rcldb.cpp:943::Db::open: lastdocid: 5026
:4:index/fsindexer.cpp:135::FsIndexer: threads: haveIQ 1 iql 2 iqts 5 haveSQ 1 
sql 2 sqts 3
:4:index/fsindexer.cpp:322::FsIndexer::indexFiles
:5:index/fsindexer.cpp:527::FsIndexerInternfileWorker: task fn 
/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf
:4:index/fsindexer.cpp:639::processone: needupdate 1 noretry 0 existing 
4294967295 oldsig []
:5:index/fsindexer.cpp:672::processone: processing: [48 KB ] 
/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf
:5:internfile/internfile.cpp:123::FileInterner::FileInterner(fn=/home/anthony/Filing/Schwab/2015/2015-06
 — Important notice regarding delivery of security holder documents.pdf)
:5:internfile/uncomp.cpp:41::Uncomp::Uncomp: m_docache: 0
:4:internfile/internfile.cpp:168::FileInterner::init fn 
[/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf] mime [(null)] preview 0
:4:utils/execmd.cpp:469::ExecCmd::startExec: (0|1) git-annex-meta-to-recoll 
{/home/anthony/Filing/Schwab/2015/2015-06 — Important notice regarding delivery 
of security holder documents.pdf} 
:5:utils/netcon.cpp:369::Netcon::selectloop: fd 11 has 0x0 mask, erasing
:5:utils/execmd.cpp:827::ExecCmd::doexec: selectloop returned 0
:4:utils/execmd.cpp:993::ExecCmd::wait: got status 0x0
:4:internfile/mimehandler.cpp:268::getMimeHandler: mtype [application/pdf] 
filtertypes 1
:4:internfile/mimehandler.cpp:64::getMimeHandlerFromCache: 
259dc001f1d38c8b4c425d19d34b1c4f cache size 0
:4:internfile/mimehandler.cpp:80::getMimeHandlerFromCache: 
259dc001f1d38c8b4c425d19d34b1c4f not found
:4:internfile/internfile.cpp:255::FileInterner:: i

Bug#928909: bleachbit: new upstream 2.2

[Hugo Lefeuvre]

Hi Jonatan,

thanks for the reminder. 2.2 will be available on experimental soon.

regards,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#930280: libvterm FTCBFS: libtool-bin dependeny unsatisfiable

[Helmut Grohne]

Source: libvterm
Version: 0~bzr718-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

libvterm Build-Depends on libtool-bin. That's bad, because we want to
remove[1] it from the archive. Additionally, libtool-bin is a
cross-unsatisfiable dependency and thus breaks cross building. Please
drop the dependency. The attached patch creates a local libtool for the
package build. Please consider applying it.

Helmut

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836123#10
diff --minimal -Nru libvterm-0~bzr718/debian/changelog 
libvterm-0~bzr718/debian/changelog
--- libvterm-0~bzr718/debian/changelog  2018-03-17 19:24:13.0 +0100
+++ libvterm-0~bzr718/debian/changelog  2019-06-09 12:25:01.0 +0200
@@ -1,3 +1,10 @@
+libvterm (0~bzr718-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Stop using libtool-bin. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Jun 2019 12:25:01 +0200
+
 libvterm (0~bzr718-1) unstable; urgency=medium
 
   * Merge latest snapshot
diff --minimal -Nru libvterm-0~bzr718/debian/configure.ac 
libvterm-0~bzr718/debian/configure.ac
--- libvterm-0~bzr718/debian/configure.ac   1970-01-01 01:00:00.0 
+0100
+++ libvterm-0~bzr718/debian/configure.ac   2019-06-09 11:30:31.0 
+0200
@@ -0,0 +1,4 @@
+AC_INIT([dummy],[1.0])
+LT_INIT
+AC_PROG_LIBTOOL
+AC_OUTPUT
diff --minimal -Nru libvterm-0~bzr718/debian/control 
libvterm-0~bzr718/debian/control
--- libvterm-0~bzr718/debian/control2018-03-17 19:24:13.0 +0100
+++ libvterm-0~bzr718/debian/control2019-06-09 12:24:51.0 +0200
@@ -1,7 +1,7 @@
 Source: libvterm
 Priority: optional
 Maintainer: James McCoy 
-Build-Depends: debhelper (>= 11), libtool-bin
+Build-Depends: debhelper (>= 11), autoconf, libtool
 Standards-Version: 4.1.3
 Section: libs
 Homepage: http://www.leonerd.org.uk/code/libvterm/
diff --minimal -Nru libvterm-0~bzr718/debian/rules 
libvterm-0~bzr718/debian/rules
--- libvterm-0~bzr718/debian/rules  2018-03-17 19:24:13.0 +0100
+++ libvterm-0~bzr718/debian/rules  2019-06-09 12:25:01.0 +0200
@@ -8,20 +8,30 @@
 include /usr/share/dpkg/pkg-info.mk
 
 export CFLAGS CPPFLAGS LDFLAGS
+export LIBTOOL=$(CURDIR)/debian/libtool/libtool
 
 MAKED = $(MAKE) -C libvterm-0.0
 
 %:
dh $@
 
-override_dh_auto_build-arch:
+debian/libtool/libtool:
+   mkdir debian/libtool
+   cp debian/configure.ac debian/libtool/
+   cd debian/libtool && LIBTOOLIZE='libtoolize -i' autoreconf -f -i
+   dh_auto_configure --sourcedirectory=debian/libtool
+
+override_dh_auto_clean: debian/libtool/libtool
+   dh_auto_clean
+
+override_dh_auto_build-arch: debian/libtool/libtool
$(MAKE) distdir
$(MAKED) VERBOSE=1 PREFIX=/usr LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
 
-override_dh_auto_install-arch:
+override_dh_auto_install-arch: debian/libtool/libtool
$(MAKED) VERBOSE=1 PREFIX=/usr LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) 
DESTDIR=$(CURDIR)/debian/tmp install
 
-override_dh_auto_test:
+override_dh_auto_test: debian/libtool/libtool
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
$(MAKED) VERBOSE=1 test
 endif

Bug#930221: unblock: m2crypto/ 0.31.0-3.1

[Paul Gevers]

Control: tags -1 confirmed

Hi Daniel,

On 09-06-2019 10:05, Daniel Stender wrote:
> On 6/8/19 9:20 PM, Paul Gevers wrote
>> If this version gets uploaded, be it by the maintainers of m2crpyto or
>> by Sebastian, it will be acceptable from the Release Team point of view.
>  
> I've uploaded the package including these patches.

Thanks a lot.

In my opinion, no need to re-upload, but the check for the OpenSSL
version seems to be failing (see below). That test should have been skipped.

I'll trigger a test with openssl 1.1.1c to verify, but the test passed
in unstable already. If that passes, I'll unblock this.

Paul

In testing (with openssl/1.1.1b-2):
=== FAILURES
===
___ RSATestCase.test_public_encrypt


self = 

@unittest.skipIf(m2.OPENSSL_VERSION_NUMBER < 0x1010103f,
 'Relies on fix which happened only in OpenSSL 1.1.1c')
def test_public_encrypt(self):
priv = RSA.load_key(self.privkey)
# pkcs1_padding, pkcs1_oaep_padding
for padding in self.e_padding_ok:
p = getattr(RSA, padding)
ctxt = priv.public_encrypt(self.data, p)
ptxt = priv.private_decrypt(ctxt, p)
self.assertEqual(ptxt, self.data)

# sslv23_padding
ctxt = priv.public_encrypt(self.data, RSA.sslv23_padding)
>   res = priv.private_decrypt(ctxt, RSA.sslv23_padding)

tests/test_rsa.py:129:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
data =
'\x1c\x1a\xa2o>\xb7e\x0e\xeaX\x86\x0c\xda\x80y%t,\xccyN\xde\xed;P\xf8\xddL\x9de\x8e\x9b\\\xbbV\x16\x02\xb7\x11\x95\x02...xbb\\\xbe\x0b\x8b\xdb~\xb3HS\xdfIH\x7f\xec5L\xd1-FN\x882-I\xe3\x95\x11\xe0\xdeZ\xd8\xd2M\\\xc3\x93\xf2\xea\xa3\xcc\xa0'
padding = 2

def private_decrypt(self, data, padding):
# type: (bytes, int) -> bytes
assert self.check_key(), 'key is not initialised'
>   return m2.rsa_private_decrypt(self.rsa, data, padding)
E   RSAError: sslv3 rollback attack



signature.asc
Description: OpenPGP digital signature

Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items

[Simon McVittie]

On Sun, 09 Jun 2019 at 18:21:10 +0200, Adam Borowski wrote:
> my personal reason to uninstall gvfs was that automounting USB sticks and SD
> cards is harmful for me

gvfs doesn't do this, so preventing automounting by removing gvfs is not
reliable (at best, you're only preventing automounting accidentally,
by the fallback GUnixMountMonitor not being sufficiently complete to
signal new devices appearing). Whatever higher-level component responds
to new drives/volumes appearing by mounting them should have a way to
disable that behaviour.

For example, in current GNOME automount is done by gnome-shell, in GNOME
Flashback it's done by the gnome-flashback service, and in older versions
of both it was part of gnome-settings-daemon, all of which share a dconf
setting "/org/gnome/desktop/media-handling/automount" which can turn it
off. In XFCE's thunar, as far as I can tell, the thunar-volman package
is responsible for this and has two settings "/automount-drives/enabled"
and "/automount-drives/enabled" in the xfconf framework (or removing
thunar-volman would probably also work).

There are also UDISKS_AUTO and UDISKS_IGNORE udev properties
that you can set on devices via udev rules, which higher-level
components are meant to use as a hint that this particular device
is not to be mounted automatically, or should not appear at all,
respectively. In GLib with gvfs, UDISKS_AUTO gets propagated up through
the g_volume_should_automount() method.

> So you actually care about Recommends being too strong?

Of course. Recommends and Suggests are a trade-off between a hard
dependency and no relationship, and maintainers should choose carefully
case-by-case whether a related package that is not strictly essential
should be a Depends, Recommends, Suggests, or not represented in dpkg
metadata. Whatever we choose, not everyone is going to like the decision,
but a decision needs to be made anyway - preferably one that balances
the partially-conflicting goals of making default installations as good
as possible for as many people as possible, having enough flexibility
to allow for unusual installations, and preventing broken situations
from being installable.

I can understand the appeal of a more minimal system, and I turn off
some selected Recommends myself, but I don't think globally disabling
installation of Recommends and expecting a system as complex as a full
desktop environment to have all of its intended behaviours is sustainable.
If users demand full functionality with Recommends disabled, one logical
but ironic course of action available to maintainers is to use fewer
Recommends and more Depends, which of course leads to the exact opposite
of what users who turn off Recommends were presumably aiming for.

> On the other hand, I have serious doubts if fixing the fallback mechanism is
> a good use for your time.  Perhaps it'd be better for it to return "nothing
> removable" if gvfs is not installed?

I don't think falling back to "there are no devices, no volumes and no
mounts" is really the intent of the API, but if you want to propose this
upstream as the fallback behaviour, go ahead. I am not going to forward
that request upstream myself, because proposing changes that I don't
personally want and can't justify well will tend to get them rejected,
and I don't want to sabotage the opportunity for someone who wants this
more than I do to justify it better than I could.

smcv

Bug#930279: trimage: Please package new upstream version 1.0.6 (also an ITS request)

[Boyuan Yang]

Package: trimage
Severity: important
Version: 1.0.5+git20130126.e47888e-1
X-Debbugs-CC: kil...@kilianvalkhof.com

Dear trimage maintainers,

The trimage upstream has requested to update trimage in Debian to version
1.0.6. [1] Please consider packaging the new version in the Bullseye cycle.

Regards,
Boyuan Yang

[1] https://github.com/Kilian/Trimage/pull/47


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

Bug#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

[Paul Gevers]

Hi,

On 08-06-2019 23:15, Dr. Tobias Quathamer wrote:
> thanks for the update. I suspect that the FTBFS is due to the (probably
> accidental) upload of a new version of
> golang-github-mendersoftware-mender-artifact to unstable instead of
> experimental.
> 
> I've just reverted that package with a +really version. Could you
> reschedule the binNMU in a couple of hours, after the updated package
> has been ACCEPTED in unstable?

Will do so shortly.

> Should I file a separate bug report for the unblock of
> golang-github-mendersoftware-mender-artifact?

I'll take care of that.

However, it seems that my previous report was missing some pieces (I
only check amd64 last time).

coyim FTBFS previously already on arm64
https://buildd.debian.org/status/fetch.php?pkg=coyim&arch=arm64&ver=0.3.8%2Bds-6%2Bb10&stamp=1552303594&raw=0

google-cloud-print-connector FTBFS on armel
https://buildd.debian.org/status/fetch.php?pkg=google-cloud-print-connector&arch=armel&ver=1.12-1%2Bb22&stamp=1559987469&raw=0

prometheus FTBFS on armel
https://buildd.debian.org/status/fetch.php?pkg=prometheus&arch=armel&ver=2.7.1%2Bds-3%2Bb11&stamp=1559988997&raw=0

prometheus-alertmanager FTBFS on mips
https://buildd.debian.org/status/fetch.php?pkg=prometheus-alertmanager&arch=mips&ver=0.15.3%2Bds-3%2Bb1&stamp=1559990584&raw=0

rclone FTBFS previously already on mips and mipsel
https://buildd.debian.org/status/fetch.php?pkg=rclone&arch=mips&ver=1.45-2%2Bb10&stamp=1552305912&raw=0
https://buildd.debian.org/status/fetch.php?pkg=rclone&arch=mipsel&ver=1.45-2%2Bb10&stamp=1552305234&raw=0

rkt FTBFS previously already on arm64 and ppc64el
https://buildd.debian.org/status/fetch.php?pkg=rkt&arch=arm64&ver=1.30.0%2Bdfsg-7%2Bb10&stamp=1552301141&raw=0
https://buildd.debian.org/status/fetch.php?pkg=rkt&arch=ppc64el&ver=1.30.0%2Bdfsg-7%2Bb10&stamp=1552301135&raw=0

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930278: phonesim does not run on startup

[Ilya Tsindlekht]

Package: ofono-phonesim
Version: 1.21-1
Severity: wishlist

Phonesim is necessary for the bluetooth HFP profile implementation in
pulseaudio, so it is desireable to have an option to start it at boot time. I
wrote a systemd service file to do this.



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

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

Versions of packages ofono-phonesim depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-7
ii  libqt4-dbus 4:4.8.7+dfsg-18
ii  libqt4-network  4:4.8.7+dfsg-18
ii  libqt4-script   4:4.8.7+dfsg-18
ii  libqt4-xml  4:4.8.7+dfsg-18
ii  libqtcore4  4:4.8.7+dfsg-18
ii  libqtgui4   4:4.8.7+dfsg-18
ii  libstdc++6  8.3.0-7

ofono-phonesim recommends no packages.

ofono-phonesim suggests no packages.




*** /etc/systemd/system/phonesim.service
[Unit]
Description=Phonesim modem emulator for ofono
After=ofono.service
StartLimitedIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
ExecStart=/usr/bin/ofono-phonesim -p 12345 /usr/share/phonesim/default.xml
ExecStartPost=/bin/sleep 1
ExecStartPost=/usr/bin/dbus-send --system --dest=org.ofono --type=method_call
/phonesim org.ofono.Modem.SetProperty string:"Powered" variant:boolean:"true"
StandartError=null

Bug#903635: This is RC; breaks unrelated software

[Shengjing Zhu]

Hi Jonathan,

On Wed, Apr 24, 2019 at 08:04:43PM +0100, Jonathan Dowland wrote:
> severity 903635 critical
> thanks
> 
> Justification: "makes unrelated software on the system (or the whole system) 
> break"
> 
> Installing docker.io changed my FORWARD chain policy to DROP, breaking
> networking for unrelated virsh-based VMs that I had installed on the machine 
> at
> the time. This matches exactly the text for severity: serious.

Could you provide more info about "changed my FORWARD chain policy to
DROP"?

I set add `"iptables": false` to `/etc/docker/daemon.json`. Then reboot
my laptop. Then run `iptables-save`.

The result is
```
# Generated by xtables-save v1.8.2 on Mon Jun 10 01:22:35 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Mon Jun 10 01:22:35 2019
```

The FORWARD policy is ACCEPT.

The origin bug is true that, docker still adds an empty chain, when
iptables=false is set.

But IMHO your justification is not real.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#930091: bison is wrongly marked Multi-Arch: foreign

[Chuan-kai Lin]

Status update.  The ratt run is still in progress, having built 152
out of 547 reverse dependencies.  Out of those 152 only 1 fails to
build (libbonobo), and that package is already FTBFS for reasons
entirely unrelated to bison.

So I think A is the way to go, and it is likely that very few packages
will need to manually add libbison-dev as build dependency.

Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

[Shawn Landden]

Ping.

lld-7 should be disabled on ppc64el

Bug#928052: CVE-2019-11502 CVE-2019-11503

[Salvatore Bonaccorso]

Hi,

I have not reviewed the whole patch but the following appeared on my
redar while reviewing:

On Sun, Jun 09, 2019 at 05:09:15PM +0900, Kentaro Hayashi wrote:
> +  [ Kentaro Hayashi ]
> +  * Non-maintainer upload.
> +  * d/patches/CVE-2019-11502.patch: fix unintended access to a private /tmp
> +directory. (Closes: #928052)

This should not close the bug yet as it only adresses CVE-2019-11502.
#928052 both tracks CVE-2019-11502 CVE-2019-11503. So onless I miss
smoething the changes to fix CVE-2019-11503 are missing yet.

Regards,
Salvatore

Bug#930277: unblock: gdcm_2.8.8-9

[Gert Wollny]

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

Please unblock package gdcm-2.8.8-9 

The package is testing gdcm-2.8.8-6 FTBFS on some architectures
(#929718) because the provided .symbols file changes depending on the
build dependencies.

With version gdcm-2.8.8-9 the symbols file is dropped again because
this seem so be the only viable approach to alliviate this problem when
it comes to C++ libraries.

Many thanks, 
Gert 

unblock gdcm/2.8.8-9

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

Kernel: Linux 4.19.48-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff -Nru gdcm-2.8.8/debian/changelog gdcm-2.8.8/debian/changelog
--- gdcm-2.8.8/debian/changelog	2019-01-13 09:26:00.0 +0100
+++ gdcm-2.8.8/debian/changelog	2019-03-26 22:07:17.0 +0100
@@ -1,3 +1,24 @@
+gdcm (2.8.8-9) unstable; urgency=medium
+
+  * d/*.symbols: remove symbols file, with C++ libraries this
+just doesn't work well enough.
+
+ -- Gert Wollny   Tue, 26 Mar 2019 22:07:17 +0100
+
+gdcm (2.8.8-8) unstable; urgency=medium
+
+  * d/libvtkgdcm2.8a.symbols: Attempt to fix symbols on mips/mipsel
+
+ -- Gert Wollny   Tue, 26 Mar 2019 19:35:20 +0100
+
+gdcm (2.8.8-7) unstable; urgency=medium
+
+  [ Gianfranco Costamagna ]
+  * Fixup symbols file, mark as optional some symbols disappearing
+with a -O3 build
+
+ -- Gert Wollny   Fri, 08 Mar 2019 11:33:29 +0100
+
 gdcm (2.8.8-6) unstable; urgency=medium
 
   * d/p/fiX_charls_2: Fix compilation with CharLS-2.0
diff -Nru gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols
--- gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols	2019-01-13 09:26:00.0 +0100
+++ gdcm-2.8.8/debian/libvtkgdcm2.8a.symbols	1970-01-01 01:00:00.0 +0100
@@ -1,1001 +0,0 @@
-libvtkgdcm.so.2.8 libvtkgdcm2.8a #MINVER#
-* Build-Depends-Package: libvtkgdcm2-dev
- (regex|c++|optional)^_ZNK?4gdcm9Attribute.*@Base$ 2.8.7
- (regex|c++|optional)^_ZNK?4gdcm7Element.*@Base$ 2.8.7
- (regex|c++|optional)^_ZN?St.*@Base$ 2.8.7
- _Z23vtkImageRGBToYBRExecuteIaEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIcEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIdEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIfEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIhEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIiEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIjEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIlEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteImEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIsEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteItEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIxEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageRGBToYBRExecuteIyEvP16vtkImageRGBToYBRP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIaEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIcEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIdEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIfEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIhEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIiEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIjEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIlEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteImEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIsEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteItEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIxEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkImageYBRToRGBExecuteIyEvP16vtkImageYBRToRGBP12vtkImageDataS3_PiiPT_@Base 2.8.7
- _Z23vtkLookupTable16MapDataIaEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIcEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIdEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIfEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIhEvP16vtkLookupTable16PT_Ptiii@Base 2.8.7
- _Z23vtkLookupTable16MapDataIiEvP16vt

Bug#929724: unblock: shim-signed/1.33 (was Re: unblock: shim-signed/1.32)

[Steve McIntyre]

Control: retitle -1 unblock: shim-signed/1.33

Hey folks,

We've just got the new signed binaries back from Microsoft this
morning, so I've now updated to use them and just uploaded
shim-unsigned 1.33. Summary of changes since 1.30:

  * Build against new signed binaries corresponding to
15+1533136590.3beb971-7
  * Update Build-Depends and Depends to match. Closes: #928107
  * Drop the hard-coded version in Built-Using; pick up the version of
shim we're using properly.
  * Display the sha256sums of the binaries as we check them
  * Add Breaks/Replaces to shim-signed-common for
update-secureboot-policy etc. Closes: #929673
  * update-secureboot-policy: fix error if /var/lib/dkms does not
exist. Closes: #923718
  * Separate the helper scripts into a new shim-signed-common package,
apart from the actual signed shim binaries so that we can
sensibly support co-installability using Multi-Arch.
Closes: #928486
  * Add/update translations:
+ Italian (Closes: #915993, thanks to Beatrice Torracca)
+ Swedish (Closes: #921410, thanks to Matrin Bagge)
+ Russian (Closes: #99, thanks to Lev Lamberov)
+ Dutch (Closes: #917580, #926664, thanks to Frans Spiesschaert)
  * Remove doc link used to quieten old lintian versions

The main fixes are for #928486 (which is blocking some users building
multi-arch live media), but I've also rolled in a trivial fix for
#923718 (cosmetic) and a bunch of translation updates (filtered out
here). #929673 showed I made a daft mistake with the 1.31 upload. :-(

This package fixes our one outstanding RC bug in version 1.30
(#928107), which was impossible to fix until now.

debdiff attached.

unblock shim-signed/1.33

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.
diff -Nru shim-signed-1.30/Makefile shim-signed-1.33/Makefile
--- shim-signed-1.30/Makefile   2019-04-19 15:18:30.0 +0100
+++ shim-signed-1.33/Makefile   2019-06-09 17:16:05.0 +0100
@@ -9,6 +9,7 @@
cp /usr/lib/shim/shim$(EFI_ARCH).efi build/shim$(EFI_ARCH).efi.signed
sbattach --attach build/detached-sig build/shim$(EFI_ARCH).efi.signed
cmp shim$(EFI_ARCH).efi.signed build/shim$(EFI_ARCH).efi.signed
+   sha256sum shim$(EFI_ARCH).efi.signed build/shim$(EFI_ARCH).efi.signed
 
 clean:
rm -rf build
diff -Nru shim-signed-1.30/debian/changelog shim-signed-1.33/debian/changelog
--- shim-signed-1.30/debian/changelog   2019-04-23 00:01:10.0 +0100
+++ shim-signed-1.33/debian/changelog   2019-06-09 17:32:54.0 +0100
@@ -1,3 +1,38 @@
+shim-signed (1.33) unstable; urgency=medium
+
+  * Build against new signed binaries corresponding to
+15+1533136590.3beb971-7
+  * Update Build-Depends and Depends to match. Closes: #928107
+  * Drop the hard-coded version in Built-Using; pick up the version of
+shim we're using properly.
+  * Display the sha256sums of the binaries as we check them
+
+ -- Steve McIntyre <93...@debian.org>  Sun, 09 Jun 2019 17:32:54 +0100
+
+shim-signed (1.32) unstable; urgency=medium
+
+  * Add Breaks/Replaces to shim-signed-common for
+update-secureboot-policy etc. Closes: #929673
+
+ -- Steve McIntyre <93...@debian.org>  Tue, 28 May 2019 14:23:54 +0100
+
+shim-signed (1.31) unstable; urgency=medium
+
+  * update-secureboot-policy: fix error if /var/lib/dkms does not
+exist. Closes: #923718
+  * Separate the helper scripts into a new shim-signed-common package,
+apart from the actual signed shim binaries so that we can
+sensibly support co-installability using Multi-Arch.
+Closes: #928486
+  * Add/update translations:
++ Italian (Closes: #915993, thanks to Beatrice Torracca)
++ Swedish (Closes: #921410, thanks to Matrin Bagge)
++ Russian (Closes: #99, thanks to Lev Lamberov)
++ Dutch (Closes: #917580, #926664, thanks to Frans Spiesschaert)
+  * Remove doc link used to quieten old lintian versions
+
+ -- Steve McIntyre <93...@debian.org>  Mon, 27 May 2019 23:02:10 +0100
+
 shim-signed (1.30) unstable; urgency=medium
 
   * Force the built-using version to be 15+1533136590.3beb971-6. That
diff -Nru shim-signed-1.30/debian/control shim-signed-1.33/debian/control
--- shim-signed-1.30/debian/control 2019-04-22 23:59:15.0 +0100
+++ shim-signed-1.33/debian/control 2019-06-09 16:50:25.0 +0100
@@ -4,10 +4,7 @@
 Maintainer: Debian EFI Team 
 Uploaders: Steve McIntyre <93...@debian.org>, Steve Langasek 

 Build-Depends: debhelper (>= 9),
-# Need shim-unsigned version 15+1533136590.3beb971-5 so we can check the
-# signature on the right version of shim. Version -6 saw arm64 toolchain
-# changes that changed the binary. Ugh. :-(
- shim-unsigned (= 15+1533136590.3beb971-5),
+ shim-unsigned (= 15+1533136590.3beb971-7),
 # sbsigntool before 0.9.2-2 had a horrid bug with checksum calculation
 # which broke our build
  sbsigntool (>= 0.9.2-2),
@@ -18,17 +15,17 @@
 
 Pa

Bug#930276: vlc: multiple vulnerabilities fixed in 3.0.7 release

[Salvatore Bonaccorso]

Source: vlc
Version: 3.0.6-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: fixed -1 3.0.7-1
Control: found -1 3.0.6-0+deb9u1

Hi

Given there are no CVEs for the repsective issues (so far) add a
single tracking bug in the BTS to get a reference, fixed already in
3.0.7-1 in unstable:

 vlc (3.0.7-1) unstable; urgency=high
 .
   * New upstream release.
 - Fix multiple integer overflows.
 - Fix multiple buffer overflows.
 - Fix use-after-free issue.
 - Fix NULL pointer dereference.
 - Fix other memory access bugs and infinite loops.
   * debian/rules: Be explicit about --enable-debug/disable-debug.

Regards,
Salvatore

Bug#930275: unblock: dcmtk/3.6.4-2.1

[Gert Wollny]

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

Please unblock package dcmtk

Upstream hasn't ported the package to use charls-2.yet, and the port
tried by me resulted in serious regressions (as reported in #923433). 

This upload removes the patch introducing the port to charls-2.0 and
the patch that forces the use of the system provided charls library,
since the old version charls-1 is no longer in the archives. As a
result dcmtk will  use the bundled version.

Many thanks, 

Gert 

unblock dcmtk/3.6.4-2.1

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

Kernel: Linux 4.19.48-gentoo (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff -Nru dcmtk-3.6.4/debian/changelog dcmtk-3.6.4/debian/changelog
--- dcmtk-3.6.4/debian/changelog	2019-01-19 10:36:10.0 +0100
+++ dcmtk-3.6.4/debian/changelog	2019-05-28 21:39:19.0 +0200
@@ -1,3 +1,10 @@
+dcmtk (3.6.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert to convenient charls copy for now. Closes: #923433
+
+ -- Mathieu Malaterre   Tue, 28 May 2019 21:39:19 +0200
+
 dcmtk (3.6.4-2) unstable; urgency=medium
 
   * d/rules,d/p/03: Fix DATADIC path, Closes: #913304
diff -Nru dcmtk-3.6.4/debian/patches/series dcmtk-3.6.4/debian/patches/series
--- dcmtk-3.6.4/debian/patches/series	2019-01-19 10:36:10.0 +0100
+++ dcmtk-3.6.4/debian/patches/series	2019-05-28 21:29:41.0 +0200
@@ -1,8 +1,8 @@
 01_dcmtk_3.6.0-1.patch
-02_system_charls.patch
+#02_system_charls.patch
 03_datadic_install.patch
 04_Fixed-OFoptional-by-introducing-OFalign.patch
 05_performance.patch
 07_dont_export_all_executables.patch
 08_remove_system_processor.patch
-09_charls-2.0.patch
+#09_charls-2.0.patch

Bug#930261: gdm3: Wrong bluetooth detected.

[Corcodel Marian]

On Sun, 9 Jun 2019 15:00:54 +0100 Simon McVittie  wrote:
> On Sun, 09 Jun 2019 at 15:23:44 +0200, Corcodel Marian wrote:
> > Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (II) 
Using input

> > driver 'libinput' for 'FC:58:FA:EC:61:91'
> ...
> > but FC:58:FA:EC:61:91 is bluetooth audio device.
>
> Are you observing any bugs or wrong behaviour caused by this, or is the
> log entry the only symptom?
>
> Does the Bluetooth audio device have control buttons? My Bluetooth
> headset has play/pause/end-call, volume-up and volume-down buttons,
> which are made available to user-space apps as equivalent to some of
> the keys of a multimedia keyboard (XF86AudioPlay, XF86AudioRaiseVolume
> and XF86AudioLowerVolume), so that they can control media players in the
> obvious way. This results in it being treated as a keyboard in addition
> to acting as an audio device, which is intentional: the buttons wouldn't
> work otherwise.
>
> Regards,
> smcv
>
>


Bluetooth audio device is MMC 220 Mac audio and not see any control buttons.

Bug#930274: RFS: junitparser/1.3.2-1 [ITP]

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "junitparser".

 * Package name: junitparser
   Version : 1.3.2-1
   Upstream Author : Joel Wang
 * URL : https://github.com/gastlygem/junitparser
 * License : Apache-2.0
   Section : python

It builds those binary packages:

  python3-junitparser - Manipulates JUnit/xUnit Result XML files

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/j/junitparser/junitparser_1.3.2-1.dsc

junitparser is a JUnit/xUnit result XML Parser. It can parse and
manipulate existing result XML files, or create new JUnit/xUnit result
XMLs from scratch.

There are already two python packages in Debian that can create
JUnit/xUnit result XML files but there does not seem to be any that can
parse them to a domain specific object model.

More information about junitparser can be obtained from
https://github.com/gastlygem/junitparser.

Regards,
Bastian Germann

Bug#930267: provide type definitions for node-ast-types

[Pirate Praveen]

Control: block -1 by 929829

It has these errors and more, so we will need babel 7 to proceed.

test/ecmascript.ts(6,29): error TS2307: Cannot find module '@babel/types'.
test/typescript.ts(4,66): error TS2307: Cannot find module '@babel/parser'.
types/esprima.d.ts(7,19): error TS2384: Overload signatures must all be
ambient or non-ambient.
types/esprima.d.ts(7,49): error TS2304: Cannot find name 'ParseOptions'.
types/esprima.d.ts(7,115): error TS2304: Cannot find name 'Program'.
../../../usr/lib/nodejs/@types/glob/index.d.ts(11,28): error TS2307:
Cannot find module 'minimatch'.



signature.asc
Description: OpenPGP digital signature

Bug#930260: Ignoring Provides line with non-equal DepCompareOp for package firefox-l10n-bn-bd

[Adam D. Barratt]

Control: reassign -1 firefox-l10n-bn-bd
Control: forcemerge 930256 -1

On Sun, 2019-06-09 at 12:36 +, shirish शिरीष wrote:
> I got the following errors while updating the apt index -
> 
> 2 packages can be upgraded. Run 'apt list --upgradable' to see them.
> W: Ignoring Provides line with non-equal DepCompareOp for package
> firefox-l10n-bn-bd
> W: Ignoring Provides line with non-equal DepCompareOp for package
> firefox-l10n-bn-in
> 

That would be #930256, which is already filed against the responsible
package.

Regards,

Adam

Bug#930273: new warnings with postgresql 11

[Daniel Baumann]

Package: pgcli
Version: 1.9.1-2

Hi,

thanks for fixing #930010. Unfortunatly I still get, now different,
warnings:

---snip---
 postgres  ~  pgcli
Version: 1.9.1
Chat: https://gitter.im/dbcli/pgcli
Mail: https://groups.google.com/forum/#!forum/pgcli
Home: http://pgcli.com
postgres> Exception in thread completion_refresh:
Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)
  File "/usr/share/pgcli/pgcli/completion_refresher.py", line 68, in
_bg_refresh
refresher(completer, executor)
  File "/usr/share/pgcli/pgcli/completion_refresher.py", line 146, in
refresh_functions
completer.extend_functions(executor.functions())
  File "/usr/share/pgcli/pgcli/pgcompleter.py", line 224, in
extend_functions
for f in func_data: ON  [F3] Multiline: OFF  [F4] Emacs-mode
Refreshing
  File "/usr/share/pgcli/pgcli/pgexecute.py", line 634, in functions
yield FunctionMetadata(*row)
TypeError: __init__() takes 11 positional arguments but 12 were given

postgres>
---snap---

Regards,
Daniel

Bug#930079: Segmentation fault (core dumped) with CDPATH=~bogus

[Osamu Aoki]

Hi,

Reported to upstream as:

 https://github.com/neovim/neovim/issues/10172

Regards,

Osamu

Bug#930272: debootstrap: needless conditional --keep-debootstrap-dir for log move

[Matthias]

Package: debootstrap
Severity: important
Tags: patch



-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages debootstrap depends on:
ii  wget  1.18-5+deb9u3

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2017.5
ii  gnupg   2.1.18-8~deb9u4

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

running debootstrap against a recent nfs Server has a known issue 'can't
rm debootstrap' and an already implemented workaround - using mv instead
of cp and rm.
But tis workaround is needless restricted to the --keep-debootstrap-dir Flag -
it won't harm to always mv . 
This way we will prevent quite some hours figuring out, what the hell
breakes the second stage ...


--- a/debootstrap2019-06-09 15:37:34.718199723 +0200
+++ b/debootstrap  2019-06-09 16:12:53.541620567 +0200
@@ -674,16 +674,13 @@
fi
 
if [ -e "$TARGET/debootstrap/debootstrap.log" ]; then
-   if [ "$KEEP_DEBOOTSTRAP_DIR" = true ]; then
-   cp "$TARGET/debootstrap/debootstrap.log" 
"$TARGET/var/log/bootstrap.log"
-   else
-   # debootstrap.log is still open as stdout/stderr and 
needs
-   # to remain so, but after unlinking it some NFS servers
-   # implement this by a temporary file in the same 
directory,
-   # which makes it impossible to rmdir that directory.
-   # Moving it instead works around the problem.
-   mv "$TARGET/debootstrap/debootstrap.log" 
"$TARGET/var/log/bootstrap.log"
-   fi
+ # no need to distinguish between kept or deleted DEBOOTSTRAP_DIR
+ # debootstrap.log is still open as stdout/stderr and needs
+ # to remain so, but after unlinking it some NFS servers
+ # implement this by a temporary file in the same directory,
+ # which makes it impossible to rmdir that directory.
+ # Moving it instead works around the problem.
+ mv "$TARGET/debootstrap/debootstrap.log" "$TARGET/var/log/bootstrap.log"
fi
sync

Bug#930271: iw: cannot scan if two cells on 2.4Ghz and 5Gz have same SSID

[Martin Monperrus]

Package: iw
Version: 5.0.1-1
Severity: normal

Dear Maintainer,

   * What are you trying to do?

I'm trying to scan networks in a place where two cells on 2.4Ghz and 5Gz have
the same SSID.

   * What was the outcome of this action?

The scan returns only one cell (not the one with double frequency, a third
one), and subsequent scan return nothing. It seems that the scan itself somehow
crashes.

   * What outcome did you expect instead?

The scan would return all cells.

   * What's a potential explanation?

Somewhere in the stack, there is a confusion regarding having the same SSID in
both the 2.4Ghz and 5Gz frequency range.

Best regards,

--Martin



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages iw depends on:
ii  libc6 2.28-10
ii  libnl-3-200   3.4.0-1
ii  libnl-genl-3-200  3.4.0-1

Versions of packages iw recommends:
ii  crda  3.18-1

iw suggests no packages.

-- no debconf information

Bug#930270: Graphical debug session does not start

[computer.enthusiastic]

Subject: mu-editor: graphical debug session does not start
Package: mu-editor
Version: 1.0.2+dfsg-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I wrote a print('Hello world') test program and I tried to start a
debugging session

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The debug button of graphical interface does not start the debug mode
of mu-editor

   * What was the outcome of this action?
The following error showed in the "running" lower pane of mu-editor:

Traceback (most recent call last):
  File "/usr/share/mu-editor/mu/mu-debug.py", line 4, in 
from mu.app import debug
ModuleNotFoundError: No module named 'mu'

-- FINISHED --
exit code: 1 status: 0 Unable to connect to the Python debugger.


   * What outcome did you expect instead?
I expected the start of interactive debugger.

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

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mu-editor depends on:
ii  fonts-inconsolata   001.010-5
ii  python3 3.7.3-1
ii  python3-appdirs 1.4.3-1
ii  python3-guizero 0.6.0+dfsg1-1
ii  python3-matplotlib  3.0.2-2
ii  python3-nudatus 0.0.4-1
ii  python3-pgzero  1.2.post4+dfsg-1
ii  python3-pil 5.4.1-2
ii  python3-pycodestyle 2.4.0-2
ii  python3-pyflakes2.0.0-1
ii  python3-pyqt5   5.11.3+dfsg-1+b3
ii  python3-pyqt5.qsci  2.10.4+dfsg-2
ii  python3-pyqt5.qtchart   5.11.3+dfsg-1
ii  python3-pyqt5.qtserialport  5.11.3+dfsg-1+b3
ii  python3-qtconsole   4.3.1-1
ii  python3-requests2.21.0-1
ii  python3-semver  2.0.1-3
ii  python3-serial  3.4-4
ii  python3-uflash  1.2.4+dfsg-1

mu-editor recommends no packages.

Versions of packages mu-editor suggests:
pn  mu-editor-doc   
pn  python3-pigpio  

-- no debconf information

Bug#925581: impossible to scroll in mate-panel

[Pascal Giard]

Dear Simon,

I hereby confirm that installing libgtk-3-0 3.24.8-1 from experimental,
along with its dependencies (corresponding versions of libgail-3-0 and
libgtk-3-0-common) fixes the issue.

Best regards,

-Pascal
--
Homepage (http://giard.info)
École de technologie supérieure (http://etsmtl.ca)


On Sun, Jun 9, 2019 at 6:45 AM Simon McVittie  wrote:

> Control: severity -1 important
> Control: tags -1 + fixed-upstream
> Control: forwarded -1
> https://gitlab.gnome.org/GNOME/gtk/merge_requests/565
>
> On Wed, 27 Mar 2019 at 05:13:40 +0100, DC-1 wrote:
> > It's impossible to select new keyboard layout, due to can't scroll in
> > mate-keyboard-preferences .
> ...
> > The bug was fixed in gtk 3.24.6 with this patch:
> >
> https://gitlab.gnome.org/GNOME/gtk/commit/1d4eac211c09624d29b9309e2b92173f7477a9b7
>
> Please could you confirm that GTK 3.24.8-1 in experimental resolves
> this bug?
>
> buster has been in hard freeze since mid March, so we would have to check
> the benefit vs. regression risk and get permission from the release team
> to be able to backport some or all of the 3.24.x changes into buster, but
> the first step would be to confirm that the fixes have the desired effect.
>
> On Sat, 08 Jun 2019 at 22:48:12 -0400, Pascal Giard wrote:
> > Looking at the severity definitions, this bug seem to deserve to be
> marked
> > as important, no?
>
> Probably yes, doing so.
>
> smcv
>

Bug#909427: please add @types/glob for node-xterm 3.x

[Pirate Praveen]

On Sun, 23 Sep 2018 20:06:05 +0530 Pirate Praveen
 wrote:
> Please add type definitions for @types/glob.

@types/estree is required by node-ast-types



signature.asc
Description: OpenPGP digital signature

Bug#930269: Install .ts files also for building node-ast-types 0.12.3

[Pirate Praveen]

package: node-esprima
version: 4.0.1+ds-1
severity: wishlist
Control: block 930267 by -1

tsc throws this error,

test/ecmascript.ts(2,31): error TS7016: Could not find a declaration 
file for module 'esprima'. '/usr/lib/nodejs/esprima/dist/esprima.js' 
implicitly has an 'any' type.
 Try `npm install @types/esprima` if it exists or add a new 
declaration (.d.ts) file containing `declare module 'esprima';`

Bug#930232: vlc: No video output in any video

[Ralf Jung]

Hi again,

> The weirdest thing is that I just tried VLC after disconnecting the HDMI 
> screen,
> and then it worked fine with the default video output mode.  And then I tried 
> it
> again on the HDMI screen and it still works.  I will have to do a reboot to 
> see
> if this sticks.  I have not installed any updates since yesterday when I
> installed VLC 3.0.7 from testing and the bug was still present.

After a reboot things still work.  I don't understand why I cannot reproduce the
issue any more -- I've had this problem several times across a week or two
before I reported it.  Maybe the update to 3.0.7 did help but for some reason
did not take "immediate effect"?  Not that that makes any sense.^^

But, either way, I cannot reproduce this any more with 3.0.7.

; Ralf

Bug#930232: vlc: No video output in any video

[Ralf Jung]

Hi,

> On 2019-06-08 23:37:18, Ralf Jung wrote:
>>> Control: tags -1 moreinfo
>>> Control: severity -1 important
>>> Control: found -1 3.0.6-1
>>>
>>> On 2019-06-08 23:20:15, Ralf Jung wrote:
 Package: vlc
 Version: 3.0.7-1
 Severity: grave
 Justification: renders package unusable

 Dear Maintainer,

 No matter which video file I try to open with VLC, VLC fails to display any
 image.  All I get is a flickering VLC icon.  I will attach a "-vv" log for 
 one
 of the many files that I tried.  The same files all work fine with mpv.
>>>
>>> What type of GPU do you use?
>>
>> (Sorry, I thought the debug log would have all that stuff.)
>> This is a dual-GPU system, with an HD Graphics P530 and an NVidia Quadro 
>> M2000M.
>>  The Intel card is the master, the NVidia card is used as an output slave 
>> (i.e.,
>> my HDMI port is actually connected to the NVidia card).
> 
> I didn't find anything in the log. Looks like vlc or the underlying
> libraries failed to detect the hardware. Is this an NVIDIA Optimus-type
> setup that requires bumblebee to work properly? The logs suggest that
> some OpenGL related functions failed.

Bumblebee is for using the NVidia card as an accelerator while rendering the
image on a screen controlled by the Intel card *without* support from either of
the two involved drivers.  I am not using that.  Also this doesn't even apply
because the NVidia card is not involved as an accelerator here, or at least
should not be.

Instead what happens is that DMA-BUF "output slave" mode is used to use the
NVidia card as an *output* together with the internal laptop screen that is
accessed directly by the Intel card.  All the rendering is done by the Intel 
card.

There are two ways in which a "master" GPU can use the "service" of another one:

* It uses the other card to render stuff, then copies the result back to its own
frame buffer for some output it controls.  This is the "bumblebee" situation.
Bumblebee makes this work with the proprietary NVidia drivers without them
having dedicated support for this situation.  When using the open-source noveau
driver, there is no need for bumblebee: the driver can natively just do this
using DMA-BUF, and I can set "DRI_PRIME=1" to activate this mode.  I don't do
that though, the nouveau drivers are so slow that it's not actually noticeably
faster than just using the Intel drivers for rendering.
* Another situation is when the laptop has some of its display connectors
connected to one GPU and some to the other GPU, but you still want a shared
desktop across all of them. Some modern hardware unfortunately does that. My
internal laptop screen is connected to the Intel card but my HDMI port is
connected to the NVidia card. I use the Intel card as the "master" so that the
NVidia card can turn off when no screen is connected. But when a screen is
connected, the image rendered by the Intel card somehow needs to get to the
frame buffer on the NVidia card. This is an "output slave" in DMA-BUF
terminology, and bumblebee doesn't help here.  The NVidia proprietary drivers
don't support this, which is why I use nouveau.

I can try to explain more about this setup if you want, though I am far from an
expert myself -- just enough to get my system to run.^^

The weirdest thing is that I just tried VLC after disconnecting the HDMI screen,
and then it worked fine with the default video output mode.  And then I tried it
again on the HDMI screen and it still works.  I will have to do a reboot to see
if this sticks.  I have not installed any updates since yesterday when I
installed VLC 3.0.7 from testing and the bug was still present.

>>> Do you have the corresponding hardware
>>> decoding driver installed?
>> How can I find that out?  I am using the Mesa drivers for both cards, as far 
>> as
>> OpenGL goes.  (The proprietary NVidia drivers don't support being an output 
>> slave.)
> 
> For the Intel card that'd be i965-va-driver (or intel-media-va-driver
> and setting LIBVA_DRIVER_NAME to iHD). You'll probably also need
> non-free firmware for that. For NVIDIA you'd need the non-free drivers
> together nvidia-vdpau-driver. As far as I am aware, the hardware
> decoding experience with nouveau is suboptimal.

i965-va-driver is installed. (Though IMO it would be a bug if VLC broke when a
non-depended packet is not installed.)
As mentioned above I cannot use the non-free NVidida drivers as they don't
support output slave mode.

Kind regards,
Ralf

Bug#930268: node-typescript should add debian's nodejs library paths to tsc

[Pirate Praveen]

package: node-typescript
version: 3.4.5-1
severity: important

Now every package that uses tsc is having to add symlink for system 
modules to local node_modules directory. See node-xterm for an example, 
https://salsa.debian.org/js-team/node-xterm/blob/59935974572560cee71ca6fcb28661a6e67ac052/debian/rules#L10


Primary use of node-typescript is building other debian packages and it 
should be adapted to that purpose (like grunt and gulp).

Bug#930267: provide type definitions for node-ast-types

[Pirate Praveen]

package: node-ast-types
version: 0.11.7-1
severity: wishlist
Control: block 930266 by -1

While trying to update node-recast to 0.18, tsc throws this error

lib/comments.ts(2,24): error TS7016: Could not find a declaration file 
for module 'ast-types'. '/usr/lib/nodejs/ast-types/main.js' implicitly 
has an 'any' type.
 Try `npm install @types/ast-types` if it exists or add a new 
declaration (.d.ts) file containing `declare module 'ast-types';`

Bug#930266: Update node-recast to 0.18.1

[Pirate Praveen]

Package: node-recast
version: 0.16.1-1
severity: wishlist
Control: block 930265 by -1

recast type definitions are required for building 
node-rollup-plugin-invariant (I have started working on the update).

Bug#930261: gdm3: Wrong bluetooth detected.

[Simon McVittie]

On Sun, 09 Jun 2019 at 15:23:44 +0200, Corcodel Marian wrote:
> Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (II) Using input
> driver 'libinput' for 'FC:58:FA:EC:61:91'
...
> but  FC:58:FA:EC:61:91 is bluetooth audio device.

Are you observing any bugs or wrong behaviour caused by this, or is the
log entry the only symptom?

Does the Bluetooth audio device have control buttons? My Bluetooth
headset has play/pause/end-call, volume-up and volume-down buttons,
which are made available to user-space apps as equivalent to some of
the keys of a multimedia keyboard (XF86AudioPlay, XF86AudioRaiseVolume
and XF86AudioLowerVolume), so that they can control media players in the
obvious way. This results in it being treated as a keyboard in addition
to acting as an audio device, which is intentional: the buttons wouldn't
work otherwise.

Regards,
smcv

Bug#930263: searx: fails to retrieve results from google

[Diego Roversi]

Source: searx
Severity: important
Tags: upstream

Dear Maintainer,

  the current version of searx in debian fail to parse results from google. The 
problem is already known to the upstream and a fix exists in upstream git:

https://github.com/asciimoo/searx/commit/cbd1ebdce8f75730bee96fcfae8739e11023f9a9

  The fix is trivial, so it should easily applied to current version in debian.

Thanks,
  Diego.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.15.11-mainline-rev1 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#930265: ITP: node-rollup-plugin-invariant -- Rollup plugin to strip invariant(condition, message) strings in production

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org
Control: block 930262 by -1

* Package name : node-rollup-plugin-invariant
 Version : 0.5.6
 Upstream Author : Ben Newman 
* URL : https://github.com/apollographql/invariant-packages
* License : Expat
 Programming Lang: JavaScript
 Description : Rollup plugin to strip invariant(condition, message) 
strings in production

Packages for working with invariant(condition, message) assertions.
.
This package includes ts-invariant and rollup-plugin-invariant 
libraries.

.
Node.js is an event-based server-side JavaScript engine.

This package is a build dependency of apollo-link, which is a 
dependency of gitlab. Since it uses rollup and typescript to generate 
code, it is not suitable for embedding.

Bug#930264: modemmanager: --filter-policy=strict no longer respects blacklist and probes Arduinos

[Matthijs Kooijman]

Package: modemmanager
Version: 1.10.0-1
Severity: normal

Hi,

since a while, ModemManager is using the new "strict" filter policy.
Rather than probing all serial ports that are not blacklisted (which
causes problems with serial devices that do not like to be probed), it
now uses more specific rules about what devices are likely to be modems
and does not probe any others.

However, this strict policy does *not* use the blacklist (configured
through udev rules), which I believe is problematic.

This problem particularly surfaces when using Arduino serial devices.
These development boards enumerate as TTY ACM USB devices, which cause
the kernel to automatically create serial ports for them. However, in
their USB descriptors, these devices advertise support for AT commands
(class=2/subclass=2/protocol=1), which triggers the MM
FILTER_RULE_TTY_ACM_INTERFACE and makes it probe these devices.

Of course, the actual problem in this case is that these devices
misadvertise themselves in their USB descriptor. I've raised this issue
in the Arduino community [1] and hopefully this will be fixed in the
future, but this will not help for existing devices (whose firmware is
not automatically or easily updated). This means that there are a lot of
Arduino devices out there which are broken by the switch to strict.

Previously, these devices were handled by the blacklist, but now they
are again probed when they should not. I suspect that there might be
other devices that have a similar fate. Also, users (such as myself)
might have collected some udev rules with blacklists over time, which
now unexpectedly stop working.

It seems that disabling the blacklist in strict mode is not an oversight
from upstream, since they also offer a "paranoid" mode which is equal to
"strict" mode but with the blacklist and greylist (manual scan only)
enabled.

A potential fix is to use the paranoid policy rather than the strict
policy, or to explicitly enable the blacklist and/or greylist on top of
the strict policy. I tried the latter, which indeed prevents MM from
probing my Arduinos. I did this:

  $ cat /etc/systemd/system/ModemManager.service.d/override.conf
  [Service]
  Environment="MM_FILTER_RULE_TTY_BLACKLIST=1"

Note that upstream discourages using the blacklists in their
documentation:

> It is not recommended to use this option in normal setups as the
> blacklists may be obsoleted in future ModemManager versions (in favor
> of using the Strict policy as default).

However, I've raised this same issue upstream [2], asking them to reconsider
this position.


Since this issue is a regression (Stretch still has a working blacklist,
but the Buster version uses the swtrict policy), it would make sense to
me to still make this change in Buster, if the freeze policy allows
this.

[1]: https://github.com/arduino/ArduinoCore-avr/pull/92
[2]: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/127

Gr.

Matthijs

(Note that I'm running Ubuntu on this machine, but reporting this to
Debian since that's where I believe this should be fixed)

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

Kernel: Linux 5.0.0-16-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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

Versions of packages modemmanager depends on:
ii  libc6  2.29-0ubuntu2
ii  libglib2.0-0   2.60.0-1
ii  libgudev-1.0-0 1:232-2
ii  libmbim-glib4  1.18.0-1
ii  libmbim-proxy  1.18.0-1
ii  libmm-glib01.10.0-1
ii  libpolkit-gobject-1-0  0.105-25
ii  libqmi-glib5   1.22.0-1.2
ii  libqmi-proxy   1.22.0-1.2
ii  libsystemd0240-6ubuntu5

Versions of packages modemmanager recommends:
ii  usb-modeswitch  2.5.2+repack0-2ubuntu1

modemmanager suggests no packages.

-- no debconf information

Bug#930262: ITP: node-apollo-link -- Flexible, lightweight transport layer for GraphQL

[Pirate Praveen]

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

* Package name : node-apollo-link
 Version : 1.2.11
 Upstream Author : Evans Hauser 
* URL : https://github.com/apollographql/apollo-link#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Flexible, lightweight transport layer for GraphQL
This library is a standard interface for modifying control flow of 
GraphQL
requests and fetching GraphQL results, designed to provide a simple 
GraphQL

client that is capable of extensions.
.
The high level use cases of `apollo-link` are highlighted below:
 * fetch queries directly without normalized cache
 * network interface for Apollo Client
 * network interface for Relay Modern
 * fetcher for GraphiQL
.
The apollo link interface is designed to make links composable and 
easy to
share, each with a single purpose. In addition to the core, this 
package

contains links for the most common fetch methods—http, local schema,
websocket—and common control flow manipulations, such as retrying 
and polling.

.
Node.js is an event-based server-side JavaScript engine.

This package is a dependency of gitlab. Since it uses rollup and 
typescript to generate code, it is not suitable for embedding.

Bug#930232: vlc: No video output in any video

[Sebastian Ramacher]

Hi

On 2019-06-08 23:37:18, Ralf Jung wrote:
> > Control: tags -1 moreinfo
> > Control: severity -1 important
> > Control: found -1 3.0.6-1
> > 
> > On 2019-06-08 23:20:15, Ralf Jung wrote:
> >> Package: vlc
> >> Version: 3.0.7-1
> >> Severity: grave
> >> Justification: renders package unusable
> >>
> >> Dear Maintainer,
> >>
> >> No matter which video file I try to open with VLC, VLC fails to display any
> >> image.  All I get is a flickering VLC icon.  I will attach a "-vv" log for 
> >> one
> >> of the many files that I tried.  The same files all work fine with mpv.
> > 
> > What type of GPU do you use?
> 
> (Sorry, I thought the debug log would have all that stuff.)
> This is a dual-GPU system, with an HD Graphics P530 and an NVidia Quadro 
> M2000M.
>  The Intel card is the master, the NVidia card is used as an output slave 
> (i.e.,
> my HDMI port is actually connected to the NVidia card).

I didn't find anything in the log. Looks like vlc or the underlying
libraries failed to detect the hardware. Is this an NVIDIA Optimus-type
setup that requires bumblebee to work properly? The logs suggest that
some OpenGL related functions failed.

> > Do you have the corresponding hardware
> > decoding driver installed?
> How can I find that out?  I am using the Mesa drivers for both cards, as far 
> as
> OpenGL goes.  (The proprietary NVidia drivers don't support being an output 
> slave.)

For the Intel card that'd be i965-va-driver (or intel-media-va-driver
and setting LIBVA_DRIVER_NAME to iHD). You'll probably also need
non-free firmware for that. For NVIDIA you'd need the non-free drivers
together nvidia-vdpau-driver. As far as I am aware, the hardware
decoding experience with nouveau is suboptimal.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#930261: gdm3: Wrong bluetooth detected.

[Corcodel Marian]

Package: gdm3
Version: 3.22.3-3+deb9u2
Severity: normal

Bellow present info report from journalctl command:

 Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (**)
FC:58:FA:EC:61:91: always reports core events
Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (II) systemd-logind:
got fd for /dev/input/event10 13:74 fd 50 paused 0
Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (II) Using input
driver 'libinput' for 'FC:58:FA:EC:61:91'
Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (**)
FC:58:FA:EC:61:91: Applying InputClass "libinput keyboard catchall"
Jun 09 14:54:49 debian /usr/lib/gdm3/gdm-x-session[1858]: (II) config/udev:
Adding input device FC:58:FA:EC:61:91 (/dev/input/event10)

but  FC:58:FA:EC:61:91 is bluetooth audio device.
I checked on var/run/udev/data on event10 is another device pci.



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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.43-1
ii  adduser   3.115
ii  dconf-cli 0.26.0-2+b1
ii  dconf-gsettings-backend   0.26.0-2+b1
ii  debconf [debconf-2.0] 1.5.61
ii  gir1.2-gdm-1.03.22.3-3+deb9u2
ii  gnome-session [x-session-manager] 3.22.3-1
ii  gnome-session-bin 3.22.3-1
ii  gnome-settings-daemon 3.22.2-2+deb9u2
ii  gnome-shell   3.22.3-3
ii  gnome-terminal [x-terminal-emulator]  3.22.2-1
ii  gsettings-desktop-schemas 3.22.0-1
ii  libaccountsservice0   0.6.43-1
ii  libaudit1 1:2.6.7-2
ii  libc6 2.24-11+deb9u4
ii  libcanberra-gtk3-00.30-3
ii  libcanberra0  0.30-3
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libgdm1   3.22.3-3+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libglib2.0-bin2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libkeyutils1  1.5.9-9
ii  libpam-modules1.1.8-3.6
ii  libpam-runtime1.1.8-3.6
ii  libpam-systemd232-25+deb9u11
ii  libpam0g  1.1.8-3.6
ii  librsvg2-common   2.40.16-1+b1
ii  libselinux1   2.6-3+b3
ii  libsystemd0   232-25+deb9u11
ii  libwrap0  7.6.q-26
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxau6   1:1.0.8-1
ii  libxcb1   1.12-1
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  9.20161125
ii  mutter [x-window-manager] 3.22.3-2
ii  policykit-1   0.105-18+deb9u1
ii  ucf   3.0036
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+7+b1
ii  xterm [x-terminal-emulator]   327-2

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-6+deb9u1
ii  desktop-base9.0.2+deb9u1
ii  x11-xkb-utils   7.7+3+b1
ii  xserver-xephyr  2:1.19.2-1+deb9u5
ii  xserver-xorg1:7.7+19
ii  zenity  3.22.0-1+b1

Versions of packages gdm3 suggests:
ii  gnome-orca3.22.2-3
ii  libpam-gnome-keyring  3.20.0-3

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#929983: ipxe-qemu: virtio booting no longer works after upgrade to buster

[Shengjing Zhu]

On Wed, Jun 05, 2019 at 01:24:06AM +0200, Thorsten Glaser wrote:
[...]
> I’ll attach the virsh dumpxml output below; I had reinstalled Debian
> using an e1000 NIC and netboot in the meantime and reverted to virtio
> afterwards, but I’m pretty sure this is reproducible even on other
> virtualisation hosts, I will try that tomorrow.
> 

I just test with plain qemu, and it looks good.

  qemu-system-x86_64 -m 2G -cpu host -accel kvm -device 
virtio-net-pci,netdev=net0 -netdev user,id=net0 -nographic

---BEGIN---
SeaBIOS (version 1.12.0-1)


iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+7FF90020+7FED0020 C980



Booting from Hard Disk...
Boot failed: could not read the boot disk

Booting from Floppy...
Boot failed: could not read the boot disk

Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0003)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initialising devices...ok



iPXE 1.0.0+git-20190125.36a4c85-1 -- Open Source Network Boot Firmware -- http:/
/ipxe.org
Features: DNS HTTP iSCSI NFS TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT

net0: 52:54:00:12:34:56 using virtio-net on :00:03.0 (open)
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
Configuring (net0 52:54:00:12:34:56).. ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
net0: fec0::5054:ff:fe12:3456/64 gw fe80::2
net0: fe80::5054:ff:fe12:3456/64
Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
No more network devices

iPXE>
---END---

Bug#925863: xcalib: ftbfs with GCC-9

[Reiner Herrmann]

Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS by moving all
linked libraries to the end of the command line.

Regards,
  Reiner
diff -u xcalib-0.8.dfsg1/debian/rules xcalib-0.8.dfsg1/debian/rules
--- xcalib-0.8.dfsg1/debian/rules
+++ xcalib-0.8.dfsg1/debian/rules
@@ -26,7 +26,7 @@
 	dh_testdir
 	
 	$(CC) $(CFLAGS) -c xcalib.c -DXCALIB_VERSION=\"$(XCALIB_VERSION)\"
-	$(CC) $(CFLAGS) -lm -o xcalib xcalib.o -lX11 -lXxf86vm -lXext
+	$(CC) $(CFLAGS) -o xcalib xcalib.o -lm -lX11 -lXxf86vm -lXext
 	
 	touch $@
 


signature.asc
Description: PGP signature

Bug#906115: gnucash: Crash when press key on new entry in account

[Markus Grunwald]

Hello

> does unsetting GTK_IM_MODULE help?
Yes, it helps :)

Can be seen on the BT, as well

#1  0x149af54e in gdk_x11_window_get_xid () at
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#2  0x155540a6cd9e in  () at
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
#3  0x14c484b3 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x105b31c9 in gnucash_sheet_key_press_event
(widget=0x57008410, event=0x57c85940) at
./gnucash/register/register-gnome/gnucash-sheet.c:1904


-- 
Markus Grunwald
https://www.the-grue.de/~markus/markus_grunwald.gpg

Bug#906115: Backtrace included

[Markus Grunwald]

Hello,

I have the same bug and followed the instructions from
https://wiki.debian.org/HowToGetABacktrace

Here's the backtrace:

Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault.
0x149792d2 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#0  0x149792d2 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1  0x149af54e in gdk_x11_window_get_xid () at
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#2  0x155540a6cd9e in  () at
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
#3  0x14c484b3 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x105b31c9 in gnucash_sheet_key_press_event
(widget=0x57008410, event=0x57c85940) at
./gnucash/register/register-gnome/gnucash-sheet.c:1904
#5  0x14df7274 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x14553dd0 in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x1456fd74 in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x1457097f in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x14da5324 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x14dc591b in gtk_window_propagate_key_event () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x14dc942b in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x14df7274 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x14553ec6 in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x1456fd74 in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x1457097f in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x14da5324 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#17 0x14c65a3f in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#18 0x14c67a83 in gtk_main_do_event () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#19 0x14969465 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#20 0x1499a112 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#21 0x1516af2e in g_main_context_dispatch () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x1516b1c8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x1516b4c2 in g_main_loop_run () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x14c66b15 in gtk_main () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#25 0x104cc40d in gnc_ui_start_event_loop () at
./gnucash/gnome-utils/gnc-gnome-utils.c:651
#26 0x8132 in inner_main (closure=,
argc=, argv=) at ./gnucash/gnucash-bin.c:684
#27 0x1531350d in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#28 0x152f5dfa in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#29 0x1537453f in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#30 0x15379d8f in scm_call_n () at
/usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#31 0x15368784 in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#32 0x152f63e0 in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#33 0x152f6475 in scm_c_with_continuation_barrier () at
/usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#34 0x15367396 in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#35 0x15259ef5 in GC_call_with_stack_base () at
/usr/lib/x86_64-linux-gnu/libgc.so.1
#36 0x15367728 in scm_with_guile () at
/usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#37 0x153136a2 in scm_boot_guile () at
/usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
#38 0x7a30 in main (argc=, argv=) at ./gnucash/gnucash-bin.c:831
#0  0x149792d2 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1  0x149af54e in gdk_x11_window_get_xid () at
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#2  0x155540a6cd9e in  () at
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
#3  0x14c484b3 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x105b31c9 in gnucash_sheet_key_press_event
(widget=0x57008410, event=0x57c85940) at
./gnucash/register/register-gnome/gnucash-sheet.c:1904
sheet = 0x57008410
editable = 
start_sel = 0
end_sel = 31
__func__ = "gnucash_sheet_key_press_event"
#5  0x14df7274 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x14553dd0 in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x1456fd74 in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x1457097f in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x14da5324 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x14dc591b in gtk_window_propagate_key_event () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x14dc942b in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x14df7274 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x14553ec6 in  () at
/usr/lib/x86_64-linux-gnu/libgobjec

Bug#930260: Ignoring Provides line with non-equal DepCompareOp for package firefox-l10n-bn-bd

[shirish शिरीष]

Package: apt
Version: 1.8.2
Severity: normal

Dear Maintainer,

I got the following errors while updating the apt index -

2 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: Ignoring Provides line with non-equal DepCompareOp for package
firefox-l10n-bn-bd
W: Ignoring Provides line with non-equal DepCompareOp for package
firefox-l10n-bn-in

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions
|| exit 0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service
&& /us

Bug#930259: RM: cantor-backend-scilab [armel mips mipsel] -- RoQA; NBS; scilab is no longer available on all architectures

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

cantor-backend-scilab is no longer built for architectures without
scilab.


Andreas

Bug#930256: Ignoring Provides line with non-equal DepCompareOp for package firefox-l10n-bn-bd

[Vincent Lefevre]

On 2019-06-09 19:32:25 +0800, 積丹尼 Dan Jacobson wrote:
> # apt-get update
> W: Ignoring Provides line with non-equal DepCompareOp for package 
> firefox-l10n-bn-bd
> W: Ignoring Provides line with non-equal DepCompareOp for package 
> firefox-l10n-bn-in

Same problem (and ditto with aptitude, which confuses its curses
interface).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#930258: RM: cantor-backend-python [all] -- RoQA; NBS; obsolete arch:all package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Let's remove some cruft. src:cantor is now at 4:18.12.0-2

anbe@coccia:~$ dak rm -Rn -b cantor-backend-python
Will remove the following packages from unstable:

cantor-backend-python | 4:17.08.3-1 | all

Maintainer: Debian/Kubuntu Qt/KDE Maintainers 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas

Bug#908678: Update on the security-tracker git discussion

[Salvatore Bonaccorso]

On Sat, Jun 08, 2019 at 06:29:24PM +0200, Salvatore Bonaccorso wrote:
> Notes on possible CVE/list splits
> -
[...]

After a face-to-face conversation with Daniel, Daniel suggested to
create a priority list out of that, we will followup with that to that
(ideally as gitlab task-list) here with a link once we have made our
minds on it.

Regards,
Salvatore

Bug#927775: monit: CVE-2019-11454 CVE-2019-11455

[Salvatore Bonaccorso]

Hi Sergey,

On Sun, Jun 09, 2019 at 01:14:57PM +0300, Sergey B Kirpichev wrote:
> On Sun, Jun 09, 2019 at 12:08:21PM +0200, Salvatore Bonaccorso wrote:
> > After some time passed, on 2019-06-03, another Debian security team
> > member (Moritz Muehlenhoff ) raised the severity to a
> > release critical value.
> 
> For no reasons.

I gave a reason though now in my previous mail, right in the sentence
following after that.

> > Could you please work out with the Release team via an unblock request
> > if they would wave through the version or a sheduled a targeted fix
> > via testing-proposed-updates?
> 
> Yes, I'm planing backports for these fixes.  I don't know why this
> require increase in the bug severity.

Perfect, thanks! The increase in severity was done as per above, to
make sure it is marked release critical and not missed for the
release of buster.

I still do not get it why a new upstream version was uploaded to
unstable at this point in the freeze, though.

Regards,
Salvatore

Bug#930257: luarocks: Request for update

[Faheem Mitha]

Package: luarocks
Version: 2.4.2+dfsg-1
Severity: wishlist

Dear Maintainer,

The current packaged version is 2.4.2, but the current release is
3.1.3.

Could I get an update on the status of this package?

I could assist with an update on the packaging, if anyone out there is
interested in sponsoring it.

Regards, Faheem Mitha

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages luarocks depends on:
ii  liblua5.1-0-dev [liblua5.1-dev]  5.1.5-8.1+b2
ii  liblua5.2-dev5.2.4-1.1+b2
ii  liblua5.3-dev5.3.3-1.1
ii  lua-any  25
ii  lua5.1   5.1.5-8.1+b2
ii  lua5.2   5.2.4-1.1+b2
ii  lua5.3   5.3.3-1.1
ii  unzip6.0-23
ii  wget 1.20.1-1.1
ii  zip  3.0-11+b1

Versions of packages luarocks recommends:
ii  lua-sec  0.7-1

luarocks suggests no packages.

-- no debconf information

Bug#930256: Ignoring Provides line with non-equal DepCompareOp for package firefox-l10n-bn-bd

[積丹尼 Dan Jacobson]

Package: firefox-l10n-bn-bd

# apt-get update
W: Ignoring Provides line with non-equal DepCompareOp for package 
firefox-l10n-bn-bd
W: Ignoring Provides line with non-equal DepCompareOp for package 
firefox-l10n-bn-in