Bug#940553: Bug#941807: r-cran-recipes: autopktest depends on r-cran-rsample which doesn't exist

2019-10-05 Thread Andreas Tille
Hi Paul,

I took the freedomto upload a few r-cran-* packages with new
test-depends which are only in new.  In this case it is:

  https://ftp-master.debian.org/new/r-cran-rsample_0.0.5-1.html

Its probably not the best idea for you and those who are watching test
results closely.  However, I would have either needed to patch the tests
to exclude the new dependency or deactivate it just to activate it later
again.  So I took the freedom to let those packages temporarily fail the
tests until the new package is accepted (which to my experience went
relatively fast with r-cran-* packages).

I hope you do not consider this procedure as a bad idea.  I always
tested the test suite with the package in new and can confirm that
this bug will close automatically.

Kind regards and thanks a lot for your effort about autopkgtest

 Andreas.

On Sat, Oct 05, 2019 at 10:27:17PM +0200, Paul Gevers wrote:
> Source: r-cran-recipes
> Version: 0.1.7-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainers,
> 
> With a recent upload of r-cran-recipes the autopkgtest of r-cran-recipes
> fails in testing when that autopkgtest is run with the binary packages
> of r-cran-recipes from unstable. It passes when run with only packages
> from testing. In tabular form:
>passfail
> r-cran-recipes from testing0.1.7-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. As you can
> see, the autopkgtest of r-cran-recipes depends on r-cran-rsample, which
> doesn't exist in Debian.
> 
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=r-cran-recipes
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-recipes/3080108/log.gz
> 
> E: Unable to locate package r-cran-rsample
> 




> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team


-- 
http://fam-tille.de



Bug#941656: lintian: changelog-file-missing-explicit-entry false positive for 2 consecutive NMUs (-X.1, -X.2)

2019-10-05 Thread Andreas Metzler
On 2019-10-03 Raphaël Hertzog  wrote:
> Package: lintian
> Version: 2.24.0
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali

> I just uploaded ddd_3.3.12-5.2.dsc and I get this warning:
> W: ddd source: changelog-file-missing-explicit-entry 1:3.3.12-5.1 -> 
> 1:3.3.12-5 (missing) -> 1:3.3.12-5.2

> Yet the changelog file has all the entries and in the expected order:
> $ grep ^ddd debian/changelog |head -n 3
> ddd (1:3.3.12-5.2) unstable; urgency=medium
> ddd (1:3.3.12-5.1) unstable; urgency=medium
> ddd (1:3.3.12-5) unstable; urgency=low

Hello,

This also applies if one of the NMUs uploads a new upstream version.

W: xplanet source: changelog-file-missing-explicit-entry 1.3.0-5.1 -> 1.3.1-0 
(missing) -> 1.3.1-0.1

(sid)ametzler@argenau:/tmp/XPLANET/xplanet-1.3.1$ grep ^xplanet 
debian/changelog | head -n3
xplanet (1.3.1-0.1) UNRELEASED; urgency=medium
xplanet (1.3.0-5.1) unstable; urgency=medium
xplanet (1.3.0-5) unstable; urgency=low

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#941828: git: fatal: could not read Password for : Permission denied

2019-10-05 Thread Heinrich Schuchardt

The problem seems to stem from missing accessibility of /dev/tty:

$ ls /dev/tty -la
crw--w 1 root tty 5, 0 Oct  6 06:19 /dev/tty



Bug#941773: reportbug: Reportbug should keep a list of your reported bugs

2019-10-05 Thread Sandro Tosi
On Sat, Oct 5, 2019 at 2:03 AM Svein Engelsgjerd  wrote:
>  I sometimes forget what packages I have reported bugs to... I would like 
> to have a list of "my reported bygs" in reportbug.

i dont think this is reportbug's job, maybe querybts?

>  I can filter on my email, but this means using two systems instead of one

you can always access the list of your reported bugs via
https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=EMAILADDRESS


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



Bug#937815: [Python-modules-team] Processed: Bug#937815 marked as pending in python-html2text

2019-10-05 Thread Sandro Tosi
> Hi Sandro (2019.10.04_18:58:17_+0200)
> > there are still reverse dependencies:
> > http://sandrotosi.me/debian/py2removal/python-html2text_1.svg
>
> It's in a branch, not master.
> https://salsa.debian.org/python-team/modules/python-html2text/compare/master...python3
>
> Upstream released a new version, it's py3, only. So, stuffed the new
> version in a "python3" branch to remind myself that it's not uploadable.
>
> So no, not *actually* pending.
> Let's revert the bot's work.

oh great, thanks!

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



Bug#941831: gir1.2-gnomedesktop-3.0: 3.34.0-2 causes gdm3 black screen

2019-10-05 Thread Ross Vandegrift
Package: gir1.2-gnomedesktop-3.0
Version: 3.34.0-2
Severity: normal

Dear Maintainer,

After installing gir1.2-gnomedesktop-3.0 3.34.0-2, gdm3 only displays a black
screen.  Downgrading to 3.30.2.1-2 and restarting gdm3 fixes the issue.

Ross

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

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

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


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

Kernel: Linux 5.2.0-3-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gir1.2-gnomedesktop-3.0 depends on:
ii  gir1.2-gdesktopenums-3.0  3.28.1-1
ii  gir1.2-glib-2.0   1.62.0-2
ii  gir1.2-gtk-3.03.24.11-1
ii  libgnome-desktop-3-18 3.34.0-2

gir1.2-gnomedesktop-3.0 recommends no packages.

gir1.2-gnomedesktop-3.0 suggests no packages.

-- no debconf information



Bug#941830: pypy3: "import numpy" complains with: "Original error was: No module named 'numpy.core._multiarray_umath'"

2019-10-05 Thread Kingsley G. Morse Jr.
Package: pypy3
Version: 7.1.1+dfsg-1
Severity: normal

Thank you very much for maintaining pypy3.

It executes code I wrote 2X as fast as python3.

The main reason for this bug report is I happened
to notice pypy3 failed to import a math module
named "numpy".

Here's how I elicited the error:

1.) $ pypy3

2.) import numpy

I expected to see the ">>> " prompt next.

Unfortunately, instead I saw

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 40, in 

from . import multiarray
  File "/usr/lib/python3/dist-packages/numpy/core/multiarray.py", line 13, 
in 
from . import overrides
  File "/usr/lib/python3/dist-packages/numpy/core/overrides.py", line 6, in 

from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 142, in 

from . import core
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 71, in 

raise ImportError(msg)
ImportError: 

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the multiarray numpy extension module failed.  Most
likely you are trying to import a failed build of numpy.
Here is how to proceed:
- If you're working with a numpy git repository, try `git clean -xdf`
  (removes all files not under version control) and rebuild numpy.
- If you are simply trying to use the numpy version that you have installed:
  your installation is broken - please reinstall numpy.
- If you have already reinstalled and that did not fix the problem, then:
  1. Check that you are using the Python you expect (you're using 
/usr/bin/pypy3),
 and that you have no directories in your PATH or PYTHONPATH that can
 interfere with the Python and numpy versions you're trying to use.
  2. If (1) looks fine, you can open a new issue at
 https://github.com/numpy/numpy/issues.  Please include details on:
 - how you installed Python
 - how you installed numpy
 - your operating system
 - whether or not you have multiple versions of Python installed
 - if you built from source, your compiler versions and ideally a build 
log

 Note: this error has many possible causes, so please don't comment on
 an existing issue about this - open a new one instead.

Original error was: No module named 'numpy.core._multiarray_umath'

I read the above advice, and

1.) tested the latest versions of pypy3 and
python3-numpy in unstable, and 

2.) didn't notice any directory in my $PATH or
$PYTHONPATH environemnt variables that
looked suspicious.

No luck!

My understanding is pypy has only recently
supported numpy.

At least for me, python3 can import it.

So,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

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

Versions of packages pypy3 depends on:
ii  dpkg  1.19.7
ii  libbz2-1.01.0.8-2
ii  libc6 2.29-1
ii  libexpat1 2.2.7-2
ii  libffi6   3.2.1-9
ii  libgcc1   1:9.2.1-7
ii  libgdbm6  1.18.1-5
ii  liblzma5  5.2.4-1+b1
ii  libncurses6   6.1+20190803-1
ii  libncursesw6  6.1+20190803-1
ii  libsqlite3-0  3.29.0-2
ii  libssl1.1 1.1.1d-1
ii  libtinfo6 6.1+20190803-1
ii  pypy3-lib 7.1.1+dfsg-1
ii  zlib1g1:1.2.11.dfsg-1+b1

pypy3 recommends no packages.

Versions of packages pypy3 suggests:
pn  pypy3-doc  
pn  pypy3-tk   

-- no debconf information



Bug#941829: inform-mode: Can't type right bracket; complains about last-command-char

2019-10-05 Thread John Goerzen
Package: inform-mode
Version: 1.5.8-4
Severity: grave
Justification: renders package unusable

Whenever I attempt to type a right bracket -- a rather important
operation in inform, as it ends a function -- I get:

Symbol's value as variable is void: last-command-char

According to
https://stackoverflow.com/questions/18336117/void-variable-last-command-char-error-when-i-use-semantic-to-locate-symbol,
in Emacs 24.3, it was removed and renamed to last-command-event.

I suspect this is also addressed in the newer releases of inform-mode,
as mentioned in #673376.

- John

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

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

Versions of packages inform-mode depends on:
ii  emacsen-common  3.0.4

inform-mode recommends no packages.

inform-mode suggests no packages.

-- no debconf information



Bug#941828: git: fatal: could not read Password for : Permission denied

2019-10-05 Thread Heinrich Schuchardt

Package: git
Version: 1:2.23.0-1
Severity: normal

Dear Maintainer,

since the last KDE plasma update git push fails with an error

git: fatal: could not read Password for : Permission denied

When working locally I can use

export GIT_ASKPASS=`which ksshaskpass`

as a workaround.

But that does not help if I am working via SSH.

How can I simply enter the password on the console?

Best regards

Heinrich Schuchardt

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

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

Versions of packages git depends on:
ii  git-man  1:2.23.0-1
ii  libc62.29-2
ii  libcurl3-gnutls  7.66.0-1
ii  liberror-perl0.17028-1
ii  libexpat12.2.7-2
ii  libpcre2-8-0 10.32-5+b1
ii  perl 5.28.1-6
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1
ii  openssh-client [ssh-client]  1:8.0p1-6
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-9
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
ii  git-email 1:2.23.0-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information



Bug#936219: blockdiag: Python2 removal in sid/bullseye

2019-10-05 Thread Sandro Tosi
On Thu, 12 Sep 2019 16:12:59 +0200 Matthias Klose  wrote:
> Control: severity -1 serious
>
> python-zc.buildout is now gone, python3-zc.buildout is now in the archive.

python-blockdiag has 15 reverse dependencies:
http://sandrotosi.me/debian/py2removal/python-blockdiag_1.svg

you should revert the removal of python-zc.buildout until all its
reverse dependencies have been ported to python3



Bug#938281: python-xtermcolor: diff for NMU version 1.2.1-2.1

2019-10-05 Thread Sandro Tosi
Control: tags 938281 + patch
Control: tags 938281 + pending


Dear maintainer,

I've prepared an NMU for python-xtermcolor (versioned as 1.2.1-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-xtermcolor-1.2.1/debian/changelog python-xtermcolor-1.2.1/debian/changelog
--- python-xtermcolor-1.2.1/debian/changelog	2015-10-25 11:43:19.0 -0400
+++ python-xtermcolor-1.2.1/debian/changelog	2019-10-05 22:51:17.0 -0400
@@ -1,3 +1,10 @@
+python-xtermcolor (1.2.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938281
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 22:51:17 -0400
+
 python-xtermcolor (1.2.1-2) unstable; urgency=low
 
   * Don't hard-code the Python versions (Closes: #802864)
diff -Nru python-xtermcolor-1.2.1/debian/control python-xtermcolor-1.2.1/debian/control
--- python-xtermcolor-1.2.1/debian/control	2015-10-25 11:42:38.0 -0400
+++ python-xtermcolor-1.2.1/debian/control	2019-10-05 22:50:59.0 -0400
@@ -2,22 +2,13 @@
 Section: python
 Priority: optional
 Maintainer: Salvo 'LtWorf' Tomaselli 
-Build-Depends: debhelper (>= 9), python-all,
+Build-Depends: debhelper (>= 9),
  python3-all, dh-python
 Standards-Version: 3.9.6
 Homepage: https://github.com/broadinstitute/xtermcolor
 X-Python3-Version: >= 3.4
 X-Python-Version: >= 2.7
 
-Package: python-xtermcolor
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Python module to print coloured text on terminals
- This module provides a simple API to print in color on terminals, it can
- accept RGB and ANSI colors, and can use 256 colors.
- .
- This package provides Python 2.x version of python-xtermcolor
-
 Package: python3-xtermcolor
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-xtermcolor-1.2.1/debian/python-xtermcolor.docs python-xtermcolor-1.2.1/debian/python-xtermcolor.docs
--- python-xtermcolor-1.2.1/debian/python-xtermcolor.docs	2015-09-16 03:17:45.0 -0400
+++ python-xtermcolor-1.2.1/debian/python-xtermcolor.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.md
diff -Nru python-xtermcolor-1.2.1/debian/python-xtermcolor.examples python-xtermcolor-1.2.1/debian/python-xtermcolor.examples
--- python-xtermcolor-1.2.1/debian/python-xtermcolor.examples	2015-09-16 03:17:45.0 -0400
+++ python-xtermcolor-1.2.1/debian/python-xtermcolor.examples	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-debian/example.py
diff -Nru python-xtermcolor-1.2.1/debian/rules python-xtermcolor-1.2.1/debian/rules
--- python-xtermcolor-1.2.1/debian/rules	2015-09-16 12:40:18.0 -0400
+++ python-xtermcolor-1.2.1/debian/rules	2019-10-05 22:51:15.0 -0400
@@ -2,4 +2,4 @@
 
 export PYBUILD_NAME=xtermcolor
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#941827: module loading fails with error: "Lockdown: modprobe: Loading of unsigned module is restricted; see https://wiki.debian.org/SecureBoot"

2019-10-05 Thread Niv Sardi
Package: src:linux
Version: 5.3.2-1~exp1
Severity: important

I can't figure out how to sign my kernel modules once I installed my MOK,
the doc in https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key didn't 
really help me out.

└[cochabamba] mokutil --test-key mok/MOK.cer
 22:41:13
mok/MOK.cer is already enrolled
└[cochabamba] sudo keyctl show -x %:.builtin_trusted_keys   
 22:41:37
Keyring
0x2d16579e ---lswrv  0 0  keyring: .builtin_trusted_keys
0x29b4e884 ---lswrv  0 0   \_ asymmetric: Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
0x3681dcff ---lswrv  0 0   \_ asymmetric: Debian Secure Boot Signer: 
00a7468def
└[cochabamba] sudo keyctl show -x %:.platform   
 22:41:42
Keyring
0x1cbb137c ---lswrv  0 0  keyring: .platform
0x3d97fc8d ---lswrv  0 0   \_ asymmetric: Microsoft Windows Production 
PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
0x04167078 ---lswrv  0 0   \_ asymmetric: Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
0x3646f72f ---lswrv  0 0   \_ asymmetric: Canonical Ltd. Master 
Certificate Authority: ad91990bc22ab1f517048c23b6655a268e345a63
0x02bb95ba ---lswrv  0 0   \_ asymmetric: Niv Sardi: 
8b6895ea20ac18cf58b558b8367eabd6400d021d
0x16f8c206 ---lswrv  0 0   \_ asymmetric: : 
6e4c5e40f58b7aad499ef717e69bc28d
0x1120e45f ---lswrv  0 0   \_ asymmetric: Microsoft Corporation UEFI CA 
2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
└[cochabamba] sudo /usr/src/linux-headers-(uname -r)/scripts/sign-file sha256 
~/mok/MOK.key ~/mok/MOK.cer /lib/modules/(uname -r)/updates/dkms/wireguard.ko 
wireguard.ko
└[cochabamba] hexdump -C wireguard.ko |tail -24 
 22:44:22
00053be0  4e 69 76 20 53 61 72 64  69 02 14 4e 56 b2 8b 51  |Niv Sardi..NV..Q|
00053bf0  00 33 4c 28 86 cd 99 08  b6 c9 8a 6a bb f8 58 30  |.3L(...j..X0|
00053c00  0b 06 09 60 86 48 01 65  03 04 02 01 30 0d 06 09  |...`.H.e0...|
00053c10  2a 86 48 86 f7 0d 01 01  01 05 00 04 82 01 00 3e  |*.H>|
00053c20  5e 55 0d bc 7a 4f c5 0f  f8 05 bc f3 68 a3 88 3c  |^U..zO..h..<|
00053c30  8e 52 d7 15 b9 2e 0a 26  1d a0 0f 17 48 01 bd f5  |.R.&H...|
00053c40  f1 b8 f8 f0 01 c3 8f 07  c5 33 65 08 14 f5 a6 58  |.3eX|
00053c50  44 d5 78 c2 be bf f6 14  93 3b 13 56 76 0e 46 29  |D.x..;.Vv.F)|
00053c60  de 2c b2 21 e2 c0 8b aa  04 a0 86 42 5f fb 81 89  |.,.!...B_...|
00053c70  da ca d7 23 e4 ea 1a 7c  8f 9f b6 0b c0 58 ad 6f  |...#...|.X.o|
00053c80  4d ed f2 ed 54 5c ce f8  ff 99 f9 40 d3 6d 39 7a  |M...T\.@.m9z|
00053c90  db 73 e5 47 3f da 4c 03  d0 25 f9 03 19 ad 2e cd  |.s.G?.L..%..|
00053ca0  93 e5 c0 6b eb be 2e 38  2a 0e f4 9b 18 99 27 9d  |...k...8*.'.|
00053cb0  ca 92 d1 f9 5f b2 2d 50  19 1a 8a 4b 88 3d 39 f5  |_.-P...K.=9.|
00053cc0  b4 59 9f 3e 70 5f 43 09  01 91 20 bc 95 c9 88 fc  |.Y.>p_C... .|
00053cd0  96 32 f0 06 85 9c fb 26  3a f4 05 38 e0 b8 d0 9c  |.2.&:..8|
00053ce0  94 a9 f9 c2 40 49 a9 95  43 db e1 cc 51 36 30 92  |@I..C...Q60.|
00053cf0  1e 6e ee 31 ac f4 e1 83  4a 19 91 72 26 44 f4 30  |.n.1J..r|
00053d00  6c d5 79 c4 f8 22 70 8c  9a 56 e9 ab f8 70 a9 65  |l.y.."p..V...p.e|
00053d10  cf 2e a1 96 3a ce 3d 88  30 23 2f 9c f6 be 87 00  |:.=.0#/.|
00053d20  00 02 00 00 00 00 00 00  00 01 8f 7e 4d 6f 64 75  |...~Modu|
00053d30  6c 65 20 73 69 67 6e 61  74 75 72 65 20 61 70 70  |le signature app|
00053d40  65 6e 64 65 64 7e 0a  |ended~.|
00053d47
└[cochabamba] sudo insmod ./wireguard.ko
 22:44:25
insmod: ERROR: could not insert module ./wireguard.ko: Operation not permitted

this just get dmesg to output:
[   20.488940] Lockdown: modprobe: Loading of unsigned module is restricted; 
see https://wiki.debian.org/SecureBoot

-- Package-specific info:
** Version:
Linux version 5.3.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
9.2.1 20190909 (Debian 9.2.1-8)) #1 SMP Debian 5.3.2-1~exp1 (2019-10-02)

** Command line:
BOOT_IMAGE=/vmlinuz-5.3.0-trunk-amd64 root=/dev/mapper/cochabamba--vg-root ro 
pcie_aspm=force quiet splash

** Tainted: U (64)
 * Userspace-defined naughtiness.

** Kernel log:
[   12.497793] Bluetooth: RFCOMM ver 1.11
[   12.511270] uvcvideo 1-7:1.0: Entity type for entity Extension 4 was not 
initialized!
[   12.511272] uvcvideo 1-7:1.0: Entity type for entity Extension 3 was not 
initialized!
[   12.511274] uvcvideo 1-7:1.0: Entity type for entity Processing 2 was not 
initialized!
[   12.511276] uvcvideo 1-7:1.0: Entity type for entity Camera 1 was not 
initialized!
[   12.511363] input: HD Camera: HD Camera as 
/devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/input/input25
[   12.511447] usbcore: registered new interface driver uvcvideo
[   12.511448] USB Video Class driver 

Bug#938240: python-unpaddedbase64: diff for NMU version 1.1.0-4.1

2019-10-05 Thread Sandro Tosi
Control: tags 938240 + patch
Control: tags 938240 + pending


Dear maintainer,

I've prepared an NMU for python-unpaddedbase64 (versioned as 1.1.0-4.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-unpaddedbase64-1.1.0/debian/changelog python-unpaddedbase64-1.1.0/debian/changelog
--- python-unpaddedbase64-1.1.0/debian/changelog	2019-01-29 10:14:57.0 -0500
+++ python-unpaddedbase64-1.1.0/debian/changelog	2019-10-05 22:48:01.0 -0400
@@ -1,3 +1,10 @@
+python-unpaddedbase64 (1.1.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938240
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 22:48:01 -0400
+
 python-unpaddedbase64 (1.1.0-4) unstable; urgency=medium
 
   * Enable autopkgtest CI.
diff -Nru python-unpaddedbase64-1.1.0/debian/control python-unpaddedbase64-1.1.0/debian/control
--- python-unpaddedbase64-1.1.0/debian/control	2019-01-29 10:14:57.0 -0500
+++ python-unpaddedbase64-1.1.0/debian/control	2019-10-05 22:47:43.0 -0400
@@ -5,8 +5,6 @@
 Build-Depends:
  debhelper-compat (= 12),
  dh-python,
- python-all (>= 2.6.6-3),
- python-setuptools (>= 0.6.24),
  python3-all,
  python3-setuptools (>= 0.6.24)
 Standards-Version: 4.3.0
@@ -15,21 +13,6 @@
 Vcs-Browser: https://salsa.debian.org/matrix-team/python-unpaddedbase64
 Vcs-Git: https://salsa.debian.org/matrix-team/python-unpaddedbase64.git
 
-Package: python-unpaddedbase64
-Architecture: all
-Depends:
- ${misc:Depends},
- ${python:Depends}
-Provides: ${python:Provides}
-Description: unpadded Base64 implementation in Python
- A module to encode and decode Base64 without "=" padding.
- .
- RFC 4648 specifies that Base64 should be padded to a multiple of 4 bytes
- using "=" characters. However this conveys no benefit so many protocols choose
- to use Base64 without the "=" padding.
- .
- This package is for Python 2.
-
 Package: python3-unpaddedbase64
 Architecture: all
 Depends:
diff -Nru python-unpaddedbase64-1.1.0/debian/python-unpaddedbase64.docs python-unpaddedbase64-1.1.0/debian/python-unpaddedbase64.docs
--- python-unpaddedbase64-1.1.0/debian/python-unpaddedbase64.docs	2019-01-29 10:14:57.0 -0500
+++ python-unpaddedbase64-1.1.0/debian/python-unpaddedbase64.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.rst
diff -Nru python-unpaddedbase64-1.1.0/debian/rules python-unpaddedbase64-1.1.0/debian/rules
--- python-unpaddedbase64-1.1.0/debian/rules	2019-01-29 10:14:57.0 -0500
+++ python-unpaddedbase64-1.1.0/debian/rules	2019-10-05 22:47:58.0 -0400
@@ -3,4 +3,4 @@
 export PYBUILD_NAME=unpaddedbase64
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#941749: plasma-workspace: System tray not shown and no panel context menu

2019-10-05 Thread Heinrich Schuchardt

plasma-workspace 4:5.14.5.1-3 (available with Sid) has the same problems.

Best regards

Heinrich Schuchardt



Bug#938200: python-stem: diff for NMU version 1.7.1-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 938200 + patch
Control: tags 938200 + pending


Dear maintainer,

I've prepared an NMU for python-stem (versioned as 1.7.1-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-stem-1.7.1/debian/changelog python-stem-1.7.1/debian/changelog
--- python-stem-1.7.1/debian/changelog	2018-12-26 18:41:51.0 -0500
+++ python-stem-1.7.1/debian/changelog	2019-10-05 21:50:32.0 -0400
@@ -1,3 +1,10 @@
+python-stem (1.7.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938200
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:50:32 -0400
+
 python-stem (1.7.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-stem-1.7.1/debian/control python-stem-1.7.1/debian/control
--- python-stem-1.7.1/debian/control	2018-12-26 18:41:51.0 -0500
+++ python-stem-1.7.1/debian/control	2019-10-05 21:49:01.0 -0400
@@ -5,23 +5,12 @@
 Build-Depends: debhelper (>= 11),
  dh-python,
  pypy,
- python-all (>= 2.6.6-6),
  python3-all,
 Standards-Version: 4.3.0
 Homepage: https://gitweb.torproject.org/stem.git
 Vcs-Git: https://salsa.debian.org/debian/python-stem.git
 Vcs-Browser: https://salsa.debian.org/debian/python-stem
 
-Package: python-stem
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: Tor control library for Python
- Stem is a Python controller library for Tor. With it you can use
- Tor's control protocol to script against the Tor process and read
- descriptor data relays publish about themselves.
- .
- This is Python 2 series module.
-
 Package: python3-stem
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, python3-distutils
diff -Nru python-stem-1.7.1/debian/python-stem.postinst python-stem-1.7.1/debian/python-stem.postinst
--- python-stem-1.7.1/debian/python-stem.postinst	2018-12-26 18:41:51.0 -0500
+++ python-stem-1.7.1/debian/python-stem.postinst	1969-12-31 19:00:00.0 -0500
@@ -1,13 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = "configure" ]; then
-update-alternatives \
---install /usr/bin/tor-prompt tor-prompt /usr/bin/python2-tor-prompt 300 \
---slave /usr/share/man/man8/tor-prompt.8.gz tor-prompt.8.gz \
-/usr/share/man/man8/python2-tor-prompt.8.gz
-fi
-
-#DEBHELPER#
-
-exit 0
diff -Nru python-stem-1.7.1/debian/python-stem.prerm python-stem-1.7.1/debian/python-stem.prerm
--- python-stem-1.7.1/debian/python-stem.prerm	2018-12-26 18:41:51.0 -0500
+++ python-stem-1.7.1/debian/python-stem.prerm	1969-12-31 19:00:00.0 -0500
@@ -1,10 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = "remove" ]; then
-update-alternatives --remove tor-prompt /usr/bin/python2-tor-prompt
-fi
-
-#DEBHELPER#
-
-exit 0
diff -Nru python-stem-1.7.1/debian/rules python-stem-1.7.1/debian/rules
--- python-stem-1.7.1/debian/rules	2018-12-26 18:41:51.0 -0500
+++ python-stem-1.7.1/debian/rules	2019-10-05 21:49:47.0 -0400
@@ -6,22 +6,19 @@
 export PYBUILD_NAME=stem
 
 %:
-		dh $@ --with python2,python3,pypy  --buildsystem=pybuild
+		dh $@ --with python3,pypy  --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean
-	rm -rf build debian/python2-tor-prompt.8 debian/python3-tor-prompt.8
+	rm -rf build debian/python3-tor-prompt.8
 
 override_dh_auto_install:
 	dh_auto_install
-	mv debian/python-stem/usr/bin/tor-prompt debian/python-stem/usr/bin/python2-tor-prompt
 	mv debian/python3-stem/usr/bin/tor-prompt debian/python3-stem/usr/bin/python3-tor-prompt
 
 override_dh_installman:
-	cp debian/tor-prompt.8 debian/python2-tor-prompt.8
 	cp debian/tor-prompt.8 debian/python3-tor-prompt.8
 	dh_installman -ppypy-stem debian/tor-prompt.8
-	dh_installman -ppython-stem debian/python2-tor-prompt.8
 	dh_installman -ppython3-stem debian/python3-tor-prompt.8
 
 override_dh_installexamples:


Bug#941826: php-http: undefined symbol: uidna_IDNToASCII

2019-10-05 Thread Tomoo Nomura
Package: php-http
Version: 3.2.1+2.6.0-1
Severity: normal

Dear Maintainer,

I upgraded from buster to bullseye, php7.3 http.so said,
/usr/bin/php: symbol lookup error: /usr/lib/php/20180731/http.so: undefined 
symbol: uidna_IDNT

And I downgrade to php-http_3.2.0+2.6.0-2_amd64.deb, it disappered.

I checked past bug reports and found
Bug#849939: marked as done (undefined symbol: uidna_IDNToASCII)
Found in version php-pecl-http/3.1.0+2.6.0-1
Fixed in version php-pecl-http/3.1.0+2.6.0-3

It seems to be reoccurence.

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


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (101, 'testing'), (100, 'stable'), (99, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 php-http depends on:
ii  libapache2-mod-php7.3 [phpapi-20180731]  7.3.9-1
ii  libc62.29-2
ii  libcurl4 7.66.0-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libicu60 60.2-6
ii  libidn11 1.33-2.2
ii  libssl1.11.1.1d-1
ii  php-common   2:69
ii  php-propro   2.1.0+1.0.2-2
ii  php-raphf2.0.0+1.1.2-4
ii  php7.3-cgi [phpapi-20180731] 7.3.9-1
ii  php7.3-cli [phpapi-20180731] 7.3.9-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

php-http recommends no packages.

php-http suggests no packages.

-- Configuration Files:
/etc/php/7.3/mods-available/http.ini changed:
; configuration for php http module
; priority=25
extension=http.so


-- no debconf information



Bug#938173: python-sigmavirus24-urltemplate: diff for NMU version 3.0.0+git20181031.68064e2-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 938173 + patch
Control: tags 938173 + pending


Dear maintainer,

I've prepared an NMU for python-sigmavirus24-urltemplate (versioned as 
3.0.0+git20181031.68064e2-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/changelog python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/changelog
--- python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/changelog	2018-12-20 01:39:34.0 -0500
+++ python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/changelog	2019-10-05 21:36:07.0 -0400
@@ -1,3 +1,10 @@
+python-sigmavirus24-urltemplate (3.0.0+git20181031.68064e2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938173
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:36:07 -0400
+
 python-sigmavirus24-urltemplate (3.0.0+git20181031.68064e2-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/control python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/control
--- python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/control	2018-12-20 01:09:03.0 -0500
+++ python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/control	2019-10-05 21:35:56.0 -0400
@@ -4,8 +4,6 @@
 Maintainer: SZ Lin (林上智) 
 Build-Depends: debhelper (>= 11),
dh-python,
-   python (>= 2.6),
-   python-setuptools,
python3 (>= 3.2),
python3-setuptools
 Standards-Version: 4.2.1
@@ -13,15 +11,6 @@
 Vcs-Git: https://salsa.debian.org/debian/python-sigmavirus24-urltemplate.git
 Vcs-Browser: https://salsa.debian.org/debian/python-sigmavirus24-urltemplate
 
-Package: python-sigmavirus24-urltemplate
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: Simple Python library to deal with URI Templates - Python 2.x
- It provides several API for URI template parsing
- which implements RFC6570.
- .
- This package installs the library for Python 2.x.
-
 Package: python3-sigmavirus24-urltemplate
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/rules python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/rules
--- python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/rules	2018-08-27 22:38:21.0 -0400
+++ python-sigmavirus24-urltemplate-3.0.0+git20181031.68064e2/debian/rules	2019-10-05 21:36:05.0 -0400
@@ -1,8 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME:=sigmavirus24-urltemplate
-export PYBUILD_INSTALL_ARGS_python2=--install-lib=/usr/lib/python2.7/dist-packages/python-sigmavirus24-urltemplate
 export PYBUILD_INSTALL_ARGS_python3=--install-lib=/usr/lib/python3/dist-packages/python-sigmavirus24-urltemplate
 
 %:
-	dh $@  --with python2,python3 --buildsystem=pybuild
+	dh $@  --with python3 --buildsystem=pybuild


Bug#938109: python-q: diff for NMU version 2.6-1.2

2019-10-05 Thread Sandro Tosi
Control: tags 938109 + patch
Control: tags 938109 + pending


Dear maintainer,

I've prepared an NMU for python-q (versioned as 2.6-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-q-2.6/debian/changelog python-q-2.6/debian/changelog
--- python-q-2.6/debian/changelog	2017-08-04 08:32:15.0 -0400
+++ python-q-2.6/debian/changelog	2019-10-05 21:30:53.0 -0400
@@ -1,3 +1,10 @@
+python-q (2.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938109
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:30:53 -0400
+
 python-q (2.6-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-q-2.6/debian/control python-q-2.6/debian/control
--- python-q-2.6/debian/control	2017-08-04 08:32:10.0 -0400
+++ python-q-2.6/debian/control	2019-10-05 21:30:31.0 -0400
@@ -5,8 +5,6 @@
 Build-Depends: debhelper (>= 9~)
 Build-Depends-Indep:
  dh-python,
- python-setuptools (>= 0.6b3),
- python-all (>= 2.6.6-3),
  python3-all,
  python3-setuptools,
 Standards-Version: 3.9.6
@@ -16,14 +14,6 @@
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-q.git
 Vcs-Browser: https://anonscm.debian.org/gitweb/?p=collab-maint/python-q.git
 
-Package: python-q
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Quick-and-dirty Python debugging output for tired programmers
- q is a Python module for "print" style of debugging Python code.
- It provides convenient short API for print out of values, tracebacks,
- and falling into the Python interpreter.
-
 Package: python3-q
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-q-2.6/debian/python-q.docs python-q-2.6/debian/python-q.docs
--- python-q-2.6/debian/python-q.docs	2016-01-03 10:39:48.0 -0500
+++ python-q-2.6/debian/python-q.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.md
diff -Nru python-q-2.6/debian/rules python-q-2.6/debian/rules
--- python-q-2.6/debian/rules	2016-01-03 10:39:48.0 -0500
+++ python-q-2.6/debian/rules	2019-10-05 21:30:52.0 -0400
@@ -3,11 +3,11 @@
 export DH_VERBOSE=1
 export PYBUILD_NAME=q
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
-	for python in $(shell pyversions -r) $(shell py3versions -r); do \
+	for python in $(shell py3versions -r); do \
 		$$python test/test_basic.py -v; \
 	done
 endif


Bug#941825: syncthing: 2Gb index-v0.14.0.db

2019-10-05 Thread sergio
Package: syncthing
Version: 1.1.4~ds1-4
Severity: normal

Dear Maintainer,

% du -sh .config/syncthing/index-v0.14.0.db
2.2G.config/syncthing/index-v0.14.0.db

% ls -1 .config/syncthing/index-v0.14.0.db | wc -l
938



Bug#938034: python-plumbum: diff for NMU version 1.6.7-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 938034 + patch
Control: tags 938034 + pending


Dear maintainer,

I've prepared an NMU for python-plumbum (versioned as 1.6.7-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-plumbum-1.6.7/debian/changelog python-plumbum-1.6.7/debian/changelog
--- python-plumbum-1.6.7/debian/changelog	2018-09-11 06:52:30.0 -0400
+++ python-plumbum-1.6.7/debian/changelog	2019-10-05 21:24:21.0 -0400
@@ -1,3 +1,10 @@
+python-plumbum (1.6.7-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938034
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:24:21 -0400
+
 python-plumbum (1.6.7-1) unstable; urgency=medium
 
   * New upstream version 1.6.7
diff -Nru python-plumbum-1.6.7/debian/control python-plumbum-1.6.7/debian/control
--- python-plumbum-1.6.7/debian/control	2018-09-11 06:48:37.0 -0400
+++ python-plumbum-1.6.7/debian/control	2019-10-05 21:24:02.0 -0400
@@ -5,8 +5,6 @@
 Priority: optional
 Build-Depends: debhelper (>= 11~),
dh-python,
-   python-all,
-   python-setuptools,
python3-all,
python3-setuptools
 Standards-Version: 4.2.1
@@ -14,19 +12,6 @@
 Vcs-Git: https://salsa.debian.org/debian/python-plumbum.git
 Homepage: http://plumbum.readthedocs.org
 
-Package: python-plumbum
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends}
-Description: library for writing shell script-like programs in Python 2
- python-plumbum provides shell-like syntax and handy shortcuts for writing shell
- script one-liners in Python using shell combinators. It supports local and
- remote command execution (over SSH), local and remote file-system paths,
- easy working-directory and environment manipulation and a programmatic
- Command-Line Interface (CLI) application toolkit.
- .
- This is the Python 2 version.
-
 Package: python3-plumbum
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-plumbum-1.6.7/debian/python-plumbum.docs python-plumbum-1.6.7/debian/python-plumbum.docs
--- python-plumbum-1.6.7/debian/python-plumbum.docs	2018-09-11 04:51:46.0 -0400
+++ python-plumbum-1.6.7/debian/python-plumbum.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.rst
diff -Nru python-plumbum-1.6.7/debian/python-plumbum.lintian-overrides python-plumbum-1.6.7/debian/python-plumbum.lintian-overrides
--- python-plumbum-1.6.7/debian/python-plumbum.lintian-overrides	2018-09-11 04:51:46.0 -0400
+++ python-plumbum-1.6.7/debian/python-plumbum.lintian-overrides	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-python-plumbum: no-upstream-changelog
diff -Nru python-plumbum-1.6.7/debian/rules python-plumbum-1.6.7/debian/rules
--- python-plumbum-1.6.7/debian/rules	2018-09-11 04:51:46.0 -0400
+++ python-plumbum-1.6.7/debian/rules	2019-10-05 21:24:20.0 -0400
@@ -7,4 +7,4 @@
 export PYBUILD_NAME=plumbum
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#941782: gir1.2-gnomedesktop-3.0 3.34.0-2 breaks gnome-shell

2019-10-05 Thread Jean-Marc
On Sat, 5 Oct 2019 15:33:34 -0700 Mike Miller  wrote:
> Package: gir1.2-gnomedesktop-3.0
> Version: 3.34.0-2
> Followup-For: Bug #941782
> 
> Affected by this today, gnome-shell is completely non-functional with
> the version of gir1.2-gnomedesktop-3.0 now in testing. Confirm that
> installing the stable version of the package (3.30.2.1-2) restores it.

and to restore/install the stable version of the package gir1.2-gnomedesktop-3.0
1/ add the stable to your source.list
2/ sudo apt update
3/ sudo apt install gir1.2-gnomedesktop-3.0=3.30.2.1-2
4/ sudo apt-mark hold gir1.2-gnomedesktop-3.0

Do not forget to mark it unhold once the bug will be fixed.

> -- 
> mike

I add this info to this bug because a lot of people asked for a solution on the 
#debian-next channel since yesterday.

Regards,

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpNkAmYYTk86.pgp
Description: PGP signature


Bug#938023: python-phpserialize: diff for NMU version 1.3-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 938023 + patch
Control: tags 938023 + pending


Dear maintainer,

I've prepared an NMU for python-phpserialize (versioned as 1.3-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-phpserialize-1.3/debian/changelog python-phpserialize-1.3/debian/changelog
--- python-phpserialize-1.3/debian/changelog	2015-10-14 14:20:56.0 -0400
+++ python-phpserialize-1.3/debian/changelog	2019-10-05 21:17:54.0 -0400
@@ -1,3 +1,10 @@
+python-phpserialize (1.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938023
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:17:54 -0400
+
 python-phpserialize (1.3-1) unstable; urgency=low
 
   * Initial release (closes: #801801).
diff -Nru python-phpserialize-1.3/debian/control python-phpserialize-1.3/debian/control
--- python-phpserialize-1.3/debian/control	2015-10-14 14:20:56.0 -0400
+++ python-phpserialize-1.3/debian/control	2019-10-05 21:17:36.0 -0400
@@ -2,22 +2,10 @@
 Section: python
 Priority: optional
 Maintainer: Tristan Seligmann 
-Build-Depends: debhelper (>= 9), dh-python, python, python-setuptools, python3, python3-setuptools
+Build-Depends: debhelper (>= 9), dh-python, python3, python3-setuptools
 Standards-Version: 3.9.6
 Homepage: http://github.com/mitsuhiko/phpserialize
 
-Package: python-phpserialize
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Recommends: ${python:Recommends}
-Suggests: ${python:Suggests}
-XB-Python-Egg-Name: phpserialize
-Description: Python port of PHP serialize and unserialize functions (Python 2)
- This module implements the Python serialization interface (eg: provides dumps,
- loads and similar functions).
- .
- This package contains phpserialize for Python 2.
-
 Package: python3-phpserialize
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-phpserialize-1.3/debian/python-phpserialize.pydist python-phpserialize-1.3/debian/python-phpserialize.pydist
--- python-phpserialize-1.3/debian/python-phpserialize.pydist	2015-10-14 14:20:56.0 -0400
+++ python-phpserialize-1.3/debian/python-phpserialize.pydist	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-phpserialize python-phpserialize; PEP386
diff -Nru python-phpserialize-1.3/debian/rules python-phpserialize-1.3/debian/rules
--- python-phpserialize-1.3/debian/rules	2015-10-14 14:20:56.0 -0400
+++ python-phpserialize-1.3/debian/rules	2019-10-05 21:17:52.0 -0400
@@ -2,4 +2,4 @@
 
 export PYBUILD_NAME=phpserialize
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#938021: python-phabricator: diff for NMU version 0.7.0-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 938021 + patch
Control: tags 938021 + pending


Dear maintainer,

I've prepared an NMU for python-phabricator (versioned as 0.7.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-phabricator-0.7.0/debian/changelog python-phabricator-0.7.0/debian/changelog
--- python-phabricator-0.7.0/debian/changelog	2016-12-18 13:30:51.0 -0500
+++ python-phabricator-0.7.0/debian/changelog	2019-10-05 21:15:17.0 -0400
@@ -1,3 +1,10 @@
+python-phabricator (0.7.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938021
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:15:17 -0400
+
 python-phabricator (0.7.0-1) unstable; urgency=medium
 
   * New upstream version 0.7.0
diff -Nru python-phabricator-0.7.0/debian/control python-phabricator-0.7.0/debian/control
--- python-phabricator-0.7.0/debian/control	2016-12-18 13:30:29.0 -0500
+++ python-phabricator-0.7.0/debian/control	2019-10-05 21:15:00.0 -0400
@@ -4,13 +4,9 @@
 Maintainer: Héctor Orón Martínez 
 Build-Depends: debhelper (>= 9),
  dh-python,
- python-all,
- python-setuptools,
  python3-all,
  python3-setuptools,
- python-mock,
  python3-mock,
- python-unittest2,
 X-Python-Version: >= 2.6
 X-Python3-Version: >= 3.2
 Standards-Version: 3.9.8
@@ -18,16 +14,6 @@
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/python-phabricator.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-phabricator.git
 
-Package: python-phabricator
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends}
-Description: Phabricator Python API Bindings (Python 2)
- Phabricator is an open source collection of web applications which make it
- easier to write, review, and share source code.
- .
- The current package provides Python API bindings for Phabricator interfaces.
-
 Package: python3-phabricator
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-phabricator-0.7.0/debian/python-phabricator.pyremove python-phabricator-0.7.0/debian/python-phabricator.pyremove
--- python-phabricator-0.7.0/debian/python-phabricator.pyremove	2016-12-18 13:26:26.0 -0500
+++ python-phabricator-0.7.0/debian/python-phabricator.pyremove	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-phabricator*.egg-info 2.6
-phabricator*.egg-info 2.7
diff -Nru python-phabricator-0.7.0/debian/rules python-phabricator-0.7.0/debian/rules
--- python-phabricator-0.7.0/debian/rules	2016-12-18 13:26:26.0 -0500
+++ python-phabricator-0.7.0/debian/rules	2019-10-05 21:15:15.0 -0400
@@ -3,7 +3,7 @@
 export PYBUILD_NAME = phabricator
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_clean:
 	rm -rf phabricator.egg-info


Bug#937999: python-parse: diff for NMU version 1.6.6-0.2

2019-10-05 Thread Sandro Tosi
Control: tags 937999 + patch
Control: tags 937999 + pending


Dear maintainer,

I've prepared an NMU for python-parse (versioned as 1.6.6-0.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-parse-1.6.6/debian/changelog python-parse-1.6.6/debian/changelog
--- python-parse-1.6.6/debian/changelog	2017-01-12 05:57:30.0 -0500
+++ python-parse-1.6.6/debian/changelog	2019-10-05 21:07:45.0 -0400
@@ -1,3 +1,10 @@
+python-parse (1.6.6-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937999
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:07:45 -0400
+
 python-parse (1.6.6-0.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru python-parse-1.6.6/debian/control python-parse-1.6.6/debian/control
--- python-parse-1.6.6/debian/control	2017-01-12 05:57:30.0 -0500
+++ python-parse-1.6.6/debian/control	2019-10-05 21:07:34.0 -0400
@@ -5,37 +5,10 @@
   Cyril Bouthors 
 Section: python
 Priority: optional
-Build-Depends: python-all, python3-all, debhelper (>= 10), dh-python
+Build-Depends: python3-all, debhelper (>= 10), dh-python
 Standards-Version: 3.9.8
 Homepage: https://github.com/r1chardj0n3s/parse
 
-Package: python-parse
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Parse provides the reverse function for format(), Python2 package
- Parse strings using a specification based on the Python format() syntax.
- .
-``parse()`` is the opposite of ``format()``
- .
- The module is set up to only export ``parse()``, ``search()`` and
- ``findall()`` when ``import *`` is used:
- .
- >>> from parse import *
- .
- From there it's a simple thing to parse a string:
- .
- >>> parse("It's {}, I love it!", "It's spam, I love it!")
- 
- >>> _[0]
- 'spam'
- .
- Or to search a string for some pattern:
- .
- >>> search('Age: {:d}\n', 'Name: Rufus\nAge: 42\nColor: red\n')
- 
- .
- This is the Python 2 package
-
 Package: python3-parse
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-parse-1.6.6/debian/rules python-parse-1.6.6/debian/rules
--- python-parse-1.6.6/debian/rules	2017-01-12 05:57:30.0 -0500
+++ python-parse-1.6.6/debian/rules	2019-10-05 21:07:44.0 -0400
@@ -6,6 +6,6 @@
 export PYBUILD_NAME = parse
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 


Bug#941802: calibre: ebook-viewer depends on PyQt5.QtWebEngineCore (missing)

2019-10-05 Thread Norbert Preining
frocemerge 941802 941806
tag 941802 + pending
thanks

Thanks for the reports, indeed, the Python 2 version of qtwebengine is
not available (anymore since the extraction from the main pyqt5
package).

That means, that Calibre >= 4.0 will not be able to run on Debian for
now.

I will upload a version that reverts to 3.48, and this will be the
last version of Calibre in Debian until upstream Calibre switches to
Python3, which hopefully will happen at some point.

Thanks
Norbert

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



Bug#937995: python-paho-mqtt: diff for NMU version 1.4.0-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 937995 + patch
Control: tags 937995 + pending


Dear maintainer,

I've prepared an NMU for python-paho-mqtt (versioned as 1.4.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-paho-mqtt-1.4.0/debian/changelog python-paho-mqtt-1.4.0/debian/changelog
--- python-paho-mqtt-1.4.0/debian/changelog	2018-10-20 15:45:37.0 -0400
+++ python-paho-mqtt-1.4.0/debian/changelog	2019-10-05 21:02:18.0 -0400
@@ -1,3 +1,10 @@
+python-paho-mqtt (1.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937995
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 21:02:18 -0400
+
 python-paho-mqtt (1.4.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru python-paho-mqtt-1.4.0/debian/control python-paho-mqtt-1.4.0/debian/control
--- python-paho-mqtt-1.4.0/debian/control	2018-10-20 15:45:37.0 -0400
+++ python-paho-mqtt-1.4.0/debian/control	2019-10-05 21:01:56.0 -0400
@@ -5,8 +5,6 @@
 Build-Depends: debhelper (>= 11~),
dh-python,
pylama,
-   python-all,
-   python-setuptools,
python3-all,
python3-setuptools
 Standards-Version: 4.2.1
@@ -14,23 +12,6 @@
 Vcs-Browser: https://salsa.debian.org/debian/python-paho-mqtt
 Vcs-Git: https://salsa.debian.org/debian/python-paho-mqtt.git
 
-Package: python-paho-mqtt
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: MQTT client class (Python 2)
- This code provides a client class which enable applications to connect
- to an MQTT broker to publish messages, and to subscribe to topics and
- receive published messages. It also provides some helper functions to
- make publishing one off messages to an MQTT server very straightforward.
- .
- The MQTT protocol is a machine-to-machine (M2M)/”Internet of Things”
- connectivity protocol. Designed as an extremely lightweight publish/
- subscribe messaging transport, it is useful for connections with remote
- locations where a small code footprint is required and/or network
- bandwidth is at a premium.
- .
- This is the Python 2 version of the package.
-
 Package: python3-paho-mqtt
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru python-paho-mqtt-1.4.0/debian/rules python-paho-mqtt-1.4.0/debian/rules
--- python-paho-mqtt-1.4.0/debian/rules	2018-10-20 15:45:37.0 -0400
+++ python-paho-mqtt-1.4.0/debian/rules	2019-10-05 21:02:14.0 -0400
@@ -2,7 +2,7 @@
 export PYBUILD_NAME=paho-mqtt
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
 	# test is broken


Bug#941823: tabu: cell background colours broken

2019-10-05 Thread Thorsten Glaser
Package: texlive-latex-extra
Version: 2019.20190930-2
Followup-For: Bug #941823

Also exists on latest sid. (I’ve initially reported against
the older version on the system I noticed it on so you might
have it easier to track down the change at fault, but rete‐
sted, in case it was already fixed.)


##
 List of ls-R files

-rw-r--r-- 1 root root 2310 Oct  4 15:38 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jul 31 09:21 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Sep 30 02:59 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Sep 30 02:59 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug  5 20:09 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Sep 30 02:59 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Sep 30 02:59 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 Oct  1 15:23 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Nov 26  2007 mktex.cnf
-rw-r--r-- 1 root root 475 Aug  5 20:09 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-2
ii  python 2.7.16-1
ii  python33.7.5-1
ii  tex-common 6.12
ii  texlive-base   2019.20190930-1
ii  texlive-binaries   2019.20190605.51237-3
ii  texlive-latex-recommended  2019.20190930-1
ii  texlive-pictures   2019.20190930-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2019.20190930-1
ii  texlive-plain-generic  2019.20190930-2

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.3.1+dfsg-1
ii  texlive-latex-extra-doc 2019.20190930-2

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

Versions of packages tex-common suggests:
ii  debhelper  12.6.1

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.12
ii  texlive-binaries  2019.20190605.51237-3

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:


Bug#937949: python-nmea2: diff for NMU version 1.15.0-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 937949 + patch
Control: tags 937949 + pending


Dear maintainer,

I've prepared an NMU for python-nmea2 (versioned as 1.15.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-nmea2-1.15.0/debian/changelog python-nmea2-1.15.0/debian/changelog
--- python-nmea2-1.15.0/debian/changelog	2019-07-23 09:01:19.0 -0400
+++ python-nmea2-1.15.0/debian/changelog	2019-10-05 20:45:24.0 -0400
@@ -1,3 +1,10 @@
+python-nmea2 (1.15.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937949
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 20:45:24 -0400
+
 python-nmea2 (1.15.0-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru python-nmea2-1.15.0/debian/control python-nmea2-1.15.0/debian/control
--- python-nmea2-1.15.0/debian/control	2019-07-23 09:01:19.0 -0400
+++ python-nmea2-1.15.0/debian/control	2019-10-05 20:45:10.0 -0400
@@ -2,22 +2,12 @@
 Section: python
 Priority: optional
 Maintainer: Ulises Vitulli 
-Build-Depends: debhelper (>= 12), python (>= 2.6.6-3~), dh-python,
- python-setuptools, python3-setuptools, python3-all
+Build-Depends: debhelper (>= 12), dh-python,
+ python3-setuptools, python3-all
 Standards-Version: 4.4.0
 Homepage: https://github.com/Knio/pynmea2
 Vcs-Browser: https://github.com/Knio/pynmea2
 
-Package: python-nmea2
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: Python library for the NMEA 0183 protocol
- A Python Library for the NMEA 0183 protocol
- .
- NMEA 0183 is a combined electrical and data specification for communication
- between marine electronics such as echo sounder, sonars, anemometer,
- gyrocompass, autopilot, GPS receivers and many other types of instruments.
-
 Package: python3-nmea2
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru python-nmea2-1.15.0/debian/rules python-nmea2-1.15.0/debian/rules
--- python-nmea2-1.15.0/debian/rules	2019-07-23 09:01:19.0 -0400
+++ python-nmea2-1.15.0/debian/rules	2019-10-05 20:45:21.0 -0400
@@ -6,4 +6,4 @@
 export PYBUILD_NAME = nmea2
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#941824: RM: alarm-clock-applet -- RoQA; unmaintained, depends on libunique

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: alarm-clock-app...@packages.debian.org
Affects: src:alarm-clock-applet

alarm-clock-applet was removed from Testing a year and a half ago
because it depends on libunique, an unmaintained GNOME 2 library. The
Debian GNOME team is trying to remove libunique from Debian.

There has been basically no activity on the bug. There have been no
uploads in 4 years.

Please remove alarm-clock-applet from Debian.

Testing removal bug: https://bugs.debian.org/892539

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941823: tabu: cell background colours broken

2019-10-05 Thread Thorsten Glaser
Package: texlive-latex-extra
Version: 2019.20190830-1
Severity: normal

Cell background colours are broken in tabu. When I change
the MWE to use the tabular environment…

 \begin{tabular}{|l|l|l|}

… things look as expected. Building on stretch (don’t have
texlive in buster handy) is also expected.

Large actual use case:
https://edugit.org/mirabilos/teckidscal-standalone

##
minimal input file

attached as x.tex

##
other files

attached as x.fls, x-expected.pdf (stretch), x-actual.pdf (sid)

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Jan 15  2016 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 2108 Sep  7 16:23 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jul 31 09:21 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 30 03:33 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 30 03:33 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 14 19:35 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 30 03:33 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 30 03:33 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 Sep  7 16:22 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jun 15  2013 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 14 19:35 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-extra depends on:
ii  preview-latex-style11.91-2
ii  python 2.7.16-1
ii  python33.7.3-1
ii  tex-common 6.12
ii  texlive-base   2019.20190830-1
ii  texlive-binaries   2019.20190605.51237-2
ii  texlive-latex-recommended  2019.20190830-1
ii  texlive-pictures   2019.20190830-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2019.20190830-1
ii  texlive-plain-generic  2019.20190830-1

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.3.1+dfsg-1
ii  texlive-latex-extra-doc 2019.20190830-1

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

Versions of packages tex-common suggests:
ii  debhelper  12.5.4

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.12
ii  texlive-binaries  2019.20190605.51237-2

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:
\documentclass{article}%
\usepackage[utf8]{inputenc}%
\usepackage{color}%
\usepackage[T1]{fontenc}%
\usepackage[table]{xcolor}%
\usepackage{tabu}%

\definecolor{teckidscal5}{HTML}{D12A00}%
\definecolor{teckidscal5Label}{HTML}{FF}%

\begin{document}
 test \textcolor{teckidscal5}{colourised} normal

 \begin{tabu} to \linewidth {|X|X|X|}
  \hline
  \strut foo & \cellcolor{teckidscal5}\color{teckidscal5Label}bar & 
baz\strut\\\hline
 \end{tabu}

 blah
\end{document}
PWD /home/tglase
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT x.tex
OUTPUT x.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty

Bug#941811: please convert package to use dh-elpa for perlcritic.el

2019-10-05 Thread Nicholas D Steeves
Hi Salvatore,

Salvatore Bonaccorso  writes:

> hi Nicholas,
>
> On Sat, Oct 05, 2019 at 05:42:36PM -0400, Nicholas D Steeves wrote:
>> Package: libperl-critic-perl
>> Version: 1.132-1
>> Severity: normal
>> 
>> Dear maintainer,
>> 
>> I've confirmed this affects 1.134-1.  Please convert
>> libperl-critic-perl to use dh-elpa for perlcritic.el.  It handles byte
>> compilation which the package in buster lacks.
>> 
>> It looks like emacsen-startup is Debian-specific customisation.
>> That
>> will go in the debian-autoloads.el file.  See § "Debian-specific
>> Lisp customizations" (man dh_elpa).
>
> it looks we did that back in
>
> libperl-critic-perl (1.092-1) unstable; urgency=low
> [...]
>   * install perlcritic.el into site-lisp, add debian/emacsen-startup
> adds perlcritic mode to Emacs. Thanks to Kevin Ryde for the suggestion and
> the patch. Closes: #483288
>
> Would you be open to help providing this conversion?

Yes, absolutely; however, I expect to be swamped with work for the next
week or two.  Here's an example of a moderately complex case of similar
file-mode.el bundled in upstream src:package, with atomic commits for
each operation:

  https://salsa.debian.org/sten-guest/tuareg-mode/commits/master

The biggest changes are perlcritic.el is added to
"debian/elpa-perlcritic.elpa", with some definitions in d/control, plus
the Debian-specific customisation I noted previously.  Breaks & replaces
are essential, but please omit provides in this case.  The
elpa-perlcritic.pkg file might need a hint for successful generation.
#debian-emacs is a friendly team too, so feel free to drop by even if
I'm not there :-)


Happy hacking,
Nicholas


signature.asc
Description: PGP signature


Bug#937882: python-lepl: diff for NMU version 5.1.3-2.1

2019-10-05 Thread Sandro Tosi
Control: tags 937882 + patch
Control: tags 937882 + pending


Dear maintainer,

I've prepared an NMU for python-lepl (versioned as 5.1.3-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-lepl-5.1.3/debian/changelog python-lepl-5.1.3/debian/changelog
--- python-lepl-5.1.3/debian/changelog	2013-10-15 12:53:07.0 -0400
+++ python-lepl-5.1.3/debian/changelog	2019-10-05 19:53:14.0 -0400
@@ -1,3 +1,10 @@
+python-lepl (5.1.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937882
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 19:53:14 -0400
+
 python-lepl (5.1.3-2) unstable; urgency=low
 
   * New maintainer (Closes: #706288)
diff -Nru python-lepl-5.1.3/debian/control python-lepl-5.1.3/debian/control
--- python-lepl-5.1.3/debian/control	2013-10-15 12:50:06.0 -0400
+++ python-lepl-5.1.3/debian/control	2019-10-05 19:51:58.0 -0400
@@ -3,8 +3,6 @@
 Priority: optional
 Maintainer: Radu-Bogdan Croitoru 
 Build-Depends: debhelper (>= 9),
-   python (>= 2.6.6-3~),
-   python-setuptools,
python3-all,
python3-setuptools
 X-Python-Version: >= 2.6
@@ -12,16 +10,6 @@
 Standards-Version: 3.9.4
 Homepage: http://www.acooke.org/lepl/
 
-Package: python-lepl
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: recursive descent parser library
- A recursive descent parser for Python 2.6+ (including 3!). Lepl is powerful,
- simple to use, and easy to extend: grammars are written directly as Python
- code, using a syntax similar to BNF; new matchers can be simple functions.
- .
- This is the Python 2 version of the package.
-
 Package: python3-lepl
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-lepl-5.1.3/debian/python-lepl.install python-lepl-5.1.3/debian/python-lepl.install
--- python-lepl-5.1.3/debian/python-lepl.install	2012-08-16 01:42:51.0 -0400
+++ python-lepl-5.1.3/debian/python-lepl.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru python-lepl-5.1.3/debian/rules python-lepl-5.1.3/debian/rules
--- python-lepl-5.1.3/debian/rules	2012-08-16 01:42:51.0 -0400
+++ python-lepl-5.1.3/debian/rules	2019-10-05 19:53:14.0 -0400
@@ -9,11 +9,10 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-PYTHON2=$(shell pyversions -vr)
 PYTHON3=$(shell py3versions -vr)
 
 %:
-	dh  $@ --with python2,python3
+	dh  $@ --with python3 --buildsystem=pybuild
 
 build-python%:
 	python$* setup.py build


Bug#937865: python-kaitaistruct: diff for NMU version 0.8-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 937865 + patch
Control: tags 937865 + pending


Dear maintainer,

I've prepared an NMU for python-kaitaistruct (versioned as 0.8-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-kaitaistruct-0.8/debian/changelog python-kaitaistruct-0.8/debian/changelog
--- python-kaitaistruct-0.8/debian/changelog	2018-03-30 08:02:03.0 -0400
+++ python-kaitaistruct-0.8/debian/changelog	2019-10-05 19:48:56.0 -0400
@@ -1,3 +1,10 @@
+python-kaitaistruct (0.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937865
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 19:48:56 -0400
+
 python-kaitaistruct (0.8-1) unstable; urgency=medium
 
   * Switch to DEP 14
diff -Nru python-kaitaistruct-0.8/debian/control python-kaitaistruct-0.8/debian/control
--- python-kaitaistruct-0.8/debian/control	2018-03-30 08:02:03.0 -0400
+++ python-kaitaistruct-0.8/debian/control	2019-10-05 19:48:47.0 -0400
@@ -2,7 +2,7 @@
 Maintainer: Sebastien Delafond 
 Section: python
 Priority: optional
-Build-Depends: dh-python, python-setuptools (>= 0.6b3), python3-setuptools, python-all (>= 2.6.6-3), python3-all, debhelper (>= 9)
+Build-Depends: dh-python, python3-setuptools, python3-all, debhelper (>= 9)
 Standards-Version: 4.1.3
 Homepage: https://kaitai.io
 Vcs-Git: https://salsa.debian.org/debian/python-kaitaistruct.git
@@ -10,21 +10,6 @@
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.4
 
-Package: python-kaitaistruct
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Kaitai Struct declarative parser generator for binary data
- This library implements Kaitai Struct API for Python.
- .
- Kaitai Struct is a declarative language used for describe various
- binary data structures, laid out in files or in memory: i.e. binary
- file formats, network stream packet formats, etc.
- .
- It is similar to Python's construct and Construct3, but it is
- language-agnostic. The format description is done in YAML-based .ksy
- format, which then can be compiled into a wide range of target
- languages.
-
 Package: python3-kaitaistruct
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
@@ -40,4 +25,4 @@
  format, which then can be compiled into a wide range of target
  languages.
  .
- This is the Python3 package.
\ No newline at end of file
+ This is the Python3 package.
diff -Nru python-kaitaistruct-0.8/debian/rules python-kaitaistruct-0.8/debian/rules
--- python-kaitaistruct-0.8/debian/rules	2018-03-30 08:02:03.0 -0400
+++ python-kaitaistruct-0.8/debian/rules	2019-10-05 19:48:54.0 -0400
@@ -4,5 +4,5 @@
 # Fri, 07 Jul 2017 12:18:32 +0200
 export PYBUILD_NAME=kaitaistruct
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 


Bug#937833: python-inflect: diff for NMU version 2.1.0-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 937833 + patch
Control: tags 937833 + pending


Dear maintainer,

I've prepared an NMU for python-inflect (versioned as 2.1.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-inflect-2.1.0/debian/changelog python-inflect-2.1.0/debian/changelog
--- python-inflect-2.1.0/debian/changelog	2019-01-07 06:59:00.0 -0500
+++ python-inflect-2.1.0/debian/changelog	2019-10-05 19:39:39.0 -0400
@@ -1,3 +1,10 @@
+python-inflect (2.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937833
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 19:39:39 -0400
+
 python-inflect (2.1.0-1) unstable; urgency=medium
 
   * New upstream version 2.1.0
diff -Nru python-inflect-2.1.0/debian/control python-inflect-2.1.0/debian/control
--- python-inflect-2.1.0/debian/control	2019-01-07 06:55:20.0 -0500
+++ python-inflect-2.1.0/debian/control	2019-10-05 19:39:21.0 -0400
@@ -4,11 +4,6 @@
 Maintainer: Iain R. Learmonth 
 Build-Depends: debhelper (>= 11),
dh-python,
-   python-setuptools,
-   python-setuptools-scm,
-   python-nose,
-   python-six,
-   python-all,
python3-all,
python3-setuptools,
python3-setuptools-scm,
@@ -19,15 +14,6 @@
 Vcs-Git: https://salsa.debian.org/debian/python-inflect.git
 Homepage: https://pypi.python.org/pypi/inflect
 
-Package: python-inflect
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: Generate plurals, singular nouns, ordinals, indefinite articles
- The inflect Python module correctly generates plurals, singular nouns,
- ordinals and indefinite articles. It can also convert numbers to words.
- .
- This package contains the Python 2 version of this module.
-
 Package: python3-inflect
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru python-inflect-2.1.0/debian/rules python-inflect-2.1.0/debian/rules
--- python-inflect-2.1.0/debian/rules	2019-01-07 06:38:04.0 -0500
+++ python-inflect-2.1.0/debian/rules	2019-10-05 19:39:36.0 -0400
@@ -1,19 +1,13 @@
 #!/usr/bin/make -f
 
-PYVERS=$(shell pyversions -sv)
 PY3VERS=$(shell py3versions -sv)
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_install:
 	dh_auto_install
 
-	set -e && for pyvers in $(PYVERS); do \
-		python$$pyvers setup.py install --install-layout=deb \
-		--root $(CURDIR)/debian/python-inflect; \
-		done
-
 	set -e && for pyvers in $(PY3VERS); do \
 		python$$pyvers setup.py install --install-layout=deb \
 		--root $(CURDIR)/debian/python3-inflect; \


Bug#939526: buster-pu: package inn2/2.6.3-1+deb10u1

2019-10-05 Thread Marco d'Itri
Control: retitle -1 buster-pu: package inn2/2.6.3-1+deb10u2

Bug #931256 explains in detail why TLS is broken in inn2 in buster, due 
to the policies of newer openssl versions.

As noticed by Adam D. Barratt, the original patch had a bug: it was 
then solved by the upstream maintainer and the fix has been one month in 
testing now.


diff -Nru inn2-2.6.3/debian/changelog inn2-2.6.3/debian/changelog
--- inn2-2.6.3/debian/changelog 2019-02-17 17:52:36.0 +0100
+++ inn2-2.6.3/debian/changelog 2019-10-06 00:51:59.0 +0200
@@ -1,3 +1,11 @@
+inn2 (2.6.3-1+deb10u2) buster; urgency=medium
+
+  * Backported upstream changeset 10344 to fix negotiation of DHE
+ciphersuites. (See #931256.)
+  * Backported upstream changeset 10348 to fix upstream changeset 10344.
+
+ -- Marco d'Itri   Sun, 06 Oct 2019 00:51:59 +0200
+
 inn2 (2.6.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru inn2-2.6.3/debian/patches/changeset_10344 
inn2-2.6.3/debian/patches/changeset_10344
--- inn2-2.6.3/debian/patches/changeset_10344   1970-01-01 01:00:00.0 
+0100
+++ inn2-2.6.3/debian/patches/changeset_10344   2019-09-05 22:34:04.0 
+0200
@@ -0,0 +1,202 @@
+Index: a/nnrpd/tls.c
+===
+--- a/nnrpd/tls.c  (revision 10342)
 a/nnrpd/tls.c  (revision 10344)
+@@ -96,45 +96,58 @@
+ 
+ /*
+-**  Hardcoded DH parameter files, from OpenSSL.
+-**  For information on how these files were generated, see
+-**  "Assigned Number for SKIP Protocols" 
+-**  .
+-*/
+-static const char file_dh512[] =
++**  Hardcoded DH parameter files.
++**  These are pre-defined DH groups recommended by RFC 7919 (Appendix A),
++**  that have been audited and therefore supposed to be more
++**  resistant to attacks than ones randomly generated.
++*/
++static const char file_ffdhe2048[] = \
+ "-BEGIN DH PARAMETERS-\n\
+-MEYCQQD1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWak\n\
+-XUGfnHy9iUsiGSa6q6Jew1XpKgVfAgEC\n\
++MIIBCAKCAQEA//+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz\n\
+++8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a\n\
++87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7\n\
++YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi\n\
++7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD\n\
++ssbzSibBsu/6iGtCOGEoXJf//wIBAg==\n\
+ -END DH PARAMETERS-\n";
+ 
+-static const char file_dh1024[] =
++static const char file_ffdhe4096[] = \
+ "-BEGIN DH PARAMETERS-\n\
+-MIGHAoGBAPSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsY\n\
+-jY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6\n\
+-ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpL3jHAgEC\n\
++MIICCAKCAgEA//+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz\n\
+++8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a\n\
++87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7\n\
++YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi\n\
++7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD\n\
++ssbzSibBsu/6iGtCOGEfz9zeNVs7ZRkDW7w09N75nAI4YbRvydbmyQd62R0mkff3\n\
++7lmMsPrBhtkcrv4TCYUTknC0EwyTvEN5RPT9RFLi103TZPLiHnH1S/9croKrnJ32\n\
++nuhtK8UiNjoNq8Uhl5sN6todv5pC1cRITgq80Gv6U93vPBsg7j/VnXwl5B0rZp4e\n\
++8W5vUsMWTfT7eTDp5OWIV7asfV9C1p9tGHdjzx1VA0AEh/VbpX4xzHpxNciG77Qx\n\
++iu1qHgEtnmgyqQdgCpGBMMRtx3j5ca0AOAkpmaMzy4t6Gh25PXFAADwqTs6p+Y0K\n\
++zAqCkc3OyX3Pjsm1Wn+IpGtNtahR9EGC4caKAH5eZV9q//8CAQI=\n\
+ -END DH PARAMETERS-\n";
+ 
+-static const char file_dh2048[] =
++static const char file_ffdhe8192[] = \
+ "-BEGIN DH PARAMETERS-\n\
+-MIIBCAKCAQEA9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV\n\
+-89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50\n\
+-T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknb\n\
+-zSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdX\n\
+-Q6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbT\n\
+-CD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwIBAg==\n\
+--END DH PARAMETERS-\n";
+-
+-static const char file_dh4096[] =
+-"-BEGIN DH PARAMETERS-\n\
+-MIICCAKCAgEA+hRyUsFN4VpJ1O8JLcCo/VWr19k3BCgJ4uk+d+KhehjdRqNDNyOQ\n\
+-l/MOyQNQfWXPeGKmOmIig6Ev/nm6Nf9Z2B1h3R4hExf+zTiHnvVPeRBhjdQi81rt\n\
+-Xeoh6TNrSBIKIHfUJWBh3va0TxxjQIs6IZOLeVNRLMqzeylWqMf49HsIXqbcokUS\n\
+-Vt1BkvLdW48j8PPv5DsKRN3tloTxqDJGo9tKvj1Fuk74A+Xda1kNhB7KFlqMyN98\n\
+-VETEJ6c7KpfOo30mnK30wqw3S8OtaIR/maYX72tGOno2ehFDkq3pnPtEbD2CScxc\n\
+-alJC+EL7RPk5c/tgeTvCngvc1KZn92Y//EI7G9tPZtylj2b56sHtMftIoYJ9+ODM\n\
+-sccD5Piz/rejE3Ome8EOOceUSCYAhXn8b3qvxVI1ddd1pED6FHRhFvLrZxFvBEM9\n\
+-ERRMp5QqOaHJkM+Dxv8Cj6MqrCbfC4u+ZErxodzuusgDgvZiLF22uxMZbobFWyte\n\
+-OvOzKGtwcTqO/1wV5gKkzu1ZVswVUQd5Gg8lJicwqRWyyNRczDDoG9jVDxmogKTH\n\
+-AaqLulO7R8Ifa1SwF2DteSGVtgWEN8gDpN3RBmmPTDngyF2DHb5qmpnznwtFKdTL\n\
+-KWbuHn491xNO25CQWMtem80uKw+pTnisBRF/454n1Jnhub144YRBoN8CAQI=\n\

Bug#937790: python-glad: diff for NMU version 0.1.30-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 937790 + patch
Control: tags 937790 + pending


Dear maintainer,

I've prepared an NMU for python-glad (versioned as 0.1.30-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-glad-0.1.30/debian/changelog python-glad-0.1.30/debian/changelog
--- python-glad-0.1.30/debian/changelog	2019-06-06 11:46:45.0 -0400
+++ python-glad-0.1.30/debian/changelog	2019-10-05 19:33:43.0 -0400
@@ -1,3 +1,10 @@
+python-glad (0.1.30-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937790
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 19:33:43 -0400
+
 python-glad (0.1.30-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-glad-0.1.30/debian/control python-glad-0.1.30/debian/control
--- python-glad-0.1.30/debian/control	2019-06-06 11:43:54.0 -0400
+++ python-glad-0.1.30/debian/control	2019-10-05 19:33:26.0 -0400
@@ -4,8 +4,6 @@
 Maintainer: Steffen Moeller 
 Build-Depends: debhelper (>= 11),
  dh-python,
- python-all,
- python-setuptools,
  python3-all,
  python3-setuptools
 Standards-Version: 4.2.1
@@ -14,26 +12,6 @@
 Vcs-Git: https://salsa.debian.org/python-team/modules/glad.git
 Testsuite: autopkgtest-pkg-python
 
-Package: python-glad
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Conflicts: python3-glad
-Description: GL/GLES/EGL/GLX/WGL Loader-Generator (Python 2)
- This package provides the implementation of what is also available as
- a webservice on
-  http://glad.dav1d.de/
- to transform OpenGL specs into an API that one can program against.
- It uses the official Khronos-XML specs to generate a GL/GLES/EGL/GLX/WGL
- Loader made for your needs. Glad currently supports the languages C,
- D and Volt.
- .
- The package is not meant for end users and will not be installed
- by the users of the package that it helped building.  It is a build
- dependency that is prepared to be integrated with CMake or Conan into
- the build process.
- .
- This package installs the library for Python 2.
-
 Package: python3-glad
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru python-glad-0.1.30/debian/python-glad.manpages python-glad-0.1.30/debian/python-glad.manpages
--- python-glad-0.1.30/debian/python-glad.manpages	2019-06-06 11:43:54.0 -0400
+++ python-glad-0.1.30/debian/python-glad.manpages	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-debian/glad.1
diff -Nru python-glad-0.1.30/debian/rules python-glad-0.1.30/debian/rules
--- python-glad-0.1.30/debian/rules	2019-06-06 11:43:54.0 -0400
+++ python-glad-0.1.30/debian/rules	2019-10-05 19:33:40.0 -0400
@@ -4,5 +4,5 @@
 export PYBUILD_NAME=glad
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 


Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

2019-10-05 Thread David Steele
On Sat, Oct 5, 2019 at 1:06 PM Sean Whitton  wrote:
>
> Hello David,
>
> On Sun 29 Sep 2019 at 10:35AM -04, David Steele wrote:
>
> > On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton  
> > wrote:
> >>
> >> Hello,
> >>
> >> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote:
> >>
> >> > Reasonable. Then let's drop part about Depends:
> >> >
> >> >   [ ... All packages with daemons must provide init.d scripts ...],
> >> >   unless software is only usable, by upstream's design, when
> >> >   pid1 is provided by some other init system.
> >>
> >> I think this would work.  What do you think, David?
> >
> > I don't know. It provides more clarity the original Policy question, but 
> > raises
> > a technical one I don't know the answer to. For my special case, is it
> > practical to use systemd (via D-Bus) to manage system daemon
> > start/stop when it is
> > not pid1? If yes, things may have gotten worse (I'm responsible for getting 
> > this
> > all to work correctly?).
>
> Unfortunately, there isn't quite enough context in your reply for me to
> understand exactly how you think this makes things worse for you.  Could
> you expand, please?

I'm going to drop my objection, and assume that this is saying I don't need to
write init scripts for my special case.



Bug#937668: python-crank: diff for NMU version 0.7.2-4.1

2019-10-05 Thread Sandro Tosi
Control: tags 937668 + patch
Control: tags 937668 + pending


Dear maintainer,

I've prepared an NMU for python-crank (versioned as 0.7.2-4.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-crank-0.7.2/debian/changelog python-crank-0.7.2/debian/changelog
--- python-crank-0.7.2/debian/changelog	2019-01-04 11:10:10.0 -0500
+++ python-crank-0.7.2/debian/changelog	2019-10-05 19:16:13.0 -0400
@@ -1,3 +1,10 @@
+python-crank (0.7.2-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937668
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 19:16:13 -0400
+
 python-crank (0.7.2-4) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-crank-0.7.2/debian/control python-crank-0.7.2/debian/control
--- python-crank-0.7.2/debian/control	2019-01-04 11:10:10.0 -0500
+++ python-crank-0.7.2/debian/control	2019-10-05 19:15:29.0 -0400
@@ -8,13 +8,9 @@
  debhelper (>= 10),
  dh-python,
  openstack-pkg-tools (>= 89),
- python-all,
- python-setuptools,
  python3-all,
  python3-setuptools,
 Build-Depends-Indep:
- python-nose,
- python-webob,
  python3-nose,
  python3-webob,
 Standards-Version: 4.3.0
@@ -22,16 +18,6 @@
 Vcs-Git: https://salsa.debian.org/openstack-team/python/python-crank.git
 Homepage: https://github.com/TurboGears/crank
 
-Package: python-crank
-Architecture: all
-Depends:
- ${misc:Depends},
- ${python:Depends},
-Description: dispatch mechanism for use across frameworks - Python 2.7
- Generalized Object based Dispatch mechanism for use across frameworks.
- .
- This package contains the Python 2.7 module.
-
 Package: python3-crank
 Architecture: all
 Depends:
diff -Nru python-crank-0.7.2/debian/rules python-crank-0.7.2/debian/rules
--- python-crank-0.7.2/debian/rules	2019-01-04 11:10:10.0 -0500
+++ python-crank-0.7.2/debian/rules	2019-10-05 19:16:13.0 -0400
@@ -4,19 +4,15 @@
 include /usr/share/openstack-pkg-tools/pkgos.make
 
 %:
-	dh $@ --buildsystem=python_distutils --with python2,python3
-
-override_dh_auto_install:
-	pkgos-dh_auto_install
+	dh $@ --buildsystem=pybuild --with python3
 
 override_dh_auto_test:
 ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
-	nosetests -v
 	set -e ; for pyvers in $(PYTHON3S); do \
 		PYTHON=python$$pyvers nosetests3 -v ; \
 	done
 endif
 
 override_dh_clean:
-	dh_clean -O--buildsystem=python_distutils
+	dh_clean -O--buildsystem=pybuild
 	rm -rf build


Bug#937646: python-ck: diff for NMU version 1.9.4-1.1

2019-10-05 Thread Sandro Tosi
Control: tags 937646 + patch
Control: tags 937646 + pending


Dear maintainer,

I've prepared an NMU for python-ck (versioned as 1.9.4-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-ck-1.9.4/debian/changelog python-ck-1.9.4/debian/changelog
--- python-ck-1.9.4/debian/changelog	2017-11-10 10:01:00.0 -0500
+++ python-ck-1.9.4/debian/changelog	2019-10-05 18:43:49.0 -0400
@@ -1,3 +1,10 @@
+python-ck (1.9.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937646
+
+ -- Sandro Tosi   Sat, 05 Oct 2019 18:43:49 -0400
+
 python-ck (1.9.4-1) unstable; urgency=medium
 
   * many aggregated fixes since 1.7.2
diff -Nru python-ck-1.9.4/debian/control python-ck-1.9.4/debian/control
--- python-ck-1.9.4/debian/control	2017-11-10 10:01:00.0 -0500
+++ python-ck-1.9.4/debian/control	2019-10-05 18:43:32.0 -0400
@@ -4,40 +4,14 @@
 Maintainer: Grigori Fursin 
 Build-Depends: debhelper (>= 9),
dh-python,
-   python-all,
-   python-setuptools,
python3-all,
python3-setuptools
 Standards-Version: 3.9.8
 Homepage: http://github.com/ctuning/ck
 
-Package: python-ck
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Conflicts: python3-ck
-Description: Python2 light-weight knowledge manager
- Collective Knowledge Framework and Repository (CK)
- is a small and portable Python application to organize,
- cross-link, share and reuse research artifacts.
- CK helps decompose complex and hardwired experimental
- workflows into unified and reusable components
- with simple JSON API  and meta-description shared via GitHub
- or any other web service. CK can complement Docker
- and Virtual Machines while helping researchers
- quickly prototype their ideas from shared components
- as LEGO(TM), crowdsource experiments, share knowledge,
- reproduce results and create interactive articles.
- Full documentation and results of GCC/LLVM crowdtuning
- (collaborative program optimization and machine learning)
- are available at https://github.com/ctuning/ck/wiki
- and http://cknowledge.org/repo
- .
- This is the Python 2 version of this package.
-
 Package: python3-ck
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
-Conflicts: python-ck
 Description: Python3 light-weight knowledge manager
  Collective Knowledge Framework and Repository (CK)
  is a small and portable Python application to organize,
diff -Nru python-ck-1.9.4/debian/python-ck.manpages python-ck-1.9.4/debian/python-ck.manpages
--- python-ck-1.9.4/debian/python-ck.manpages	2017-11-10 10:01:00.0 -0500
+++ python-ck-1.9.4/debian/python-ck.manpages	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-man/man1/ck.1
diff -Nru python-ck-1.9.4/debian/rules python-ck-1.9.4/debian/rules
--- python-ck-1.9.4/debian/rules	2017-11-10 10:01:00.0 -0500
+++ python-ck-1.9.4/debian/rules	2019-10-05 18:43:45.0 -0400
@@ -2,4 +2,4 @@
 
 export PYBUILD_NAME=ck
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild


Bug#941822: enchant uninstallable with hunspell (except en-us) because libenchant1c2a depends on nonexistent hunspell-directory

2019-10-05 Thread Ben Caradoc-Davies
Package: enchant
Version: 1.6.0-11.2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

enchant 1.6.0-11.2 is uninstallable with hunspell (except en-us) because
libenchant1c2a depends on a nonexistent hunspell-directory, which should
probably be hunspell-dictionary, as requested in Bug#860888
.

Note the possibly unintended change from hunspell-dictionary to hunspell-
directory when reordering libenchant1c2a dependencies:

- Depends: aspell-en |  myspell-dictionary | aspell-dictionary | ispell-
dictionary | hunspell-dictionary,
+ Depends: hunspell-en-us | hunspell-directory | aspell-dictionary | myspell-
dictionary | ispell-dictionary,

With hunspell-en-gb installed, dist-upgrade on unstable fails with:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libenchant1c2a : Depends: hunspell-en-us but it is not going to be installed
or
   hunspell-directory but it is not installable or
   aspell-dictionary or
   myspell-dictionary or
   ispell-dictionary
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by
held packages.

Kind regards,
Ben.



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

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

Versions of packages enchant depends on:
ii  libc6   2.29-2
ii  libenchant1c2a  1.6.0-11.2
ii  libglib2.0-02.62.0-3

enchant recommends no packages.

enchant suggests no packages.

-- no debconf information



Bug#941782: gir1.2-gnomedesktop-3.0 3.34.0-2 breaks gnome-shell

2019-10-05 Thread Mike Miller
Package: gir1.2-gnomedesktop-3.0
Version: 3.34.0-2
Followup-For: Bug #941782

Affected by this today, gnome-shell is completely non-functional with
the version of gir1.2-gnomedesktop-3.0 now in testing. Confirm that
installing the stable version of the package (3.30.2.1-2) restores it.

-- 
mike



Bug#941821: RM: libgnome-keyring -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: libgnome-keyr...@packages.debian.org
Affects: src:libgnome-keyring
Control: block -1 by 941812

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing a year
and a half ago. Please remove libgnome-keyring from Debian now.

Testing removal bug: https://bugs.debian.org/892539

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941817: llvm-toolchain-8: FTBFS on x32

2019-10-05 Thread Thorsten Glaser
> I’m attaching the patch and am currently building it locally to
> see whether this was all or whether more is needed.

It failed very early with…

[…]
-- Builtin supported architectures:
-- Linker detection: GNU ld
-- Linker detection: GNU ld
-- Builtin supported architectures:
-- check-shadowcallstack does nothing.
-- Sphinx enabled.
-- Found Sphinx: /usr/bin/sphinx-build
-- ISL version: isl-0.20-65-gb822a210
-- Performing Test HAS_ATTRIBUTE_WARN_UNUSED_RESULT
-- Performing Test HAS_ATTRIBUTE_WARN_UNUSED_RESULT - Failed
-- Performing Test HAVE___ATTRIBUTE__
-- Performing Test HAVE___ATTRIBUTE__ - Failed
-- Performing Test HAVE_DECL_FFS
-- Performing Test HAVE_DECL_FFS - Failed
-- Performing Test HAVE_DECL___BUILTIN_FFS
-- Performing Test HAVE_DECL___BUILTIN_FFS - Failed
-- Performing Test HAVE_DECL__BITSCANFORWARD
-- Performing Test HAVE_DECL__BITSCANFORWARD - Failed
CMake Error at tools/polly/lib/External/CMakeLists.txt:91 (message):
  No ffs implementation found

… which is caused by:

cc1: error: unrecognized argument to '-flto=' option: 'thin'

Somehow, the build system applies -flto=thin to the host compiler,
and GCC doesn’t support this flag.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Bug#941811: please convert package to use dh-elpa for perlcritic.el

2019-10-05 Thread Salvatore Bonaccorso
hi Nicholas,

On Sat, Oct 05, 2019 at 05:42:36PM -0400, Nicholas D Steeves wrote:
> Package: libperl-critic-perl
> Version: 1.132-1
> Severity: normal
> 
> Dear maintainer,
> 
> I've confirmed this affects 1.134-1.  Please convert
> libperl-critic-perl to use dh-elpa for perlcritic.el.  It handles byte
> compilation which the package in buster lacks.
> 
> It looks like emacsen-startup is Debian-specific customisation.
> That
> will go in the debian-autoloads.el file.  See § "Debian-specific
> Lisp customizations" (man dh_elpa).

it looks we did that back in

libperl-critic-perl (1.092-1) unstable; urgency=low
[...]
  * install perlcritic.el into site-lisp, add debian/emacsen-startup
adds perlcritic mode to Emacs. Thanks to Kevin Ryde for the suggestion and
the patch. Closes: #483288

Would you be open to help providing this conversion?

Regards,
Salvatore



Bug#941782: Could you suggest a detailed rescue plan ?

2019-10-05 Thread Emmanuel Charpentier
I have been bitten by this one. Severely : one of my systems won't get
to the Gnome login screen and stays on a black screen (with an (active)
mouse pointer).

  * apt-get -t stable gir1.2-gnomedesktop-3.0 gnome-desktop3-data \
libgnome-desktop-3-17
won't do a thing. ditto with --allow-downgrades.

  * apt-get remove gir1.2-gnomedesktop-3.0 gnome-desktop3-data \
libgnome-desktop-3-17
wants to remove a lot of gnome and gnome-related packages.

  * I *suppose* that "the right use" of dpkg would allow this kind of
surgery in the dependency system, allowing to replace a package by its
predecessor while temporarily ignoring the dependencies. But I do not
understand it well enough to divine the "right" set of operations.

Since this happened during a routine update of testing, I suppose I am
not alone to have to endure the consequences of an inadvertently
missing dependency, and that this plan would be useful to a lot of
people.

Thanks in advance !

--
Emmanuel Charpentier



Bug#941820: RM: gnome-vfs -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: gnome-...@packages.debian.org
Affects: src:gnome-vfs
Control: block -1 by 941818

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing a year
and a half ago. Please remove gnome-vfs from Debian now.

Testing removal bug: https://bugs.debian.org/893922

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941688: marked as done (openssl 1.1.1d security update breaks openssh login on old kernels)

2019-10-05 Thread Colin Watson
On Sat, Oct 05, 2019 at 10:58:18PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-10-05 21:34:22 [+0200], Salvatore Bonaccorso wrote:
> > Or maybe it would be worth as an option to reassign to src:openssh an
> > for such cases as for the reporter (if Colin is open to it obviously)
> > to have it backported for a point release update?
> 
> Could you please take look at
>   https://bugs.debian.org/941688
> 
> and say what you think about backporting it for stable as Salvatore
> suggested?

Hi,

Looks like we raced on this - I'm already tracking this in
https://bugs.debian.org/941663, and I just filed
https://bugs.debian.org/941810 with a stable update request.  Could you
please follow up on the latter if you have views on where the update
should go?

> It affects people with a pre-v3.19 kernel running Buster. I could do
> some testing if you want me to.

That would be useful, thanks.

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



Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object

2019-10-05 Thread Evgeny Kapun

[15:37:17] Cannot convert undefined or null to object


After checking the code, I found the root cause of this error.
The error is caused by NPM package now-and-later, which is included in Debian 
package gulp version 4.0.2-2. The version included is 1.0.0. It should be 
upgraded to at least version 2.0.0. Gulp will not work with version 1.0.0 due 
to incompatible API change.
After replacing the package with version 2.0.1 downloaded from NPM, the error 
disappears.
Also, perhaps all those packages bundled with gulp should be in separate Debian 
packages instead.



Bug#941819: RM: orbit2 -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: orb...@packages.debian.org
Affects: src:orbit2
Control: block -1 by 941818

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing more than
a year ago. Please remove orbit2 from Debian now.

Testing removal bug: https://bugs.debian.org/890459

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941818: RM: libgnome -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: libgn...@packages.debian.org
Affects: src:libgnome
Control: block -1 by 941815

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing a year
and a half ago. Please remove libgnome from Debian now.

Testing removal bug: https://bugs.debian.org/885768

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941817: llvm-toolchain-8: FTBFS on x32

2019-10-05 Thread Thorsten Glaser
Source: llvm-toolchain-8
Version: 1:8.0.1-3
Severity: important
Tags: ftbfs
Justification: fails to build from source, but built in the past, on d-ports 
arch


One of the build errors is caused by you dropping a patch that,
according to d/changelog in llvm-toolchain-8, was pertinent in
both llvm-toolchain-7 (which DID at one time build) and -snapshot.

I’m attaching the patch and am currently building it locally to
see whether this was all or whether more is needed. The patch only
needed minor updating.

This almost certainly also applies to llvm-toolchain-9, do you
prefer a separate bugreport there?
diff -Nru llvm-toolchain-8-8.0.1/debian/changelog 
llvm-toolchain-8-8.0.1/debian/changelog
--- llvm-toolchain-8-8.0.1/debian/changelog 2019-08-07 15:11:36.0 
+0200
+++ llvm-toolchain-8-8.0.1/debian/changelog 2019-10-05 23:48:41.0 
+0200
@@ -1,3 +1,10 @@
+llvm-toolchain-8 (1:8.0.1-3+x32.1) unreleased; urgency=high
+
+  * Non-maintainer upload.
+  * Add back cbmuser’s patch to fix include and library paths on x32
+
+ -- Thorsten Glaser   Sat, 05 Oct 2019 23:48:41 +0200
+
 llvm-toolchain-8 (1:8.0.1-3) unstable; urgency=medium
 
   * llvm-tools: depend on python2 packages too, the move to python3 was
diff -Nru llvm-toolchain-8-8.0.1/debian/patches/series 
llvm-toolchain-8-8.0.1/debian/patches/series
--- llvm-toolchain-8-8.0.1/debian/patches/series2019-08-06 
09:36:11.0 +0200
+++ llvm-toolchain-8-8.0.1/debian/patches/series2019-10-05 
23:46:48.0 +0200
@@ -138,3 +138,6 @@
 
 # Python 3
 0050-Remove-explicit-python-version-list.patch
+
+# porting
+x32-fix-driver-search-paths.diff
diff -Nru 
llvm-toolchain-8-8.0.1/debian/patches/x32-fix-driver-search-paths.diff 
llvm-toolchain-8-8.0.1/debian/patches/x32-fix-driver-search-paths.diff
--- llvm-toolchain-8-8.0.1/debian/patches/x32-fix-driver-search-paths.diff  
1970-01-01 01:00:00.0 +0100
+++ llvm-toolchain-8-8.0.1/debian/patches/x32-fix-driver-search-paths.diff  
2019-10-05 23:48:22.0 +0200
@@ -0,0 +1,80 @@
+Description: Fix missing include and library paths on x32
+Author: John Paul Adrian Glaubitz 
+Forwarded: https://reviews.llvm.org/D52050
+Last-Update: 2019-10-05
+
+--- a/clang/lib/Driver/ToolChains/Gnu.cpp
 b/clang/lib/Driver/ToolChains/Gnu.cpp
+@@ -1916,7 +1916,10 @@ void Generic_GCC::GCCInstallationDetecto
+   "x86_64-slackware-linux", "x86_64-unknown-linux",
+   "x86_64-amazon-linux","x86_64-linux-android",
+   "x86_64-kfreebsd-gnu","x86_64-pc-kfreebsd-gnu"};
+-  static const char *const X32LibDirs[] = {"/libx32"};
++  static const char *const X32LibDirs[] = {"/libx32", "/lib"};
++  static const char *const X32Triples[] = {
++  "x86_64-linux-gnux32","x86_64-unknown-linux-gnux32",
++  "x86_64-pc-linux-gnux32"};
+   static const char *const X86LibDirs[] = {"/lib32", "/lib"};
+   static const char *const X86Triples[] = {
+   "i686-linux-gnu",   "i686-pc-linux-gnu", "i486-linux-gnu",
+@@ -2127,14 +2130,16 @@ void Generic_GCC::GCCInstallationDetecto
+ }
+ break;
+   case llvm::Triple::x86_64:
+-LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
+-TripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+ // x32 is always available when x86_64 is available, so adding it as
+ // secondary arch with x86_64 triples
+ if (TargetTriple.getEnvironment() == llvm::Triple::GNUX32) {
+-  BiarchLibDirs.append(begin(X32LibDirs), end(X32LibDirs));
++  LibDirs.append(begin(X32LibDirs), end(X32LibDirs));
++  TripleAliases.append(begin(X32Triples), end(X32Triples));
++  BiarchLibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
+   BiarchTripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+ } else {
++  LibDirs.append(begin(X86_64LibDirs), end(X86_64LibDirs));
++  TripleAliases.append(begin(X86_64Triples), end(X86_64Triples));
+   BiarchLibDirs.append(begin(X86LibDirs), end(X86LibDirs));
+   BiarchTripleAliases.append(begin(X86Triples), end(X86Triples));
+ }
+--- a/clang/lib/Driver/ToolChains/Linux.cpp
 b/clang/lib/Driver/ToolChains/Linux.cpp
+@@ -88,10 +88,13 @@ static std::string getMultiarchTriple(co
+   case llvm::Triple::x86_64:
+ if (IsAndroid)
+   return "x86_64-linux-android";
+-// We don't want this for x32, otherwise it will match x86_64 libs
+-if (TargetEnvironment != llvm::Triple::GNUX32 &&
+-D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
+-  return "x86_64-linux-gnu";
++if (TargetEnvironment == llvm::Triple::GNUX32) {
++  if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnux32"))
++return "x86_64-linux-gnux32";
++} else {
++  if (D.getVFS().exists(SysRoot + "/lib/x86_64-linux-gnu"))
++return "x86_64-linux-gnu";
++}
+ break;
+   case llvm::Triple::aarch64:
+ if (IsAndroid)
+@@ -702,6 +705,8 @@ void Linux::AddClangSystemIncludeArgs(co
+   // in use in any 

Bug#941816: [rst-mode] Use "sensible-browser" and not hard-coded firefox to preview slides

2019-10-05 Thread Nicholas D Steeves
Package: emacs
Version: 1:26.1+1-3.2+deb10u1
Severity: normal
Tags: patch

Hi Rob,

While decrufting my config and benchmarking my init I found some
old-style Emacs package.  python-docutils-common ships an obsolete
copy of rst.el, which I'm in the process of filing a MR to remove.

That said, they have a nice, simple patch that we should adopt; I've
attached it.  There may be other places where Emacs could be better
integrated into a Debian system.  See patch for details.


Cheers,
Nicholas
From: Jakub Wilk 
Date: Thu, 8 Oct 2015 11:57:04 -0700
Subject: Use "sensible-browser" to preview slides

Use 'sensible-browser' (rather than 'firefox') as a program to preview
S5 slides.

Forwarded: not-needed
Last-Update: 2011-08-21
---
 tools/editors/emacs/rst.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/editors/emacs/rst.el b/tools/editors/emacs/rst.el
index c5ef7a0..0d83971 100644
--- a/tools/editors/emacs/rst.el
+++ b/tools/editors/emacs/rst.el
@@ -4457,7 +4457,7 @@ buffer, if the region is not selected."
 
 ;; FIXME: Should be integrated in `rst-compile-toolsets' defaulting to
 ;;something like `browse-url'.
-(defvar rst-slides-program "firefox"
+(defvar rst-slides-program "sensible-browser"
   "Program used to preview S5 slides.")
 
 (defun rst-compile-slides-preview ()


Bug#941815: RM: libbonobo -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: libbon...@packages.debian.org
Affects: src:libbonobo
Control: block -1 by 941813

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing a year
and a half ago. Please remove libbonobo from Debian now.

Testing removal bug: https://bugs.debian.org/885770

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941813: RM: libbonoboui -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: libbonob...@packages.debian.org
Affects: src:libbonoboui
Control: block -1 by 941812

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing a year
and a half ago. Please remove libbonoboui from Debian now.

Testing removal bug: https://bugs.debian.org/885769

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941814: libpopt: leaks memory for leftover arguments

2019-10-05 Thread Christian Göttsche
Package: libpopt0
Version: 1.16-12
Severity: important
Affects: logrotate
Tags: patch

The patch 318833-incorrect-handling-of-leftovers-with-poptStuffArgs.patch
introduces a memory leak for leftover arguments.

Previously the content of 'con->leftovers' did not hold own memory, so
it did not need to be freed.
With that patch it does, but it is not cleaned properly.
First there is a typo in line 57 (extra '&'), so the content would
never be freed.
Secondly in 'poptFreeContext()' 'poptResetContext()' is called, which
sets 'con->numLeftovers' to 0.
So the whole loop (line 56-58 in the patch) is not executed.


poptleak.sh
Description: application/shellscript
diff -Nru ../popt_orig/popt-1.16/popt.c ../popt/popt-1.16/popt.c
--- ../popt_orig/popt-1.16/popt.c	2019-10-05 23:40:23.0 +0200
+++ ../popt/popt-1.16/popt.c	2019-10-05 23:44:07.784682313 +0200
@@ -234,6 +234,9 @@
 con->os->nextArg = _free(con->os->nextArg);
 con->os->next = 1;			/* skip argv[0] */
 
+for (i = 0; i < con->numLeftovers; i++) {
+	con->leftovers[i] = _free(con->leftovers[i]);
+}
 con->numLeftovers = 0;
 con->nextLeftover = 0;
 con->restLeftover = 0;
@@ -1651,7 +1654,7 @@
 con->numExecs = 0;
 
 for (i = 0; i < con->numLeftovers; i++) {
-	con->leftovers[i] = _free(>leftovers[i]);
+	con->leftovers[i] = _free(con->leftovers[i]);
 }
 con->leftovers = _free(con->leftovers);
 


Bug#941812: RM: libgnomeui -- RoM; unmaintained GNOME 2 library

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: libgnom...@packages.debian.org
Affects: src:libgnomeui
Control: block -1 by 941809

The libgnome collection of libraries have been unmaintained since
GNOME 3 was released in 2011. They were removed from Testing a year
and a half ago. Please remove libgnomeui from Debian now.

Testing removal bug: https://bugs.debian.org/885767

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#941688: marked as done (openssl 1.1.1d security update breaks openssh login on old kernels)

2019-10-05 Thread Sebastian Andrzej Siewior
On 2019-10-05 21:34:22 [+0200], Salvatore Bonaccorso wrote:
> Hi, Sebastian,
Hi Colin,

> > On 2019-10-05 18:00:02 [+0200], Sylvain Rochet wrote:
> > > Indeed, you are right, this issue is now fixed upstream in openssh.
> > > https://github.com/openssh/openssh-portable/pull/149
> > 
> > in that I'm closing this.
> 
> Or maybe it would be worth as an option to reassign to src:openssh an
> for such cases as for the reporter (if Colin is open to it obviously)
> to have it backported for a point release update?

Could you please take look at
https://bugs.debian.org/941688

and say what you think about backporting it for stable as Salvatore
suggested? The openssh commit is

https://github.com/openssh/openssh-portable/commit/3ef92a657444f172b61f92d5da66d94fa8265602
as far as I can tell.

It affects people with a pre-v3.19 kernel running Buster. I could do
some testing if you want me to.

> Regards,
> Salvatore

Sebastian



Bug#941811: please convert package to use dh-elpa for perlcritic.el

2019-10-05 Thread Nicholas D Steeves
Package: libperl-critic-perl
Version: 1.132-1
Severity: normal

Dear maintainer,

I've confirmed this affects 1.134-1.  Please convert
libperl-critic-perl to use dh-elpa for perlcritic.el.  It handles byte
compilation which the package in buster lacks.

It looks like emacsen-startup is Debian-specific customisation.  That
will go in the debian-autoloads.el file.  See § "Debian-specific Lisp 
customizations" (man dh_elpa).


Regards,
Nicholas


Bug#941810: buster-pu: package openssh/1:7.9p1-10

2019-10-05 Thread Colin Watson
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

https://bugs.debian.org/941663 reports an OpenSSH regression on old
kernels prompted by the interaction between an OpenSSL update and a
seccomp filter; https://bugs.debian.org/941665 and
https://github.com/openssh/openssh-portable/pull/149 have more details.
The patch is an easy one to cherry-pick, and I've attached the resulting
diff.  I'd like approval to upload it.

I'm not sure where's best to upload this to.  Although I've filed this
as a stable update request, there's an argument that perhaps it should
be issued through the same channels as the OpenSSL update
(stable-security and then copied to stable-proposed-updates, according
to https://tracker.debian.org/pkg/openssl), so I've CCed team@security.
Any advice?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
diff --git a/debian/.git-dpm b/debian/.git-dpm
index 65e73673d..60a2fe1b6 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-6b56cd57db9061296231f14d537f1ebaf25e8877
-6b56cd57db9061296231f14d537f1ebaf25e8877
+35956d8211ef0a606a117ca3f0ba3ae163c31a39
+35956d8211ef0a606a117ca3f0ba3ae163c31a39
 3d246f10429fc9a37b98eabef94fe8dc7c61002b
 3d246f10429fc9a37b98eabef94fe8dc7c61002b
 openssh_7.9p1.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index 8b18f3506..3456413eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+openssh (1:7.9p1-10+deb10u1) UNRELEASED; urgency=medium
+
+  * Apply upstream patch to deny (non-fatally) shmget/shmat/shmdt in preauth
+privsep child, coping with changes in OpenSSL 1.1.1d that broke OpenSSH
+on Linux kernels before 3.19 (closes: #941663).
+
+ -- Colin Watson   Sat, 05 Oct 2019 22:32:31 +0100
+
 openssh (1:7.9p1-10) unstable; urgency=medium
 
   * Temporarily revert IPQoS defaults to pre-7.8 values until issues with
diff --git a/debian/patches/seccomp-handle-shm.patch 
b/debian/patches/seccomp-handle-shm.patch
new file mode 100644
index 0..56bc9414e
--- /dev/null
+++ b/debian/patches/seccomp-handle-shm.patch
@@ -0,0 +1,38 @@
+From 35956d8211ef0a606a117ca3f0ba3ae163c31a39 Mon Sep 17 00:00:00 2001
+From: Lonnie Abelbeck 
+Date: Tue, 1 Oct 2019 09:05:09 -0500
+Subject: Deny (non-fatal) shmget/shmat/shmdt in preauth privsep child.
+
+New wait_random_seeded() function on OpenSSL 1.1.1d uses shmget, shmat, and 
shmdt
+in the preauth codepath, deny (non-fatal) in seccomp_filter sandbox.
+
+Bug: https://github.com/openssh/openssh-portable/pull/149
+Bug-Debian: https://bugs.debian.org/941663
+Origin: upstream, 
https://anongit.mindrot.org/openssh.git/commit/?id=3ef92a657444f172b61f92d5da66d94fa8265602
+Last-Update: 2019-10-05
+
+Patch-Name: seccomp-handle-shm.patch
+---
+ sandbox-seccomp-filter.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
+index ef4de8c65..e8f31555e 100644
+--- a/sandbox-seccomp-filter.c
 b/sandbox-seccomp-filter.c
+@@ -149,6 +149,15 @@ static const struct sock_filter preauth_insns[] = {
+ #ifdef __NR_stat64
+   SC_DENY(__NR_stat64, EACCES),
+ #endif
++#ifdef __NR_shmget
++  SC_DENY(__NR_shmget, EACCES),
++#endif
++#ifdef __NR_shmat
++  SC_DENY(__NR_shmat, EACCES),
++#endif
++#ifdef __NR_shmdt
++  SC_DENY(__NR_shmdt, EACCES),
++#endif
+ 
+   /* Syscalls to permit */
+ #ifdef __NR_brk
diff --git a/debian/patches/series b/debian/patches/series
index b0da97283..36d464989 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -32,3 +32,4 @@ fix-key-type-check.patch
 request-rsa-sha2-cert-signatures.patch
 scp-handle-braces.patch
 revert-ipqos-defaults.patch
+seccomp-handle-shm.patch
diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index ef4de8c65..e8f31555e 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -149,6 +149,15 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_stat64
SC_DENY(__NR_stat64, EACCES),
 #endif
+#ifdef __NR_shmget
+   SC_DENY(__NR_shmget, EACCES),
+#endif
+#ifdef __NR_shmat
+   SC_DENY(__NR_shmat, EACCES),
+#endif
+#ifdef __NR_shmdt
+   SC_DENY(__NR_shmdt, EACCES),
+#endif
 
/* Syscalls to permit */
 #ifdef __NR_brk


Bug#941663: openssh-server: fatal: privsep_preauth: preauth child terminated by signal 31

2019-10-05 Thread Colin Watson
On Sat, Oct 05, 2019 at 08:21:09PM +0100, Adam D. Barratt wrote:
> On Sat, 2019-10-05 at 12:16 -0400, James Cloos wrote:
> > Using ed25519 keys (host and client) should work around this issue.
> 
> FWIW according to #941665, this should also only affect users running
> buster on kernels < 3.19.

Thanks for the clue.  I'll cherry-pick this into unstable now, and I've
also filed a stable update request.

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



Bug#941809: RM: linsmith -- RoQA; depends on unmaintained libgnome

2019-10-05 Thread Jeremy Bicha
Package: ftp.debian.org
X-Debbugs-Cc: linsm...@packages.debian.org
Affects: src:linsmith

linsmith is the last thing keeping the unmaintained libgnome in
Debian. linsmith was removed from Testing in early 2018. It's now time
to finish libgnome's removal from Debian. Therefore, please remove
linsmith from Debian.

See https://bugs.debian.org/885742

On behalf of the Debian GNOME team,
Jeremy Bicha



Bug#758094: libgl1-mesa-glx:x32: SIGSEGV in OpenGL applications on x32

2019-10-05 Thread Thorsten Glaser
Hi Sven,

>That has apparently helped, but I have just re-enabled asm in git[1],
>since the bug is supposed to be fixed since Mesa 17.0.0.
>
>@Thorsten: would be great if you could test that this actually works.

sure, thanks for informing me. Upgrading was a bit of a hassle due to
Multi-Arch but I’ve managed to persuade apt and dpkg ☻

It built fine (log attached) and works in xrdp (I’m currently at home
and could test only remotely).

In xrdp+xorgxrdp, glxgears’ performance shrinks from ~280 fps with
mesa 18.3.6-2 to ~275 fps with git master. That’s less than 2% and
probably partially due to the major version bump so I’d not count
it as a loss.

I can test this on the native nouveau hardware on Monday.

bye,
//mirabilos

PS: Do check the build log, especially lintian at the end… ☻☺
-- 
 den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │  damals, als der pizzateig noch auf dem monior "gegangen" ist

mesa_19.2.0-2_x32.build.xz
Description: Binary data


Bug#941768: open-vm-tools/10.3.10 does not compile with 4.19.0-6-amd64 on buster kernel upgrade

2019-10-05 Thread hjenkins

*Thank you, Bernd. Fixed. For the record, I did this:

$ su
Password:

# dpkg -P open-vm-tools-dkms
dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and 
/sbin


# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

*Per 
https://linuxconfig.org/command-not-found-missing-path-to-sbin-on-debian-gnu-linux


$ su -
Password:
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# dpkg -P open-vm-tools-dkms
(Reading database ... 318080 files and directories currently installed.)
Removing open-vm-tools-dkms (2:10.1.5-5055683-4+deb9u1) ...

 Uninstall Beginning 
Module: open-vm-tools
Version: 10.1.5
Kernel: 4.9.0-8-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

vmxnet.ko:
- Uninstallation
- Deleting from: /lib/modules/4.9.0-8-amd64/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

depmod...

DKMS: uninstall completed.

--
Deleting module version: 10.1.5
completely from the DKMS tree.
--
Done.
update-initramfs: deferring update (trigger activated)
Purging configuration files for open-vm-tools-dkms 
(2:10.1.5-5055683-4+deb9u1) ...

Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-6-amd64
W: Possible missing firmware /lib/firmware/i915/bxt_dmc_ver1_07.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_27.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_04.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/cnl_dmc_ver1_07.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/glk_dmc_ver1_04.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_39.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver9_29.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_ver9_33.bin for 
module i915
W: Possible missing firmware 
/lib/firmware/i915/kbl_huc_ver02_00_1810.bin for module i915
W: Possible missing firmware 
/lib/firmware/i915/bxt_huc_ver01_07_1398.bin for module i915
W: Possible missing firmware 
/lib/firmware/i915/skl_huc_ver01_07_1398.bin for module i915


*Returning myself to the standard root path:
$ su
Password:

# apt-get install --reinstall linux-headers-4.19.0-6-amd64 
linux-headers-4.19.0-6-common linux-image-4.19.0-6-amd64

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  irqbalance linux-compiler-gcc-6-x86 linux-headers-4.9.0-8-amd64 
linux-headers-4.9.0-8-common linux-image-4.9.0-8-amd64 linux-kbuild-4.9

  runit-helper
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 3 reinstalled, 0 to remove and 0 not 
upgraded.

Need to get 0 B/57.0 MB of archives.
After this operation, 0 B of additional disk space will be used.
N: Ignoring file 'testing.list.old' in directory 
'/etc/apt/sources.list.d/' as it has an invalid filename extension
N: Ignoring file 'unstable.list.old' in directory 
'/etc/apt/sources.list.d/' as it has an invalid filename extension

(Reading database ... 317359 files and directories currently installed.)
Preparing to unpack 
.../linux-headers-4.19.0-6-amd64_4.19.67-2+deb10u1_amd64.deb ...
Unpacking linux-headers-4.19.0-6-amd64 (4.19.67-2+deb10u1) over 
(4.19.67-2+deb10u1) ...
Preparing to unpack 
.../linux-headers-4.19.0-6-common_4.19.67-2+deb10u1_all.deb ...
Unpacking linux-headers-4.19.0-6-common (4.19.67-2+deb10u1) over 
(4.19.67-2+deb10u1) ...
Preparing to unpack 
.../linux-image-4.19.0-6-amd64_4.19.67-2+deb10u1_amd64.deb ...
Unpacking linux-image-4.19.0-6-amd64 (4.19.67-2+deb10u1) over 
(4.19.67-2+deb10u1) ...

Setting up linux-image-4.19.0-6-amd64 (4.19.67-2+deb10u1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-6-amd64
W: Possible missing firmware /lib/firmware/i915/bxt_dmc_ver1_07.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_27.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_04.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/cnl_dmc_ver1_07.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/glk_dmc_ver1_04.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_39.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver9_29.bin for 
module i915
W: Possible missing firmware 

Bug#941808: java-package: depends on transitional libgl1-mesa-glx

2019-10-05 Thread Thorsten Glaser
Package: java-package
Version: 0.62
Severity: important

libgl1-mesa-glx is a transitional dummy package for
Depends: libgl1, libglx-mesa0
and could be safely uninstalled except java-package
Depends on it.

Please change the dependency to the depended-on packages.

(While there you could move the Suggests on from Java… 7…)

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages java-package depends on:
ii  build-essential  12.8
ii  debhelper12.6.1
ii  dpkg-dev 1.19.7
ii  fakeroot 1.24-1
ii  libasound2   1.1.8-1+x32.1
ii  libfontconfig1   2.13.1-2+b1
ii  libgl1-mesa-glx  19.2.0-2
ii  libgtk2.0-0  2.24.32-4
ii  libx11-6 2:1.6.8-1
ii  libxslt1.1   1.1.32-2.1
ii  libxtst6 2:1.2.3-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  unzip6.0-25

java-package recommends no packages.

Versions of packages java-package suggests:
pn  openjdk-7-jre  

-- no debconf information


Bug#941807: r-cran-recipes: autopktest depends on r-cran-rsample which doesn't exist

2019-10-05 Thread Paul Gevers
Source: r-cran-recipes
Version: 0.1.7-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of r-cran-recipes the autopkgtest of r-cran-recipes
fails in testing when that autopkgtest is run with the binary packages
of r-cran-recipes from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
r-cran-recipes from testing0.1.7-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. As you can
see, the autopkgtest of r-cran-recipes depends on r-cran-rsample, which
doesn't exist in Debian.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=r-cran-recipes

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-recipes/3080108/log.gz

E: Unable to locate package r-cran-rsample



signature.asc
Description: OpenPGP digital signature


Bug#935753: Bug reported upstream

2019-10-05 Thread Sven Joachim
Control: tags -1 - moreinfo
Control: tags -1 + fixed-upstream patch
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/issues/1860

This has been reported and fixed upstream, patch from [1] attached here.

Cheers,
   Sven

1. 
https://gitlab.freedesktop.org/mesa/mesa/commit/1c6fdbc83cf1094c735b964902da421978005cb3

From 1c6fdbc83cf1094c735b964902da421978005cb3 Mon Sep 17 00:00:00 2001
From: Lionel Landwerlin 
Date: Wed, 2 Oct 2019 17:13:06 +0300
Subject: [PATCH 1/1] intel: fix topology query

i915 will report ENODEV on generations prior to Haswell because there
is no point in reporting values on those. This is prior any fusing
could happen on parts with identical PCI ids.

This query call was previously only triggered on generations that
support performance queries, which happens to match generation for
which i915 reports topology, but the commit pointed below started
using it on all generations.

Signed-off-by: Lionel Landwerlin 
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/1860
Cc: 
Fixes: 96e1c945f2 ("i965: Move device info initialization to common code")
Reviewed-by: Mark Janes 
---
 src/intel/dev/gen_device_info.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 3953a1f4af3..85fa978f9c1 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -1320,6 +1320,9 @@ query_topology(struct gen_device_info *devinfo, int fd)
if (gen_ioctl(fd, DRM_IOCTL_I915_QUERY, ))
   return false;

+   if (item.length < 0)
+  return false;
+
struct drm_i915_query_topology_info *topo_info =
   (struct drm_i915_query_topology_info *) calloc(1, item.length);
item.data_ptr = (uintptr_t) topo_info;
--
2.23.0



Bug#941806: calibre: No Bookviewer, No Edit metadata

2019-10-05 Thread Droszler Gabor
Package: calibre
Version: 4.0.0+dfsg-1
Severity: important

Dear Maintainer,

I cannot read a book on Calibre 4.0 at all. I double click the book, click the
View icon, right click to the fast menu but it won't start. Along with this I
am not able to use,

Traceback (most recent call last):
  File "/usr/bin/calibre-parallel", line 20, in 
sys.exit(main())
  File "/usr/lib/calibre/calibre/utils/ipc/worker.py", line 208, in main
result = func(*args, **kwargs)
  File "/usr/lib/calibre/calibre/gui_launch.py", line 80, in ebook_viewer
from calibre.gui2.viewer.main import main
  File "/usr/lib/calibre/calibre/gui2/viewer/main.py", line 12, in 
from PyQt5.QtWebEngineCore import QWebEngineUrlScheme
ImportError: No module named QtWebEngineCore


Edit metadata or Convert a book. I this error when I try to do either

calibre 4.0  embedded-python: False is64bit: True
Linux-5.2.0-3-amd64-x86_64-with-debian-bullseye-sid Linux ('64bit', 'ELF')
('Linux', '5.2.0-3-amd64', '#1 SMP Debian 5.2.17-1 (2019-09-26)')
Python 2.7.16+
Linux: ('debian', 'bullseye/sid', '')
Interface language: hu
Successfully initialized third party plugins: Libri_hu (1, 0, 6) && Moly_hu (1,
0, 4) && Antikvarium_hu (1, 0, 1)
Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/actions/convert.py", line 161, in
convert_ebook
self.do_convert(book_ids, bulk=bulk)
  File "/usr/lib/calibre/calibre/gui2/actions/convert.py", line 178, in
do_convert
self.gui.library_view.model().db, book_ids,
out_format=prefs['output_format'])
  File "/usr/lib/calibre/calibre/gui2/tools.py", line 44, in
convert_single_ebook
d = SingleConfig(parent, db, book_id, None, out_format)
  File "/usr/lib/calibre/calibre/gui2/convert/single.py", line 82, in __init__
self.setup_pipeline()
  File "/usr/lib/calibre/calibre/gui2/convert/single.py", line 231, in
setup_pipeline
self.mw = widget_factory(MetadataWidget)
  File "/usr/lib/calibre/calibre/gui2/convert/single.py", line 229, in
widget_factory
self.plumber.get_option_help, self.db, self.book_id)
  File "/usr/lib/calibre/calibre/gui2/convert/metadata.py", line 60, in
__init__
Widget.__init__(self, parent, OPTIONS['pipe']['metadata'])
  File "/usr/lib/calibre/calibre/gui2/convert/__init__.py", line 67, in
__init__
self.setupUi(self)
  File "/usr/lib/calibre/calibre/gui2/convert/metadata_ui.py", line 130, in
setupUi
self.comment = Editor(Form)
  File "/usr/lib/calibre/calibre/gui2/comments_editor.py", line 1018, in
__init__
self.editor = EditorWidget(self)
  File "/usr/lib/calibre/calibre/gui2/comments_editor.py", line 320, in
__init__
self.update_cursor_position_actions()
  File "/usr/lib/calibre/calibre/gui2/comments_editor.py", line 348, in
update_cursor_position_actions
lvl = bf.headingLevel()
AttributeError: 'QTextBlockFormat' object has no attribute 'headingLevel'



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

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

Versions of packages calibre depends on:
ii  calibre-bin  4.0.0+dfsg-1
ii  fonts-liberation 1:1.07.4-10
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b1
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python-apsw  3.28.0-r1-1
ii  python-bs4   4.8.0-2
ii  python-chardet   3.0.4-4
ii  python-cherrypy3 8.9.1-2
ii  python-css-parser1.0.4-1
ii  python-cssselect 1.1.0-1
ii  python-cssutils  1.0.2-2
ii  python-dateutil  2.7.3-3
ii  python-dbus  1.2.12-1
ii  python-feedparser5.2.1-1
ii  python-html2text 2019.8.11-1
ii  python-html5-parser  0.4.8-1
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.4.1-1
ii  python-markdown  3.1.1-2
ii  python-mechanize 1:0.4.3-2
ii  python-msgpack   0.5.6-1+b1
ii  python-netifaces 0.10.4-1+b1
ii  python-pil   6.1.0-1
ii  python-pkg-resources 41.2.0-1
ii  python-pyparsing 2.4.2-1
ii  python-pyqt5 5.12.3+dfsg-2
ii  python-pyqt5.qtsvg   5.12.3+dfsg-2
ii  python-pyqt5.qtwebkit5.12.3+dfsg-2
ii  

Bug#399028: developers-reference: best practices to create and delete system accounts

2019-10-05 Thread Holger Levsen
Hi Marc,

On Fri, Nov 17, 2006 at 09:41:48AM +0100, Marc Haber wrote:
> The information collected in
> http://wiki.debian.org/AccountHandlingInMaintainerScripts should
> eventually be put into the developer's reference, chapter 6.5.
 
would you suggest to remove all of that from this wiki page and then add
a pointer to developers-reference or what would you suggest today?

A suggestion where exactly to add this in the developers-reference would
also be welcome, btw.


-- 
cheers,
Holger

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



signature.asc
Description: PGP signature


Bug#941805: hmmer: autopkgtest regression: hmmpgmd_ga] ... FAILED [crash!]

2019-10-05 Thread Paul Gevers
Source: hmmer
Version: 3.2.1+dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of hmmer the autopkgtest of hmmer fails in testing
when that autopkgtest is run with the binary packages of hmmer from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
hmmer  from testing3.2.1+dfsg-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=hmmer

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hmmer/3078564/log.gz

exercise  292 [   hmmpgmd_ga] ... FAILED [crash!]
exercise  293 [   rewind] ... ok.
exercise  294 [  brute-itest] ... ok.
exercise  295 [   hmmpress-itest] ... ok.
exercise  296 [  h39] ... ok.
exercise  297 [  h45] ... ok.
exercise  298 [  h50] ... ok.
exercise  299 [  h82] ... ok.

1 of 299 exercises at level <= 2 FAILED.



signature.asc
Description: OpenPGP digital signature


Bug#941803: debian-policy: dependencies on font packages

2019-10-05 Thread Stephen Kitt
On Sat, 05 Oct 2019 21:44:25 +0200, Stephen Kitt  wrote:
> Policy section 11.8.5, point 1 says
> 
> > If one or more of the fonts so packaged are necessary for proper
> > operation of the package with which they are associated the font
> > package may be Recommended; if the fonts merely provide an
> > enhancement, a Suggests relationship may be used. Packages must not
> > Depend on font packages.  
> 
> The associated footnote explains that
> 
> > This is because the X server may retrieve fonts from the local file
> > system or over the network from an X font server; the Debian package
> > system is empowered to deal only with the local file system.  
> 
> While this is still technically true, it seems rather irrelevant
> nowadays: most GUI programs directly render fonts obtained locally,
> and even for “traditional” X fonts, the vast majority of systems will
> obtain the fonts locally. Debian hasn’t had xfs for 5.5 years
> (); there is another font server
> available, xfstt, but that only handles TrueType fonts.

Oops, that should be https://bugs.debian.org/733958

> It’s common for packages to strongly depend on non-X fonts they need;
> see for example the reverse dependencies of fonts-dejavu. While
> lintian objects to X font depencencies
> (),
> it doesn’t have anything to say about non-X fonts (rightly so).
> 
> Wouldn’t it make sense to relax the constraints on X font
> dependencies?

Regards,

Stephen


pgplErs3bpixu.pgp
Description: OpenPGP digital signature


Bug#941408: marked as pending in koules

2019-10-05 Thread Stephen Kitt
On Sat, 5 Oct 2019 21:24:04 +0200, Stephen Kitt  wrote:
> I’ll open a bug against policy.

https://bugs.debian.org/941803

Regards,

Stephen


pgp_VJCG_x8mT.pgp
Description: OpenPGP digital signature


Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)

2019-10-05 Thread Shayan Doust

Hello Andreas,

Thanks for the reminder. I have not had the chance to look at this again 
yet but eager enough to have made it the thing I will look at again now.


Kind regards,
Shayan Doust



Bug#941804: exim4: remote_smtp_smarthost transport does not set DKIM variables

2019-10-05 Thread Mike Crowe
Package: exim4
Version: 4.92-8+deb10u3
Severity: wishlist

The remote_smtp transport in
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp contains lines
like:

 .ifdef DKIM_PRIVATE_KEY
 dkim_private_key = DKIM_PRIVATE_KEY
 .endif

to set the DKIM variables based on macro values. These lines are not
present in the remote_smtp_smarthost transport in
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost, which
stops DKIM from working when using a smart host.

I've copied and pasted the DKIM lines from remote_smtp to
remote_smtp_smarthost as recommended at
https://warlord0blog.wordpress.com/2016/10/13/exim4-dkim-smarthost/ which
seemed to make DKIM work for me when using a smart host.

Please can you include these lines in the shipped configuration?

Mike.

-- Package-specific info:
Exim version 4.92 #3 built 27-Sep-2019 16:09:35
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event OCSP PRDR PROXY 
SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-base 4.92-8+deb10u3
ii  exim4-daemon-heavy 4.92-8+deb10u3

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
  exim4/drec:



Bug#941802: calibre: ebook-viewer depends on PyQt5.QtWebEngineCore (missing)

2019-10-05 Thread Thomas Renard
Package: calibre
Version: 4.0.0+dfsg-1
Severity: normal

Dear Maintainer,

ebook-viewer depends on PyQt5.QtWebEngineCore but package
python3-pyqt5.qtwebenginecore is missing (and calibre package has
no dependency on it)

- Start ebook-viewer from shell

Expected: viewer starts up
Actual Behaviour:

Traceback (most recent call last):
  File "/usr/bin/ebook-viewer", line 20, in 
sys.exit(ebook_viewer())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 80, in ebook_viewer
from calibre.gui2.viewer.main import main
  File "/usr/lib/calibre/calibre/gui2/viewer/main.py", line 12, in 
from PyQt5.QtWebEngineCore import QWebEngineUrlScheme
ImportError: No module named QtWebEngineCore

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin  4.0.0+dfsg-1
ii  fonts-liberation 1:1.07.4-10
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b1
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-5+b1
ii  python-apsw  3.28.0-r1-1
ii  python-bs4   4.8.0-2
ii  python-chardet   3.0.4-4
ii  python-cherrypy3 8.9.1-2
ii  python-css-parser1.0.4-1
ii  python-cssselect 1.1.0-1
ii  python-cssutils  1.0.2-2
ii  python-dateutil  2.7.3-3
ii  python-dbus  1.2.12-1
ii  python-feedparser5.2.1-1
ii  python-html2text 2019.8.11-1
ii  python-html5-parser  0.4.8-1
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.4.1-1
ii  python-markdown  3.1.1-2
ii  python-mechanize 1:0.4.3-2
ii  python-msgpack   0.5.6-1+b1
ii  python-netifaces 0.10.4-1+b1
ii  python-pil   6.1.0-1
ii  python-pkg-resources 41.2.0-1
ii  python-pyparsing 2.4.2-1
ii  python-pyqt5 5.12.3+dfsg-2
ii  python-pyqt5.qtsvg   5.12.3+dfsg-2
ii  python-pyqt5.qtwebkit5.12.3+dfsg-2
ii  python-regex 0.1.20190207-1+b1
ii  python-routes2.4.1-1
ii  python2.72.7.16-4
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
ii  python-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python-unrardll  

-- no debconf information



Bug#941803: debian-policy: dependencies on font packages

2019-10-05 Thread Stephen Kitt
Package: debian-policy
Version: 4.4.1.1
Severity: normal

Dear Maintainer,

Policy section 11.8.5, point 1 says

> If one or more of the fonts so packaged are necessary for proper
> operation of the package with which they are associated the font
> package may be Recommended; if the fonts merely provide an
> enhancement, a Suggests relationship may be used. Packages must not
> Depend on font packages.

The associated footnote explains that

> This is because the X server may retrieve fonts from the local file
> system or over the network from an X font server; the Debian package
> system is empowered to deal only with the local file system.

While this is still technically true, it seems rather irrelevant
nowadays: most GUI programs directly render fonts obtained locally,
and even for “traditional” X fonts, the vast majority of systems will
obtain the fonts locally. Debian hasn’t had xfs for 5.5 years
(); there is another font server
available, xfstt, but that only handles TrueType fonts.

It’s common for packages to strongly depend on non-X fonts they need;
see for example the reverse dependencies of fonts-dejavu. While
lintian objects to X font depencencies
(),
it doesn’t have anything to say about non-X fonts (rightly so).

Wouldn’t it make sense to relax the constraints on X font
dependencies?

Regards,

Stephen


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

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

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  1.8.4-1

Versions of packages debian-policy suggests:
ii  doc-base  0.10.8

-- no debconf information


Bug#941688: marked as done (openssl 1.1.1d security update breaks openssh login on old kernels)

2019-10-05 Thread Salvatore Bonaccorso
Hi, Sebastian,

> On 2019-10-05 18:00:02 [+0200], Sylvain Rochet wrote:
> > Indeed, you are right, this issue is now fixed upstream in openssh.
> > https://github.com/openssh/openssh-portable/pull/149
> 
> in that I'm closing this.

Or maybe it would be worth as an option to reassign to src:openssh an
for such cases as for the reporter (if Colin is open to it obviously)
to have it backported for a point release update?

Regards,
Salvatore



Bug#935753: Here too

2019-10-05 Thread inkbottle
I've got the exact same bug.
Lenovo x230.
$ chromium  
[2261:2261:1005/211843.228812:FATAL:memory_linux.cc(42)] Out of memory. 
#0 0x55b7729e7509  
#1 0x55b772935cc6  
#2 0x55b77294dcd4  
#3 0x55b77296ee4d  
#4 0x55b7729fac85 calloc
...
#41 0x55b76fdd406d ChromeMain 
#42 0x7f74251bdbbb __libc_start_main 
#43 0x55b76fdd3eca _start 
 r8:   r9: 7ffe439cc750 r10: 0008 r11: 
0246 
r12: 7ffe439cd9a0 r13: 7ffe439cdb60 r14: 0047 r15: 
7ffe439cc9d0 
 di: 0002  si: 7ffe439cc750  bp: 7ffe439cc9a0  bx: 
7ffe439cdfb0 
 dx:   ax:   cx: 7f74251d1081  sp: 
7ffe439cc750 
 ip: 7f74251d1081 efl: 0246 cgf: 002b0033 erf: 
 
trp:  msk:  cr2:  
[end of stack trace] 
Calling _exit(1). Core file will not be generated.


So, no more chromium on that machine.



Bug#939052: mpd: Stuttering after about 4 to 5 second or longer pause.

2019-10-05 Thread Michel
Package: mpd
Followup-For: Bug #939052

Geoff,

Installed your build of 0.21.15 from the link in your email. After
testing for a while, the stuttering after about 4 to 5 second or longer
pause; no longer occurs. Sorry for the late reply, but never received
your email.

Thank You and Be Well,
Michel



Bug#941408: marked as pending in koules

2019-10-05 Thread Stephen Kitt
On Sat, 5 Oct 2019 10:46:03 +0100, Simon McVittie  wrote:
> On Sat, 05 Oct 2019 at 11:02:00 +0200, Stephen Kitt wrote:
> > It’s not ideal, since the dependency isn’t strong, but
> > policy says packages can’t depend on font packages — which makes sense in
> > X since the fonts can be served remotely. (See
> > https://lintian.debian.org/tags/package-depends-on-an-x-font-package.html
> > for details.)  
> 
> Does this recommendation still make sense? It certainly *used to be*
> the case that font rendering (and a lot of other rendering) was done
> server-side on the X server, possibly with fonts served by a remote
> font server like the xfstt package; but my understanding is that this
> decade, toolkits like GTK and Qt normally do their rendering locally
> and are responsible for loading their own fonts, mostly via fontconfig
> and freetype.

Right, it probably doesn’t make much sense any more. Ironically, the
situation is better now than it was a few years ago when X font servers
stopped being popular and before fontconfit and Freetype became commonplace:
with the latter, there are fallbacks which usually work reasonably well (at
least, well enough to get some text on the screen), whereas X programs which
ask for a specific font (such as Koules here) typically break if the X server
doesn’t have the font...

I’ll open a bug against policy.

Regards,

Stephen


pgpqGXAB5EFWc.pgp
Description: OpenPGP digital signature


Bug#941663: openssh-server: fatal: privsep_preauth: preauth child terminated by signal 31

2019-10-05 Thread Adam D. Barratt
On Sat, 2019-10-05 at 12:16 -0400, James Cloos wrote:
> Using ed25519 keys (host and client) should work around this issue.

FWIW according to #941665, this should also only affect users running
buster on kernels < 3.19.

Regards,

Adam



Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

2019-10-05 Thread David Bremner
Sean Whitton  writes:

> Hello,
>
> On Sun 29 Sep 2019 at 11:21AM +02, Daniel Kahn Gillmor wrote:
>
>> Do you think we need this to be done in order for mailscripts to adopt
>> imap-dl?  that would make me kind of sad, though of course i can
>> continue to use imap-dl without its adoption by mailscripts.
>
> As an alternative to adding the integration tests, how about you use
> imap-dl on a daily basis for ~3 months with (I assume) a standard IMAP
> server, and if you don't have to make any nontrivial changes to the
> script during that time, we can ship it in mailscripts?

FWIW I'm already using imap-dl daily, so I guess ask me in a few months
if I noticed any problems.

d



Bug#941801: debian-reference-en: Section 6.8 completely out-of-date

2019-10-05 Thread Brian Potkin
Package: debian-reference-en
Version: 2.76
Severity: important


This page is PostScript-centric. PostScript has no special place in 
  
today's modern PDF-centric printing system. CUPS 1.6 was the defining
moment of change.

Regards,

Brian.



Bug#884372: openshot-qt hangs at start: No module named 'PyQt5.QtWebKitWidgets'

2019-10-05 Thread Jordan Christiansen
I have a workaround for this. I noticed that I had PyQt5 installed in my 
~/.local/lib directory. This version had most of the PyQt5 submodules, 
but not QtWebKit or QtWebKitWidgets. When I removed my local libraries with


pip3 uninstall PyQt5

then openshot searched for all the PyQt5 modules in the system 
directories and was able to find QtWebKit.




Bug#923475: libgl1-mesa-dri: Installed-Size does not account hardlinks

2019-10-05 Thread Sven Joachim
On 2019-02-28 19:19 +0200, Горбешко Богдан wrote:

> Package: libgl1-mesa-dri
> Version: 18.3.2-1
> Severity: minor
>
> Dear Maintainer,
>
> the size reported in the package description (163 MB) is much larger
> than it actually appears on the disk (24 MB), because most of the 
> libraries are sets of hardlinks pointing to same files. Can this be
> accounted please, so the description will not be misleading?

Perhaps, but it would have to be done in dpkg-gencontrol which computes
the Installed-Size field.  Right now it processes each direntry
separately which leads to the overestimation.

> Or the pessimistic size is shown intentionally for the case of
> filesystems that do not support hardlinks?

No, dpkg does not work on those anyway[1].

Cheers,
   Sven


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816881



Bug#939382: fswatch: bad symbols file on !amd64

2019-10-05 Thread Alf Gaida
On Wed, 4 Sep 2019 11:42:01 +0200 Gianfranco Costamagna
 wrote:
> I don't think exporting such c++ symbols is a good idea, specially
because they change between architectures,
> and with different gcc optimization levels.

I think it is a good idea - or the best idea right now. Tbh - i don't
care much about different optimization levels (i know what you mean and
i know the small derivative that uses O3 :P) - i don't care about
architecture dependend symbols. Situation is not that nice, because the
most of the differences was introduced by different compilers in some
architectures.


And yes, upstream should hide not needed symbols - but that's not my
area of expertise - if any derivative think that these symbols are of no
use - they can just delete the symbols file and be done with. So all i
can do right now is to make some symbols optional.


Cheers Alf



Bug#941330: undocumented limitation/dependency in dh_elpa_test

2019-10-05 Thread Nicholas D Steeves
Sean Whitton  writes:

> control: tag -1 +pending
>
> Hello,
>
> On Sat 28 Sep 2019 at 04:50PM -04, Nicholas D Steeves wrote:
>
>> dh-elpa-test appears to have an undocumented hard dependency on
>> (ert-run-test-batch-and-exit), specifically "-and-exit", and this
>> one-function expression must appear as the final line of the defined
>> ert_helper.
>
> Per the existing documentation of ert_helper, it would not be correct to
> set ert_helper to run code that does some work, and then ends by calling
> (ert-run-test-batch-and-exit).  That's what ert_eval is for.
>

In this case it's more: run a second round of tests using a different
upstream provided method, and output how long each test took, plus time
for garbage collection, and of a course a PASS||FAIL.  I believe some of
the variables may be set different for this second.  Upstream and I are
finally hunting for whatever is causing those periodic failures on DebCI
(3% failure rate) and his Travis instance (more than 3% failure rate)
The script is scripts/elpy-test-benchmark.el

I seem to remember that ert_eval didn't provide useful output in case of
failure, where running it as an ert_helper did.

> I believe you're correct that there is a requirement that the ert_helper
> code kill Emacs with a correct exit code in order for dh_elpa_test to
> work properly, so I'm adding documentation for that.

Thanks!
Nicholas


signature.asc
Description: PGP signature


Bug#904443: ITP: python3-asciitree -- draw tree structures using (ASCII or Unicode) characters

2019-10-05 Thread Antonio Valentino
Hi Dominik,
I'm currently working on a new package for zarr [1] that depends on
asciitree.
Do you already have some progress on this package?
Any idea on when the asciitree will be ready?
I could help if you want.



[1] https://github.com/zarr-developers/zarr-python


kind regards

-- 
Antonio Valentino



Bug#941799: lepton: should this package be removed?

2019-10-05 Thread Ryan Tandy
Source: lepton
Severity: important
User: debian...@lists.debian.org
Usertags: proposed-removal

Dear Maintainer,

for these reasons:

- last upload over 2 years ago;
- that upload FTBFS on most arches;
- has never been in testing or stable;
- RC bug #864012 with no activity since 2 years;
- two unfixed CVE bugs (admittedly lower severity);

I suggest that lepton should be removed from Debian.

thanks,
Ryan


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

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



Bug#941800: ITP: spectral -- glossy Matrix client written in c++/qt

2019-10-05 Thread Andres Salomon
Package: wnpp
Owner: Andres Salomon 
Severity: wishlist

* Package name: spectral
  Upstream Author : 
* URL or Web page : https://spectral.encom.eu.org/
* License : GPL-3
  Description : glossy Matrix client written in c++/qt

Spectral is a glossy cross-platform client for Matrix, the
decentralized communication protocol for instant messaging.
It's written in C++ and is QT-based.



Bug#941194: initscripts: remove some implementation details

2019-10-05 Thread Sean Whitton
Hello,

On Sun 29 Sep 2019 at 10:21AM +02, Ansgar wrote:

> I think README.runlevels documents everything about how rcn.d scripts
> are called that Policy also documents (at least the part removed in my
> diff).

Okay, thanks for the feedback.

It would be good to have a third party review the other docs and confirm
that we're not deleting anything useful before proceeding on this.

Sorry to be so queasy about clean up activities.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

2019-10-05 Thread Sean Whitton
Hello,

On Sun 29 Sep 2019 at 11:21AM +02, Daniel Kahn Gillmor wrote:

> Do you think we need this to be done in order for mailscripts to adopt
> imap-dl?  that would make me kind of sad, though of course i can
> continue to use imap-dl without its adoption by mailscripts.

As an alternative to adding the integration tests, how about you use
imap-dl on a daily basis for ~3 months with (I assume) a standard IMAP
server, and if you don't have to make any nontrivial changes to the
script during that time, we can ship it in mailscripts?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#941663: openssh-server: fatal: privsep_preauth: preauth child terminated by signal 31

2019-10-05 Thread Jeroen Franssen
Just tried that and same error... 



-Original Message-
From: James Cloos  
Sent: zaterdag 5 oktober 2019 18:17
To: 941...@bugs.debian.org
Subject: Bug#941663: openssh-server: fatal: privsep_preauth: preauth child
terminated by signal 31

Using ed25519 keys (host and client) should work around this issue.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

-- 
To unsubscribe, send mail to 941663-unsubscr...@bugs.debian.org.






Bug#941330: undocumented limitation/dependency in dh_elpa_test

2019-10-05 Thread Sean Whitton
control: tag -1 +pending

Hello,

On Sat 28 Sep 2019 at 04:50PM -04, Nicholas D Steeves wrote:

> dh-elpa-test appears to have an undocumented hard dependency on
> (ert-run-test-batch-and-exit), specifically "-and-exit", and this
> one-function expression must appear as the final line of the defined
> ert_helper.

Per the existing documentation of ert_helper, it would not be correct to
set ert_helper to run code that does some work, and then ends by calling
(ert-run-test-batch-and-exit).  That's what ert_eval is for.

I believe you're correct that there is a requirement that the ert_helper
code kill Emacs with a correct exit code in order for dh_elpa_test to
work properly, so I'm adding documentation for that.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

2019-10-05 Thread Sean Whitton
Hello David,

On Sun 29 Sep 2019 at 10:35AM -04, David Steele wrote:

> On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton  wrote:
>>
>> Hello,
>>
>> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote:
>>
>> > Reasonable. Then let's drop part about Depends:
>> >
>> >   [ ... All packages with daemons must provide init.d scripts ...],
>> >   unless software is only usable, by upstream's design, when
>> >   pid1 is provided by some other init system.
>>
>> I think this would work.  What do you think, David?
>
> I don't know. It provides more clarity the original Policy question, but 
> raises
> a technical one I don't know the answer to. For my special case, is it
> practical to use systemd (via D-Bus) to manage system daemon
> start/stop when it is
> not pid1? If yes, things may have gotten worse (I'm responsible for getting 
> this
> all to work correctly?).

Unfortunately, there isn't quite enough context in your reply for me to
understand exactly how you think this makes things worse for you.  Could
you expand, please?

> In that case I would prefer a statement discouraging systemd-specific
> features.

I doubt that we have project consensus on that.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#941025: autogen FTCBFS: multiple regressions

2019-10-05 Thread Bruce Korb
On 9/23/19 10:17 AM, Andreas Metzler wrote:
> I plan to let 1:5.18.16-2 migrate to testing first since migration to
> guile-2.2 seems to be urgent (serious bug).

I plan to apply your (Helmut's) patch for release -- as soon as I can
get the Autotools working again. It's been a while and they seem to have
bit-rotted in the interim. :(



Bug#941665: [Pkg-openssl-devel] Bug#941688: openssl 1.1.1d security update breaks openssh login on old kernels

2019-10-05 Thread Sylvain Rochet
Hi Kurt,

On Thu, Oct 03, 2019 at 10:47:09PM +0200, Kurt Roeckx wrote:
> 
> I think this is really an openssh problem, not openssl problem.
> It's one of the downsides of using seccomp that one of the
> libraries you're using might start to do new calls.

Indeed, you are right, this issue is now fixed upstream in openssh.
https://github.com/openssh/openssh-portable/pull/149

Sylvain


signature.asc
Description: Digital signature


Bug#758094: libgl1-mesa-glx:x32: SIGSEGV in OpenGL applications on x32

2019-10-05 Thread Sven Joachim
On 2016-12-15 18:19 +0100, Andreas Boll wrote:

> Control: tags -1 moreinfo
>
> On Thu, Aug 14, 2014 at 08:19:54AM -0400, Daniel Schepler wrote:
>> On Thu, Aug 14, 2014 at 4:46 AM, Thorsten Glaser  wrote:
>> > Package: libgl1-mesa-glx
>> > Version: 10.2.5-1
>> > Severity: normal
>> >
>> > Hi!
>> >
>> > After crossgrading from i386 to x32, OpenGL applications crash.
>> >
>> > glxgears from mesa-utils:i386 (8.2.0-1) works, but
>> > glxgears from mesa-utils:x32 (8.2.0-1) fails:
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0xf76db60b in glLightfv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1
>> > (gdb) bt
>> > #0  0xf76db60b in glLightfv () from /usr/lib/x86_64-linux-gnux32/libGL.so.1
>> > #1  0x0040146f in ?? ()
>> > #2  0xf6aceeea in __libc_start_main (main=, argc=1, 
>> > argv=,
>> > init=, fini=, rtld_fini=, 
>> > stack_end=0xd448)
>> > at libc-start.c:287
>> > #3  0x00401cfc in ?? ()
>> >
>> > I've first noticed that in "xlock -nolock -mode cage",
>> > which, with debugging information, has:
>> >
>> > Program terminated with signal SIGSEGV, Segmentation fault.
>> > #0  0xf6af524b in glGetBooleanv () from 
>> > /usr/lib/x86_64-linux-gnux32/libGL.so.1
>> > (gdb) bt
>> > #0  0xf6af524b in glGetBooleanv () from 
>> > /usr/lib/x86_64-linux-gnux32/libGL.so.1
>> > #1  0x0040fcfe in init_GL (mi=mi@entry=0x228bde0) at visgl.c:287
>> > #2  0x004dc6d4 in init_cage (mi=) at cage.c:400
>> > #3  0x0040e462 in call_init_hook (ls=0x823340 , 
>> > mi=) at mode.c:1290
>> > #4  0x0040887c in justDisplay (display=0x226e870) at xlock.c:2821
>> > #5  0x0040764f in main (argc=36104304, argv=0x0) at xlock.c:3998
>> >
>> > Bugs occur in (first glxgears, then xlock):
>> >
>> > (gdb) disas
>> > Dump of assembler code for function glLightfv:
>> >0xf76db600 <+0>: movrax,QWORD PTR [rip+0x21b9f1]# 
>> > 0xf78f6ff8
>> >0xf76db607 <+7>: movr11,QWORD PTR fs:[rax]
>> > => 0xf76db60b <+11>:jmpQWORD PTR [r11+0x500]
>> >
>> > (gdb) disas
>> > Dump of assembler code for function glGetBooleanv:
>> >0xf6af5240 <+0>: movrax,QWORD PTR [rip+0x21adb1]# 
>> > 0xf6d0fff8
>> >0xf6af5247 <+7>: movr11,QWORD PTR fs:[rax]
>> > => 0xf6af524b <+11>:jmpQWORD PTR [r11+0x810]
>> >
>> > So this appears to be an indirect function call both times.
>>
>> Always before, when I needed to hand-patch the mesa sources to get a
>> custom build, I would disable the x86_64 assembly altogether.  It
>> would appear that some more porting of the assembly to x32 is needed
>> before it's safe to use.  In this case, my guess would be that the
>> assembly is indexing into an array of function pointers, which on x32
>> would need to be adjusted to jmpl *(4*index, %reg) or maybe addr32 jmp
>> *(4*index, %{reg}d) instead of jmpq *(8*index, %reg).
>> --
>> Daniel Schepler
>
> Could you retest with mesa 13.0.2-3 from sid?
> I've disabled assembly usage on x32.

That has apparently helped, but I have just re-enabled asm in git[1],
since the bug is supposed to be fixed since Mesa 17.0.0.

@Thorsten: would be great if you could test that this actually works.

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/lib/mesa/commit/69d86fe6c8b1c73ddb652e6a404ec87926857939



Bug#941798: thunar: FOP popup not updated

2019-10-05 Thread Jiff
Package: thunar
Version: 1.8.4-1
Severity: normal

Hi Dear Mai n'tainer,

   * What led up to the situation?

Copying large videos from a NFS mount to a disk.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

* Open 2 thunar, one on NFS mount, one on local directory,

* drag'n'drop a lot of files by small groups from NFS to local,

* the FOP popup grown up to ~1/2 height of the display and when other files
were dragged'n'dropped, lost it's display (~1/10 of it's content was still
visible at the top, the rest was erased in BG color)

* repeatable each time the number of copy exceeds the FOP height.

   * What was the outcome of this action?

Can't see when each group of files will finish copying.

   * What outcome did you expect instead?

thunar work as expected.



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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u1
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  gvfs  1.38.1-5
ii  libcairo-gobject2 1.16.0-4
ii  libpangocairo-1.0-0   1.42.4-7~deb10u1
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.1-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information



Bug#941663: openssh-server: fatal: privsep_preauth: preauth child terminated by signal 31

2019-10-05 Thread James Cloos
Using ed25519 keys (host and client) should work around this issue.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6



Bug#934160: nfs-common: Umask ignored, all files created world-writable on NFS

2019-10-05 Thread Cédric
+1

QUIRK: In order to reliably disable NFS 4.2 on *server* side; in 
/etc/systemd/system/nfs-server.service.d/nfs-version.conf

# Disable NFS 4.2
# FIX: umask ignored (files created world-writable) when using NFS 4.2 (on top 
of ZFS)
# BUG: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934160
# REF: https://tools.ietf.org/id/draft-ietf-nfsv4-umask-03.html
#  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47057abde515155a4fee53038e7772d6b387e0aa
#  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=880a3a5325489a143269a8e172e7563ebf9897bc
# BUG: 
https://zfsonlinux.topicbox.com/groups/zfs-discuss/T36a651c77dc95fec-Ma755882676a054fe9a903c7f/zfs-discuss-umask-not-respected-when-a-shared-dataset-is-mountedvia-nfs-4-2
# BUG: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738063
# BUG: 
https://linuxlists.cc/l/17/linux-nfs/t/3236382/nfs-config.service_fails_to_apply_no-nfs-version_after_a_reboot#post3236382
[Service]
ExecStartPre=/bin/sh -c '/usr/sbin/rpc.nfsd 0; echo -2 +3 +4 +4.1 -4.2 > 
/proc/fs/nfsd/versions'



  1   2   >