Bug#921971: lintian-brush: fixer for out-of-date-standards-version

2019-02-10 Thread Dmitry Bogatov

Package: lintian-brush
Version: 0.12
Severity: wishlist

From bdefb25fab801e6af0a70e965f60cb48f2b759fa Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Fri, 8 Feb 2019 23:28:30 +
Subject: [PATCH] Add fixed for out-of-date-standards-version

---
 fixers/index.desc| 2 ++
 fixers/out-of-date-standards-version.sh  | 5 +
 tests/out-of-date-standards-version/simple/in/debian/control | 2 ++
 tests/out-of-date-standards-version/simple/message   | 3 +++
 .../out-of-date-standards-version/simple/out/debian/control  | 2 ++
 5 files changed, 14 insertions(+)
 create mode 100755 fixers/out-of-date-standards-version.sh
 create mode 100644 tests/out-of-date-standards-version/simple/in/debian/control
 create mode 100644 tests/out-of-date-standards-version/simple/message
 create mode 100644 
tests/out-of-date-standards-version/simple/out/debian/control

diff --git a/fixers/index.desc b/fixers/index.desc
index ce66a8a..3dabd55 100644
--- a/fixers/index.desc
+++ b/fixers/index.desc
@@ -111,3 +111,5 @@ Lintian-Tags: xs-testsuite-field-in-debian-control
 Fix-Script: xs-vcs-field-in-debian-control.sh
 Lintian-Tags: xs-vcs-field-in-debian-control
 
+Fix-Script: out-of-date-standards-version.sh
+Lintian-Tags: out-of-date-standards-version
diff --git a/fixers/out-of-date-standards-version.sh 
b/fixers/out-of-date-standards-version.sh
new file mode 100755
index 000..d8cda66
--- /dev/null
+++ b/fixers/out-of-date-standards-version.sh
@@ -0,0 +1,5 @@
+#!/bin/sh
+sed -i '/^Standards-Version:/IcStandards-Version: 4.3.0' debian/control
+echo 'Update standards version, no changes needed.'
+echo 'Certainty: certain'
+echo 'Fixed-Lintian-Tags: out-of-date-standards-version'
diff --git a/tests/out-of-date-standards-version/simple/in/debian/control 
b/tests/out-of-date-standards-version/simple/in/debian/control
new file mode 100644
index 000..7bcb99c
--- /dev/null
+++ b/tests/out-of-date-standards-version/simple/in/debian/control
@@ -0,0 +1,2 @@
+Source: lintrian-brush
+Standards-version: 3.9.6
diff --git a/tests/out-of-date-standards-version/simple/message 
b/tests/out-of-date-standards-version/simple/message
new file mode 100644
index 000..05ec0b1
--- /dev/null
+++ b/tests/out-of-date-standards-version/simple/message
@@ -0,0 +1,3 @@
+Update standards version, no changes needed.
+Certainty: certain
+Fixed-Lintian-Tags: out-of-date-standards-version
diff --git a/tests/out-of-date-standards-version/simple/out/debian/control 
b/tests/out-of-date-standards-version/simple/out/debian/control
new file mode 100644
index 000..87cc6cd
--- /dev/null
+++ b/tests/out-of-date-standards-version/simple/out/debian/control
@@ -0,0 +1,2 @@
+Source: lintrian-brush
+Standards-Version: 4.3.0




pgpDiJAm7vK_A.pgp
Description: PGP signature


Bug#912192: wontfix

2019-02-10 Thread Dmitry Bogatov

control: tags -1 +wontfix
control: close -1

As of dvtm=0.15+40.g311a8c0-1, temporary files correctly created in
/tmp. Handling of current directory is better handled by $EDITOR, which
can treat specially files in /tmp/dvtm-editor.* namespace.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgph8rkDGg5rA.pgp
Description: PGP signature


Bug#918601: compactheader 2.1.6-1~deb9u1 flagged for acceptance

2019-02-10 Thread Adam D Barratt
Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: compactheader
Version: 2.1.6-1~deb9u1

Explanation: update to work with newer Thunderbird versions



Bug#321385: wontfix

2019-02-10 Thread Dmitry Bogatov

tags -1 +wontfix +upstream
close -1
thanks

This is not change to be implemented by Debian, sorry. Try asking upstream.

But in my opinion, given that @daily is exactly equivalent to `0 0 * * *',
without randomization for load-balancing, there is little value in it.

Closing, in any case. 13 years old bug. Better late then never?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpT4A7wT3S63.pgp
Description: PGP signature


Bug#921910: vulture 0.11-1+deb9u1 flagged for acceptance

2019-02-10 Thread Adam D Barratt
Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: vulture
Version: 0.11-1+deb9u1

Explanation: add missing dependency on python3-pkg-resources



Bug#917797:

2019-02-10 Thread Michael Hudson-Doyle
Ah yes this was indeed fixed by 2.37-1 or something around there but we
forgot to mention this bug in the changelog. Thanks for the reminder!


Bug#921978: RM: python3-redmine python-redmine [all] -- RoQA; renamed to python{,3}-redminelib

2019-02-10 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Please remove the obsolete arch:all packages 

python-redmine |1.5.1-1 | all
python3-redmine |1.5.1-1 | all

they have been renamed to python{,3}-redminelib in 2.1.1-1


Andreas



Bug#921979: lmfit-py: FTBFS randomly (test_covariance_matrix.test_bounded_parameters fails)

2019-02-10 Thread Santiago Vila
Package: src:lmfit-py
Version: 0.9.11+dfsg-1
Severity: serious
Tags: ftbfs patch

Hello Andreas et al.

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/lmfit-py-0.9.11+dfsg'
dh_auto_build
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/lineshapes.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/models.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/jsonutils.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/printfuncs.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/_ampgo.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/model.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/minimizer.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/parameter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/confidence.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/_version.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
copying lmfit/ui/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
copying lmfit/ui/ipy_fitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
copying lmfit/ui/basefitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
UPDATING 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/_version.py
set 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/_version.py
 to '0.9.11'
I: pybuild pybuild:295: cp -r NIST_STRD 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/lineshapes.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/models.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/jsonutils.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/printfuncs.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/_ampgo.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/model.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/minimizer.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/parameter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/confidence.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/_version.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
copying lmfit/ui/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
copying lmfit/ui/ipy_fitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
copying lmfit/ui/basefitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
UPDATING 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/_version.py
set 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/_version.py
 to '0.9.11'
I: pybuild pybuild:295: cp -r NIST_STRD 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build
PYTHONPATH=. http_proxy='localhost' sphinx-build -N -bhtml doc/ build/html  # 
HTML generator
Running Sphinx v1.7.9
making output directory...
loading pickled environment... not yet created
loading intersphinx inventory from https://docs.python.org/2/objects.inv...
loading intersphinx inventory from 
https://docs.scipy.org/doc/numpy/objects.inv...
loading intersphinx inventory from 
https://docs.scipy.org/doc/scipy/reference/objects.inv...
building [mo]: targets for 0 po files that are out of date
building [html]: 

Bug#921984: RM: vblade-persist -- RoQA; dead upstream, alternative exists (vblade)

2019-02-10 Thread Christoph Biedl
Package: ftp.debian.org
Severity: normal

Hello,

please remove the vblade-persist package

The original author and maintainer of vblade-persist (dkg, Cc:'ed)
had orphaned the package for various reasons, as stated in in #862873.
In the meantime, the vblade package got support for persistence as
well, and there's also a conversion script so users of vblade-persist
can switch easily.

In other words, there is no need to provide this package in Debian
any longer, please remove it from unstable.

Regards,

Christoph



signature.asc
Description: PGP signature


Bug#921985: munin-node: df plugin fails to get data for /home

2019-02-10 Thread Marc Donges
Package: munin-node
Version: 2.0.45-1
Severity: normal

Dear Maintainer,

on one of my systems I noticed that munin no longer records disk free data for 
the separate /home filesystem.

While debugging I could not reproduce the problem when running the df plugin 
with munin-run. I could also not reproduce it with munin-node started directly 
from the command line.

Incomplete output with munin-node run as daemon from systemd:
marc@nephthys:~$ nc localhost 4949
# munin node at nephthys
fetch df
_dev_mapper_nephthys_root_crypt.value 73.5565195777657
_dev_shm.value 1.84851226160177
_run.value 10.594829277865
_run_lock.value 0.078125
_sys_fs_cgroup.value 0
_dev_sda1.value 25.5692545665476
.

Complete output with munin-node run from CLI:
marc@nephthys:~$ nc localhost 4949
# munin node at nephthys
fetch df
_dev_mapper_nephthys_root_crypt.value 73.5626819028434
_dev_shm.value 2.66106291417369
_run.value 10.5943386970173
_run_lock.value 0.078125
_sys_fs_cgroup.value 0
_dev_sda1.value 25.5692545665476
_dev_mapper_nephthys_home_crypt.value 95.5244404001415
.

See the last line with label _dev_mapper_nephthys_home_crypt.

I found that modifying the service file /lib/systemd/system/munin-node.service 
for munin-node fixes this. The default has:

ProtectHome=true

I changed it to:

# Plugins like "df" require access to /home if that is a separate filesystem
ProtectHome=false

This fixed the problem

Kind regards
Marc

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

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

Versions of packages munin-node depends on:
ii  libnet-server-perl  2.009-1
ii  lsb-base10.2018112800
ii  munin-common2.0.45-1
ii  munin-plugins-core  2.0.45-1
ii  netbase 5.5
ii  perl5.28.1-4

Versions of packages munin-node recommends:
ii  gawk 1:4.2.1+dfsg-1
ii  munin-plugins-extra  2.0.45-1
ii  procps   2:3.3.15-2

Versions of packages munin-node suggests:
pn  munin   
pn  munin-plugins-java  

-- Configuration Files:
/etc/munin/munin-node.conf changed:
log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid
background 1
setsid 1
user root
group root
ignore_file [\#~]$
ignore_file DEADJOE$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
ignore_file \.pod$
allow ^127\.0\.0\.1$
allow ^::1$
allow ^192\.168\.102\.[0-9]*$
allow ^2001:6f8:1d3e:[:0-9a-f]*$
host 127.0.0.1
port 4949

/etc/munin/plugin-conf.d/README [Errno 13] Permission denied: 
'/etc/munin/plugin-conf.d/README'
/etc/munin/plugin-conf.d/munin-node [Errno 13] Permission denied: 
'/etc/munin/plugin-conf.d/munin-node'

-- no debconf information



Bug#921986: ruby-cheffish: FTBFS randomly (failing tests)

2019-02-10 Thread Santiago Vila
Package: src:ruby-cheffish
Version: 13.1.0-2
Severity: important
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_autoreconf -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
mkdir -p /<>/tmp
dh_auto_install
dh_ruby --install /<>/debian/ruby-cheffish
   dh_ruby --install

┌──────────────────────────────────────────────────────────────────────────────┐
│ Install files   
 │
└──────────────────────────────────────────────────────────────────────────────┘

install -d /<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby
install -D -m644 /<>/lib/cheffish.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish.rb
install -D -m644 /<>/lib/cheffish/key_formatter.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/key_formatter.rb
install -D -m644 /<>/lib/cheffish/with_pattern.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/with_pattern.rb
install -D -m644 /<>/lib/cheffish/chef_run.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_run.rb
install -D -m644 /<>/lib/cheffish/rspec/chef_run_support.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/chef_run_support.rb
install -D -m644 /<>/lib/cheffish/rspec/repository_support.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/repository_support.rb
install -D -m644 /<>/lib/cheffish/rspec/recipe_run_wrapper.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/recipe_run_wrapper.rb
install -D -m644 /<>/lib/cheffish/rspec/matchers.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers.rb
install -D -m644 
/<>/lib/cheffish/rspec/matchers/emit_no_warnings_or_errors.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/emit_no_warnings_or_errors.rb
install -D -m644 
/<>/lib/cheffish/rspec/matchers/partially_match.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/partially_match.rb
install -D -m644 /<>/lib/cheffish/rspec/matchers/be_idempotent.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/be_idempotent.rb
install -D -m644 /<>/lib/cheffish/rspec/matchers/have_updated.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/have_updated.rb
install -D -m644 /<>/lib/cheffish/version.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/version.rb
install -D -m644 /<>/lib/cheffish/node_properties.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/node_properties.rb
install -D -m644 /<>/lib/cheffish/base_properties.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/base_properties.rb
install -D -m644 /<>/lib/cheffish/basic_chef_client.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/basic_chef_client.rb
install -D -m644 /<>/lib/cheffish/chef_run_listener.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_run_listener.rb
install -D -m644 /<>/lib/cheffish/server_api.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/server_api.rb
install -D -m644 /<>/lib/cheffish/recipe_dsl.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/recipe_dsl.rb
install -D -m644 /<>/lib/cheffish/chef_actor_base.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_actor_base.rb
install -D -m644 /<>/lib/cheffish/chef_run_data.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_run_data.rb
install -D -m644 /<>/lib/cheffish/rspec.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec.rb
install -D -m644 /<>/lib/cheffish/merged_config.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/merged_config.rb
install -D -m644 /<>/lib/cheffish/array_property.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/array_property.rb
install -D -m644 /<>/lib/cheffish/base_resource.rb 

Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

2019-02-10 Thread Mykola Nikishov
Carsten Schoenert  writes:

> The issue in question isn't breaking any policy, raises security issues,
> makes the package not usable or is provoking any data loss, so a
> severity of critical, grave or serious isn't a correct tagging.
> Decreasing the severity to normal.
>
> [1] https://www.debian.org/Bugs/Developer#severities

important:
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.

Does this one fit the bill?

-- 
Mykola

Libre/Free Java Software Engineer
https://manandbytes.gitlab.io/



Bug#921987: fixed

2019-02-10 Thread Jean-Marie Favreau
Dear debian developers,

It seems that this bug disappeared with the last apt upgrade.

Best regards,


-- 
Jean-Marie Favreau - http://jmfavreau.info



Bug#921959: openbsd-inetd: buffer overflow in tftpd caused by wrong path

2019-02-10 Thread Marco d'Itri
On Feb 10, Alison Chaiken  wrote:

> I'm running tftpd between a laptop and an NFS-booted embedded board
> connected by eth0.  When I power the board and try to transfer
> files to it, tftpd will crash, generating core files.  Here is the
Then please reassign this bug to the tftp daemon that you are using.

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#921387: UI on HIDPI too small

2019-02-10 Thread Toni Mueller


On Sat, Feb 09, 2019 at 04:37:17PM +0100, Rene Engelhard wrote:
> And then there's the GNOME/Gtk3/Qt/... settings.

If these accessibility features would be tunable by environment
variables which were interpreted by libraries or config files, that
would be perfectly fine by me. If I could just install some libraries or
such a settings program and then set those values in a way that I would
have them in awesome, but without Gome and friends, that would also be
perfectly acceptable.

> You have choosen awesome.

And for a good reason. For about everything else in those "desktop
environments" does not work for me and my workflows. I've lost my
desktop environments more often than I can remember, due to profile
corruption on every computer and every version I tried, to the point
that I could not even run Firefox on a pretty vanilla Gnome in Stretch,
where I once arrived in a situation where deleting all dot files and
directories under ~user/ did not make it work again. However, shutting
down Gnome and starting awesome fixed the problem immediately.

This accessibility issue does not outweigh the plethora of problems I
experience with "desktop enviromnents" within weeks or days after trying
to use them, and should imho be solved in a generic way that's open to
every GUI user.


Cheers,
Toni



Bug#921965: dgit.1: Write the leading dash of an option as '\-'

2019-02-10 Thread Bjarni Ingi Gislason
Package: dgit
Version: 8.3
Severity: minor
Tags: patch

Dear Maintainer,

  write the leading dash(es) of an option as '\-', not just '-', see
man-pages(7).

  The patch does not change the output from nroff.

diff -dpru dgit/dgit.1 new-dgit/dgit.1
--- dgit/dgit.1 2019-02-04 02:30:03.0 +
+++ new-dgit/dgit.1 2019-02-10 16:00:16.0 +
@@ -147,8 +147,8 @@ commit.
 Tagging, signing and actually uploading should be left to dgit push.
 
 dgit's build operations access the network,
-to get the -v option right.
-See -v, below.
+to get the \-v option right.
+See \-v, below.
 .TP
 \fBdgit build-source\fR ...
 Builds the source package, and a changes file for a prospective
@@ -163,12 +163,12 @@ Tagging, signing and actually uploading
 push-source, or dgit push.
 .TP
 .B dgit clean
-Cleans the current working tree (according to the --clean= option in
+Cleans the current working tree (according to the \-\-clean= option in
 force).
 .TP
-\fBdgit update-vcs-git\fR [\fIsuite\fP|\fB.\fR] [\fB--\fR] [\fIgit fetch 
options\fR]
+\fBdgit update-vcs-git\fR [\fIsuite\fP|\fB.\fR] [\fB\-\-\fR] [\fIgit fetch 
options\fR]
 .TQ
-\fBdgit update-vcs-git\fR [\fIsuite|\fP\fB.\fR] \fB-\fR
+\fBdgit update-vcs-git\fR [\fIsuite|\fP\fB.\fR] \fB\-\fR
 Sets up, or updates the url of, the vcs-git remote, and
 (unless \fB-\fR was specified)
 runs git fetch on it.
@@ -194,7 +194,7 @@ The output is left in
 .IP
 Note that by default
 sbuild does not build arch-independent packages.
-You probably want to pass -A, to request those.
+You probably want to pass \-A, to request those.
 .IP
 Tagging, signing and actually uploading should be left to dgit push.
 .TP
@@ -206,12 +206,12 @@ binary changes files.
 The output is left in
 .IR package \fB_\fR version \fB_multi.changes\fR.
 
-You should ensure that your dgit --build-products-dir setting matches
-your pbuilder --buildresult.
+You should ensure that your dgit \-\-build-products-dir setting matches
+your pbuilder \-\-buildresult.
 
-The \fIdebbuildopts\fP are passed to pbuilder using its --debbuildopts
+The \fIdebbuildopts\fP are passed to pbuilder using its \-\-debbuildopts
 option.  If you want to pass other options to pbuilder, use the
-\fB--pbuilder:\fR dgit option as described below
+\fB\-\-pbuilder:\fR dgit option as described below
 (remember that dgit options should appear between \fBdgit\fR and
 \fBpbuilder\fR).
 
@@ -251,7 +251,7 @@ In more detail: dgit push checks that th
 the .dsc.  It then pushes the HEAD to the suite's dgit-repos branch,
 adjusts the .changes to include any .origs which the archive lacks
 and exclude .origs which the archive has
-(so -sa and -sd are not needed when building for dgit push),
+(so \-sa and \-sd are not needed when building for dgit push),
 makes a signed git tag, edits the .dsc to contain the dgit metadata
 field, runs debsign to sign the upload (.dsc and .changes), pushes the
 signed tag, and finally uses dput to upload the .changes to the
@@ -267,11 +267,11 @@ to prepare the branch
 for source package upload and push.
 .TP
 \fBdgit push-source\fR [\fIsuite\fP]
-Without \fB-C\fR, builds a source package and dgit pushes it.  Saying
+Without \fB\-C\fR, builds a source package and dgit pushes it.  Saying
 \fBdgit push-source\fR is like saying "update the source code in the
 archive to match my git HEAD, and let the autobuilders do the rest."
 
-With \fB-C\fR, performs a dgit push, additionally ensuring that no
+With \fB\-C\fR, performs a dgit push, additionally ensuring that no
 binary packages are uploaded.
 .TP
 \fBdgit rpush\fR \fIbuild-host\fR\fB:\fR\fIbuild-dir\fR [\fIpush args...\fR]
@@ -286,7 +286,7 @@ l l.
 1. Clone on build host (dgit clone)
 2. Edit code on build host (edit, git commit)
 3. Build package on build host (dgit build)
-4. Test package on build host or elsewhere (dpkg -i, test)
+4. Test package on build host or elsewhere (dpkg \-i, test)
 5. Upload by invoking dgit rpush on host with your GPG key.
 .TE
 
@@ -390,7 +390,7 @@ dgit can make patches in some situations
 so dgit quilt-fixup can be useful in its own right.
 To always use dgit's own patch generator
 instead of git-debrebase make-patches,
-pass --git-debrebase=true to dgit.
+pass \-\-git-debrebase=true to dgit.
 
 See
 .B FORMAT 3.0 (QUILT)
@@ -421,14 +421,14 @@ and specifying where to find that commit
 import-dsc might need online access.
 If this is a problem
 (or dgit's efforts to find the commit fail),
-consider --no-chase-dsc-distro
-or --force-import-dsc-with-dgit-field.
+consider \-\-no-chase-dsc-distro
+or \-\-force-import-dsc-with-dgit-field.
 
 There is only one sub-option:
 
-.B --require-valid-signature
+.B \-\-require-valid-signature
 causes dgit to insist that the signature on the .dsc is valid
-(using the same criteria as dpkg-source -x).
+(using the same criteria as dpkg-source \-x).
 Otherwise, dgit tries to verify the signature but
 the outcome is reported only as messages to stderr.
 
@@ -468,7 +468,7 @@ This 

Bug#919339: fixed in radicale 2.1.11-3

2019-02-10 Thread Jonas Smedegaard
Control: found -1

Quoting Slavko (2019-02-10 17:51:25)
> On Tue, 15 Jan 2019 02:40:52 + Jonas Smedegaard  wrote:
> > We believe that the bug you reported is fixed in the latest version 
> > of radicale, which is due to be installed in the Debian FTP archive.
> 
> I believe that it is not fixed, at least not in 2.1.11-4, but i do not 
> want to open new issue for it.

You did the right thing by posting to this existing bugreport instead of 
creating a new.  Thanks!


 - Jonas

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

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


signature.asc
Description: signature


Bug#921667: [pkg-lxc-devel] Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

2019-02-10 Thread Antonio Terceiro
On Sun, Feb 10, 2019 at 12:13:43AM +0100, Pierre-Elliott Bécue wrote:
> Le samedi 09 février 2019 à 22:19:13+0100, Andreas Beckmann a écrit :
> > On 2019-02-09 21:51, Pierre-Elliott Bécue wrote:
> > > I'm not sure that there is something we can do regarding lxc. Am I
> > > wrong?
> > 
> > You could try to figure out why lxc explodes.
> > Probably some package places some configuration file at some location
> > 
> > 
> > Andreas
> > 
> > PS: I should be able to get a shell in the chroot after the failure
> > occurred, in case you want me to collect some information.
> 
> That's a good idea. This error is not clear at all to me.

I can reproduce this on a clean chroot (but not on a clean VM)

> Could you please try to run the .postinst of lxc manually with a set -x?
> The goal would be to check which part explodes.

8<8<8<-
Setting up lxc (1:3.1.0+really3.0.3-2) ...
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/lxc.postinst configure 
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ upgrade configure 
+ [ ! -z  ]
+ [ -z  ]
+ which apparmor_parser
+ [ -e /etc/apparmor.d/lxc-containers ]
+ apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers
Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
Use --subdomainfs to override.
dpkg: error processing package lxc (--configure):
 installed lxc package post-installation script subprocess returned error exit 
status 1
dpkg: dependency problems prevent configuration of lxc-templates:
 lxc-templates depends on lxc (>= 1:3.0.2-1~exp+1); however:
  Package lxc is not configured yet.

dpkg: error processing package lxc-templates (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 lxc
 lxc-templates
E: Sub-process /usr/bin/dpkg returned an error code (1)
8<8<8<-


signature.asc
Description: PGP signature


Bug#921974: ITS: acl

2019-02-10 Thread Guillem Jover
Source: acl
Source-Version: 2.2.52-3
Severity: important

Hi!

This package needs some attention, and looks like a candidate for
salvaging. Anibal is already being tracked by the MIA team, and I
think it's just a matter of days until he gets an orphaning pass.

I'd like to get updated packages uploaded for the next release, so
some time before the freeze. That's why I'll probably be using a
shorter salvaging process here. Nathan please let me know if you
have any objection over this?

(The usual salvaging process is described in the devref § 5.12.)

Thanks,
Guillem



Bug#921977: stretch-pu: package unzip/6.0-21+deb9u1

2019-02-10 Thread Santiago Vila
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello. Security team tells me this does not deserve a DSA but it's ok
for stable-proposed-updates.

(I know it's a little bit late for 9.8. Sorry for that, and no problem
if this is for 9.9 instead).

Debdiff below.

Thanks.

diff -Nru unzip-6.0/debian/changelog unzip-6.0/debian/changelog
--- unzip-6.0/debian/changelog  2016-12-11 21:03:30.0 +0100
+++ unzip-6.0/debian/changelog  2019-02-10 20:53:00.0 +0100
@@ -1,3 +1,10 @@
+unzip (6.0-21+deb9u1) stretch; urgency=medium
+
+  * Fix buffer overflow in password protected ZIP archives. Closes: #889838.
+Patch borrowed from SUSE. For reference, this is CVE-2018-135.
+
+ -- Santiago Vila   Sun, 10 Feb 2019 20:53:00 +0100
+
 unzip (6.0-21) unstable; urgency=medium
 
   * Rename all debian/patches/* to have .patch ending.
diff -Nru 
unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch 
unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch
--- unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch
1970-01-01 01:00:00.0 +0100
+++ unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch
2019-02-10 20:53:00.0 +0100
@@ -0,0 +1,35 @@
+From: Karol Babioch 
+Subject: Fix buffer overflow in password protected zip archives
+Bug-Debian: https://bugs.debian.org/889838
+Origin: https://bugzilla.novell.com/attachment.cgi?id=759406
+
+--- a/fileio.c
 b/fileio.c
+@@ -1582,6 +1582,10 @@
+ int r = IZ_PW_ENTERED;
+ char *m;
+ char *prompt;
++char *zfnf;
++char *efnf;
++size_t zfnfl;
++int isOverflow;
+ 
+ #ifndef REENTRANT
+ /* tell picky compilers to shut up about "unused variable" warnings */
+@@ -1590,7 +1594,15 @@
+ 
+ if (*rcnt == 0) {   /* First call for current entry */
+ *rcnt = 2;
+-if ((prompt = (char *)malloc(2*FILNAMSIZ + 15)) != (char *)NULL) {
++zfnf = FnFilter1(zfn);
++efnf = FnFilter2(efn);
++zfnfl = strlen(zfnf);
++isOverflow = TRUE;
++if (2*FILNAMSIZ >= zfnfl && (2*FILNAMSIZ - zfnfl) >= strlen(efnf))
++{
++  isOverflow = FALSE;
++}
++if ((isOverflow == FALSE) && ((prompt = (char *)malloc(2*FILNAMSIZ + 
15)) != (char *)NULL)) {
+ sprintf(prompt, LoadFarString(PasswPrompt),
+ FnFilter1(zfn), FnFilter2(efn));
+ m = prompt;
diff -Nru unzip-6.0/debian/patches/series unzip-6.0/debian/patches/series
--- unzip-6.0/debian/patches/series 2016-12-11 20:00:00.0 +0100
+++ unzip-6.0/debian/patches/series 2019-02-10 20:51:54.0 +0100
@@ -17,3 +17,4 @@
 17-restore-unix-timestamps-accurately.patch
 18-cve-2014-9913-unzip-buffer-overflow.patch
 19-cve-2016-9844-zipinfo-buffer-overflow.patch
+20-cve-2018-135-unzip-buffer-overflow.patch



Bug#921748: stretch-pu: package icedtea-web/1.6.2-3.1+deb9u1

2019-02-10 Thread Adam D. Barratt
On Fri, 2019-02-08 at 21:03 +0100, Moritz Muehlenhoff wrote:
> This disables the browser plugin (which was broken due to the Firefox
> Quantum changes),
> the equivalent change in sid was done in 1.7.1-1.

Unfortunately, at least in stable, the package no longer builds on
armhf:

Setting up ca-certificates-java (20170531+nmu1) ...
Error: missing `server' JVM at 
`/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
dpkg: error processing package ca-certificates-java (--configure):
 subprocess installed post-installation script returned error exit status 4

This looks like it needs #874276 backporting to stable.

Regards,

Adam



Bug#916696: initramfs-tools: search for nonexistent resume device

2019-02-10 Thread Trek
On Sun, 10 Feb 2019 17:32:08 +
Ben Hutchings  wrote:

> > I include a patch, tested with and without an ephemeral swap:
> > - the second block (-79,9 +83,10) is the actual fix
> If you would actually send me the log messages I might understand this
> fix, but as it is I don't.  I do need to understand it before I will
> apply it.

yes, sorry, you're right

here the log:

Calling hook resume
I: Configuration sets RESUME=
I: Checking swap device /dev/dm-1
I: /dev/dm-1 has device-mapper name sdb5_crypt; checking crypttab
I: Found cryptdev=sda5_crypt keyfile=/dev/urandom
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
I: Rejecting /dev/dm-1 since it has no permanent key
I: Checking swap device /dev/dm-0
I: /dev/dm-0 has device-mapper name sda5_crypt; checking crypttab
I: Found cryptdev=sda5_crypt keyfile=/dev/urandom
I: Rejecting /dev/dm-0 since it has no permanent key
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
Calling hook thermal


it ends up with the initrd file /main/conf/conf.d/zz-resume-auto
containing:

RESUME=/dev/dm-0


running resume with set -x explain what's going on:

+ report_verbose Rejecting /dev/dm-0 since it has no permanent key
+ test y != y
+ echo I: Rejecting /dev/dm-0 since it has no permanent key
I: Rejecting /dev/dm-0 since it has no permanent key
+ ephemeral=true
+ read -r cryptdev srcdev keyfile junk
+ report_verbose Found cryptdev=sdb5_crypt keyfile=/dev/urandom
+ test y != y
+ echo I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
+ [ sdb5_crypt = sda5_crypt ]
+ read -r cryptdev srcdev keyfile junk
+ true
+ [ -n /dev/dm-0 ]
+ true
+ [  = auto ]
+ [ -n /dev/dm-0 ]
+ [ -z /dev/dm-0 ]
+ echo RESUME=/dev/dm-0


basically, it finishes the while-loop
  while read -r cryptdev srcdev keyfile junk; do
  + read -r cryptdev srcdev keyfile junk
then it checks the ephemeral variable inside the for-loop
  $ephemeral || break
  + true
now the for-loop is finished and it evaluates the first if-construct
  if [ -n "$resume_auto" ] && ! $ephemeral; then
  + [ -n /dev/dm-0 ]
  + true
it evaluates the second if-construct (the bug is here, as it doesn't
account for ephemeral)
  if [ "$RESUME" = auto ] || [ -n "$resume_auto" ]; then
  + [  = auto ]
  + [ -n /dev/dm-0 ]
then the inner if-construct 
  if [ -z "$resume_auto" ]; then
  + [ -z /dev/dm-0 ]
and finally it writes the resume file
  echo "RESUME=${resume_auto}" > "${DESTDIR}/conf/conf.d/zz-resume-auto"
  + echo RESUME=/dev/dm-0


my fix is to reset the resume_auto variable if the device is ephemeral,
thus removing the need to check the ephemeral variable in the two
if-construct after the for-loop

  $ephemeral || break   # exit the for-loop if ephemeral=true
  resume_auto=  # otherwise empty resume_auto


that's it :)
thanks again for your time
ciao!



Bug#920533: asterisk: on upgrade from 13.23.1 to 16.1.1 RTP streams get misdirected to NAT devices

2019-02-10 Thread James Bottomley
On Tue, 2019-01-29 at 10:54 +0100, Bernhard Schmidt wrote:
> Hi James,
> 
> thanks. Have you raised this issue with upstream somehow? I know
> chan_sip is deprecated, but I doubt a bug this severe would be
> undetected for that long.
> 
> I'll try to whip together a test for this (my test installation is
> using chan_pjsip and IPv6).

Actually, you can close this; it turns out to be a firewall issue: the
asterisk 16 update apparently changed the rtp.conf file, moving the RTP
listening port range outside of the matching range on the firewall
hence an intermittent audio loss problem with external connections. 
What the patch does is mostly open the conntrack port on the firewall
allowing the inbound RTP stream.  The correct fix is, of course, to put
the rules back to matching each other.

James



Bug#919356: Licensing of include/linux/hash.h

2019-02-10 Thread Kristian Fiskerstrand
On 1/23/19 9:50 AM, Domenico Andreoli wrote:
> Ben Finney  writes:
>> Domenico Andreoli  writes:
>>
>>>   the situation of dwarves-dfsg improved a lot over the weekend
>>
>> That's good to hear. What is the event you're referring to? Can you give
>> a URL to something that describes this change?
> 
> Upstream (in CC) reacted to my request of clarification and patches
> have been applied upstream and on Salsa. See bug 919356 [0] (please
> keep in CC).
> 
>>> the only knot left is now the license of hash.h
>>>
>>> This file is also present in the kernel [0] with an updated copyright
>>> but still without license.
>>
>> The file you show (in the Linux code base) seems likely to have an
>> equivalent implementation under a different license, from some other
>> code base.
> 
> This will require research and work unlikely to be done before Buster
> release. Are we going to drop this package for now?
> 
>>> I received a private email from somebody in the kernel community who
>>> already tried to contact Nadia in the past but did not get any reply.
>>
>> Thank you also for contacting the Linux developers forum to ask
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>.
> 
> (also in CC now)
> 
>>> I think that pushing it to non-free is formally the right thing but I
>>> actually feel it's not the right thing.
>>
>> To know that work (that file) is free software, we need a clear grant of
>> some specific license, for that work.
>>
>> If the work is not free, it would be incorrect to have the work in Debian.
> 
> Is it possible that for the kernel it is instead correct because it is,
> as whole, covered by its COPYING?
> 
>> Alternatives, for complying with the Debian Free Software Guidelines with
>> this package, include:
>>
>> * Find a credible grant of license under some GPL-compatible free
>>   license to that exact file. Document that explicit grant in the Debian
>>   package. This demonstrates the work is DFSG-free.
>>
>> * Convince ‘dwarves-dfsg’ upstream to replace that file with a different
>>   implementation (I don't know whether such an implementation exists)
>>   under a license compatible with the same version of GNU GPL. Document
>>   that explicit grant in the Debian package. This demonstrates the
>>   modified work is DFSG-free.
> 
> Arnaldo, what priority would you give to this task?
> 
>>
>> * Replace that file in Debian only, with a different implementation as
>>   above. Document that explicit grant in the Debian package. This
>>   demonstrates the modified Debian package is DFSG-free.
>>
>> * Move the work to the ‘non-free’ area.
>>
>> * Remove the work altogether.
>>
>> Those are in descending order of (my recommended) preference.
> 
> Thanks,
> Domenico
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356
> 

It was [pointed out] by one of our license group that [hash.h]  is the
same that has a GPL-2+ in [fio] which has a signed-off-by.

References:
[pointed out]
https://bugs.gentoo.org/677586#c1

[hash.h]
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c

[fio]
https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright



-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Bug#921128: Info received (mailman3-web fails to initialize mysql: Specified key was too long)

2019-02-10 Thread Antoine Beaupré
On 2019-02-10 01:11:35, Pierre-Elliott Bécue wrote:
> Le vendredi 01 février 2019 à 21:05:38-0500, Antoine Beaupré a écrit :
>> I just read the README.Debian file and it says the mariadb version in
>> stretch might conflict with the mailman3-web version.
>> 
>> If that's really the case, might I suggest the backport be fixed to warn
>> explicitely about this somehow? maybe conflict with that mariadb
>> version?
>
> Please review and comment
> https://salsa.debian.org/mailman-team/mailman-suite/commit/1dc0dcf43e763b4b78e808877d65a8dbb6119170
>
> I'll upload in a couple of days. :)

That's a great start!

Couldn't we check if mariadb is actually installed or configured somehow
instead of just always prompting?

But if that's too much work, it's better than nothing for sure.

THanks! :)

A.

-- 
On ne résout pas un problème avec les modes de pensée qui l'ont
engendré.
- Albert Einstein



Bug#921989: ITP: sozu -- a fast, reliable, hot reconfigurable HTTP reverse proxy

2019-02-10 Thread Nicolas Braud-Santoni
Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: sozu
  Version : 0.11.0
  Upstream Author : Geoffroy Couprie 
* URL : http://sozu.io
* License : AGPL-3.0
  Programming Lang: Rust
  Description : a fast, reliable, hot reconfigurable HTTP reverse proxy


Its authors intend it to be “the most reliable reverse proxy ever”:

- - it should never crash (currently fixing the remaining panics)
- - you should not need to restart it
  - it can receive configuration changes from a unix socket at runtime
  - it should be able to upgrade without any downtime
- - it should not have exploitable memory errors
  - even if it has one, workers will be sandboxed
- - you set up a limit on the number of concurrent connections to a worker
  - the reverse proxy will refuse new connections over that limit,
instead of requesting unavailable resources like memory


Moreover, HTTP frontends currently-available in Debian are either fairly
low-performance, or written in languages that do not guarantee memory safety,
making them a never-ending source of remotely-exploitable bugs.

As such, I believe sozū fills a gap within Debian's package ecosystem.


I intent to package it, and its various components, as part of the Debian Rust
team, and maybe get involved in upstream development (author in X-Debbugs-CC).


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlxgr1gRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MsH4A//SuqK/mo7Y3CliIM80Lyo6m6kmYOCUtpz
eGfVAXFiR+BjvyjitVHk0NZBK7Jx0qzuA4rUc2rwJKXW+QFQCcsdXo2elkJLp1+V
ZMRHZnfuOH76iSZYdS6Kupg6PqRh5YEZzBWmS/UaBcT8HtFaI2HAj0PBbvsvYCZB
G8zQc/bnDHfPhff/1qH13yKiegsDlCFrkyyyAJtmSqMx1jM7JT7zNsOomYBgdzqs
e6m4MOqPqreFa7Cn4tDiGBK4wTQ4I21Yly9mOzvRezR4uIUNJe/jTn5U80tp5KGf
ipLFlNI1AQcVzBn5fh+eaVht1YymwNP0y7afYloEJRDRKAj7V66k8vhbWSOCNI7S
ulthOW7Yez/caTPj+9Y9E1LAh7vouPY54ECkl8MxcGtcVhxj0ztIsjrbNZTJVhn9
Rw0HOnHI9XT6qhPTzJqHVDF2fJ9NLFmy2bH56O34X/ZW2DcMoIJbvJo+vg1khHe/
8t1bzjVEb6OEPFzYNhqL7MbBs6MymSxGUN37jVvYE5LPSOamEo1BB/fTLDBbvi1A
CKkhnfkjnFuAGior7TPhMOLtklDav70e+RGlq1tdkSOWca3ifk/wEsSxfZmKCCgP
QdA6vWDT1MT6NdieXY4mOjNNkeXw3bWvATo8f5OsIUhEF/LdvdEgjFdvFkv2Edv9
JJzCw5X3Is0=
=iP16
-END PGP SIGNATURE-


Bug#921990: mypy should depend on the precise version of python3-mypy

2019-02-10 Thread Salvo Tomaselli
Package: mypy
Version: 0.670-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I upgraded mypy, python3-mypy did not get pulled in as dependency so it remained
as the old version.

This is what happens when I ran it.


$ mypy
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 789, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (mypy 0.660 (/usr/lib/python3/dist-packages), 
Requirement.parse('mypy==0.670'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/mypy", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 596, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mypy==0.670' distribution was not 
found and is required by the application



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

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

Versions of packages mypy depends on:
ii  python3   3.7.2-1
ii  python3-mypy  0.660-5

mypy recommends no packages.

Versions of packages mypy suggests:
pn  mypy-doc  

-- no debconf information



Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large

2019-02-10 Thread Zac Morris
I guess this can be closed. Gone all day without being able to replicate
the sigfault, so nothing to capture.

It seems to be chugging along well now, must have been user error on my
side.

Thanks for the quick response!
-Zac Morris

On Sun, Feb 10, 2019 at 2:03 PM Bernhard Übelacker 
wrote:

> Ok, so the package corekeeper would be an option?
> Is gdb-minimal also already too much?
>
> Kind regards,
> Bernhard
>
> PS.: please leave the bugs email as CC or To. ;-)
>
>


Bug#921985: munin-node: df plugin fails to get data for /home

2019-02-10 Thread Lars Kruse
Control: merge -1 918851

Hello Marc,


Am Sun, 10 Feb 2019 22:55:45 +0100
schrieb Marc Donges :

> # Plugins like "df" require access to /home if that is a separate filesystem
> ProtectHome=false

Indeed, this setting prevents your use case.

See the other bug report for this issue:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918851

We are discussing whether there is good way to work around this.

Cheers,
Lars



Bug#906855: gcu-plugin: NPAPI plugins are no longer supported by firefox-esr

2019-02-10 Thread Andreas Beckmann
Followup-For: Bug #906855
Control: tag -1 pending

Hi,

I just backported the fix from sid, rebuilt the package for stretch and
opened a stretch-pu request. Let's see if this can still reach 9.8.
https://bugs.debian.org/921983


Andreas



Bug#921781: fis-gtm: FTBFS (dh_auto_configure fails)

2019-02-10 Thread Shah, Amul
Thank you for the patch! We encountered the same problem with the deprecation 
of icu-config. I will fix the upstream source ASAP.

Best Regards,
Amul

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


Bug#921993: RM: golang-gopkg-libgit2-git2go.v26 -- RoQA; superseded by golang-gopkg-libgit2-git2go.v27

2019-02-10 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Hi,

please remove 

golang-gopkg-libgit2-git2go.v26 | 0.26+git20170903.0.eb0bf21-1 | source
golang-gopkg-libgit2-git2go.v26-dev | 0.26+git20170903.0.eb0bf21-1 | all

from unstable which does FTBFS and has been superseded by *.v27.


Andreas



Bug#921296: ccfits: FTBFS with upcoming doxygen 1.8.15

2019-02-10 Thread Aurelien Jarno
On 2019-02-04 10:53, Aurelien Jarno wrote:
> On 2019-02-04 01:04, Paolo Greppi wrote:
> > Source: ccfits
> > Severity: serious
> > 
> > Dear Maintainer,
> > 
> > I tested your package against a draft package for doxygen 1.8.15:
> > https://bugs.debian.org/919413
> > 
> > and it FTBFS with this error:
> > make[2]: *** [Makefile:8: refman.pdf] Error 1
> > 
> 
> That actually looks like a bug in doxygen. CCfits depends on
> doxygen-latex, which according to its description should provide
> everything needed:
> 
> | Package: doxygen-latex
> | ...
> | Description-en: Documentation system for C, C++, Java, Python and other 
> languages
> |  Doxygen is a documentation system for C, C++, Java, Objective-C, Python, 
> IDL
> |  and to some extent PHP, C#, and D.  It can generate an on-line class 
> browser
> |  (in HTML) and/or an off-line reference manual (in LaTeX) from a set of
> |  documented source files.
> |  .
> |  This dependency package adds dependencies for all LaTeX packages required
> |  to build documents using the default stylesheet.
> 
> ccfits doesn't do anything fancy, it just generates the latex file using
> doxygen and then run pdflatex on it. If a dependency is missing for
> that, it should be added to doxygen-latex.
> 

ccfits is now marked for autoremoval. Sending this email to reset the
autoremoval while waiting for an answer.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#922000: src:kauth: Symbols file out of date

2019-02-10 Thread Scott Kitterman
Package: src:kauth
Version: 5.54.0-1
Severity: normal

Seen in the amd64 build logs for 5.54.0-1:

dpkg-gensymbols: warning: some libraries disappeared in the symbols file: 
kauth_backend_plugin.so kauth_helper_plugin.so
dpkg-gensymbols: warning: debian/libkf5auth5/DEBIAN/symbols doesn't match 
completely debian/libkf5auth5.symbols
--- debian/libkf5auth5.symbols (libkf5auth5_5.54.0-1_amd64)
+++ dpkg-gensymbolsUUn6iW   2019-01-18 12:55:12.883857964 +
@@ -1,9 +1,3 @@
-kauth_backend_plugin.so libkf5auth5 #MINVER#
- qt_plugin_instance@Base 5.0.0
- qt_plugin_query_metadata@Base 5.0.0
-kauth_helper_plugin.so libkf5auth5 #MINVER#
- qt_plugin_instance@Base 5.0.0
- qt_plugin_query_metadata@Base 5.0.0
 libKF5Auth.so.5 libkf5auth5 #MINVER#
  _ZN5KAuth10ExecuteJob11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
  _ZN5KAuth10ExecuteJob11qt_metacastEPKc@Base 4.96.0

It seems like it should be updated, but I'm not sure the correct solution, so
not touching it for the security update.

Scott K



Bug#920225: pv: replace ash shell with dash

2019-02-10 Thread Andrew Wood
Thanks for this discussion and for the patch.  I have no idea why this
script uses ash instead of sh.  Digging into its history a little bit I see
that it has been unchanged since December 2003, so who knows what I was
thinking.

It will use /bin/sh in the next release.


On Tue, Jan 22, 2019 at 09:53:16PM -0500, Antoine Beaupre wrote:
> On Tue, Jan 22, 2019 at 09:01:21PM -0300, Juan Picca wrote:
> > Closed as not directly related to debian.
> > Thanks Antoine for your comments and sorry for the noise.
> 
> Glad I could be of service.
> 
> And no problem at all for the noise, I believe it was a fine patch, it's
> just we don't need it in Debian specifically. I would suggest you
> contact upstream here:
> 
> https://www.ivarch.com/personal/contact.shtml
> 
> They are usually quite supportive and responsive to patches, bug reports
> and suggestions. Don't expect a response immediately, however, they take
> their time, which is fine. :)

-- 
Andrew Wood



Bug#921994: jansi-native package is architecture independent and doesn't include native components

2019-02-10 Thread Keegan Witt
Package: libjansi-native-java
Version: 1.8-1
Owner: pkg-java-maintain...@lists.alioth.debian.org

Unlike the Alpine packaging
(https://pkgs.alpinelinux.org/packages?name=java-jansi-native=edge),
which include files /usr/lib/libjansi.so and /usr/lib/libjansi-1.8.so,
Debian's packaging does not.  I believe this is the cause of errors
I'm seeing on other architectures.  The architectures I know are
problematic are below, as well as the error that from the Java program
trying to use Jansi (happens with both Debian's OpenJDK 8 and 11).  I
tested this on Sid (actually in OpenJDK Debian Docker images
(https://hub.docker.com/_/openjdk)), but it probably affects all
versions.

The errors that I get are from the so files in the linux32
(https://search.maven.org/search?q=g:org.fusesource.jansi%20a:jansi-linux32)
and linux64 
(https://search.maven.org/search?q=g:org.fusesource.jansi%20a:jansi-linux64)
jars, but if the native package were installed, Jansi should load that
(it worked on Alpine at least).

powerpc64le
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/tmp/libjansi-64-6177151729256195035.so: Error relocating
/tmp/libjansi-64-6177151729256195035.so: unsupported relocation type 7
(Possible cause: can't load AMD 64-bit .so on a Power PC 64-bit
platform)]

arm64v8
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/tmp/libjansi-64-6661390371961894243.so: Error relocating
/tmp/libjansi-64-6661390371961894243.so: unsupported relocation type 7
(Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform)]

s390x
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/tmp/libjansi-64-7943786764210458085.so: Error loading shared library
/tmp/libjansi-64-7943786764210458085.so: Exec format error (Possible
cause: endianness mismatch)]



Bug#919308: scotch: do not use mpicc

2019-02-10 Thread Drew Parsons
Package: scotch
Version: 6.0.6-2
Followup-For: Bug #919308


Thanks Helmut. I think I'll defer this patch until after the freeze
and stable release.

Drew



Bug#921998: wpa FTCBFS: debian/rules exports CC=cc

2019-02-10 Thread Helmut Grohne
Source: wpa
Version: 2:2.7+git20190128+0c1e29f-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wpa fails to cross build from source, because debian/rules exports CC
with a (default) value of cc. That's the wrong compiler for cross
building and does no good: If there is a non-default, it already is
exported. After removing the export, wpa cross builds successfully.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru wpa-2.7+git20190128+0c1e29f/debian/changelog 
wpa-2.7+git20190128+0c1e29f/debian/changelog
--- wpa-2.7+git20190128+0c1e29f/debian/changelog2019-01-29 
18:11:01.0 +0100
+++ wpa-2.7+git20190128+0c1e29f/debian/changelog2019-02-11 
05:47:36.0 +0100
@@ -1,3 +1,10 @@
+wpa (2:2.7+git20190128+0c1e29f-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't export CC=cc. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Feb 2019 05:47:36 +0100
+
 wpa (2:2.7+git20190128+0c1e29f-1) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru wpa-2.7+git20190128+0c1e29f/debian/rules 
wpa-2.7+git20190128+0c1e29f/debian/rules
--- wpa-2.7+git20190128+0c1e29f/debian/rules2019-01-29 18:11:01.0 
+0100
+++ wpa-2.7+git20190128+0c1e29f/debian/rules2019-02-11 05:47:33.0 
+0100
@@ -19,7 +19,7 @@
 
 PKG_CONFIG ?= $(DEB_HOST_GNU_TYPE)-pkg-config
 
-export CC BINDIR V PKG_CONFIG
+export BINDIR V PKG_CONFIG
 
 DEB_HOST_ARCH_OS  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 HOSTAPD_DOT_CONFIG:= debian/config/hostapd/$(DEB_HOST_ARCH_OS)


Bug#922001: nmu: libxml2_2.9.8+dfsg-1

2019-02-10 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libxml2_2.9.8+dfsg-1 . ANY . experimental . -m "Rebuild against libicu63."

cruft cleanup in sid shows that the transition was not performed in
experimental.


Andreas



Bug#922002: ITP: gotop -- terminal based graphical activity monitor inspired by gtop and vtop

2019-02-10 Thread Mo Zhou
Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: gotop
  Version : 2.0.1
  Upstream Author : Caleb Bassi
* URL : https://github.com/cjbassi/gotop
* License : AGPL-3.0
  Programming Lang: Go
  Description : terminal based graphical activity monitor inspired by gtop 
and vtop

Packaging repo is here https://salsa.debian.org/debian/gotop
Currently it is able to produce a working deb package with vendord source.



Bug#921736: minissdpd: Script in d/minissdpd.config uses /sbin/ifconfig, but package does not depend on net-tools

2019-02-10 Thread Jean-Marc
On Fri, 08 Feb 2019 17:57:04 +0100 Tim Dengel  
wrote:
> Package: minissdpd
> Version: 1.5.20180223-5
> Severity: important
> 
> Dear Maintainer,
> 
> the script in debian/minissdpd.config uses /sbin/ifconfig, but the package 
> does not depend on net-tools, causing the script to fail on upgrades if 
> net-tools is not installed.
> 

Is it possible to increase the bug severity to serious ?
Increasing it to serious allows apt-listbugs to list it in case of upgrade.


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


pgpjmWPf2mjFL.pgp
Description: PGP signature


Bug#906142: stretch-pu: package vulture/0.11-1+deb9u1

2019-02-10 Thread Andreas Beckmann
On 2019-02-10 20:48, Adam D. Barratt wrote:
> This ended up being handled in #921910.
> 
> Andreas - *please* check for existing requests first.

Hmm, too many bugs to look at. At least it wasn't one of my requests :-)


Andreas



Bug#921542: [Patch net 1/3] net_sched: fix a race condition in tcindex_destroy()

2019-02-10 Thread Cong Wang
tcindex_destroy() invokes tcindex_destroy_element() via
a walker to delete each filter result in its perfect hash
table, and tcindex_destroy_element() calls tcindex_delete()
which schedules tcf RCU works to do the final deletion work.
Unfortunately this races with the RCU callback
__tcindex_destroy(), which could lead to use-after-free as
reported by Adrian.

Fix this by migrating this RCU callback to tcf RCU work too,
as that workqueue is ordered, we will not have use-after-free.

This change requires us to store a net pointer inside struct
tcindex_data, to avoid the known race with tc_action_net_exit().

Fixes: 27ce4f05e2ab ("net_sched: use tcf_queue_work() in tcindex filter")
Reported-by: Adrian 
Cc: Ben Hutchings 
Cc: Jamal Hadi Salim 
Cc: Jiri Pirko 
Signed-off-by: Cong Wang 
---
 net/sched/cls_tcindex.c | 46 -
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index 9ccc93f257db..14e6d80dd58e 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -48,7 +48,8 @@ struct tcindex_data {
u32 hash;   /* hash table size; 0 if undefined */
u32 alloc_hash; /* allocated size */
u32 fall_through;   /* 0: only classify if explicit match */
-   struct rcu_head rcu;
+   struct net *net;
+   struct rcu_work rwork;
 };
 
 static inline int tcindex_filter_is_set(struct tcindex_filter_result *r)
@@ -229,15 +230,23 @@ static int tcindex_destroy_element(struct tcf_proto *tp,
return tcindex_delete(tp, arg, , NULL);
 }
 
-static void __tcindex_destroy(struct rcu_head *head)
+static void __tcindex_destroy(struct tcindex_data *p)
 {
-   struct tcindex_data *p = container_of(head, struct tcindex_data, rcu);
-
kfree(p->perfect);
kfree(p->h);
kfree(p);
 }
 
+static void tcindex_destroy_work(struct work_struct *work)
+{
+   struct tcindex_data *p = container_of(to_rcu_work(work),
+ struct tcindex_data,
+ rwork);
+
+   put_net(p->net);
+   __tcindex_destroy(p);
+}
+
 static inline int
 valid_perfect_hash(struct tcindex_data *p)
 {
@@ -258,14 +267,22 @@ static int tcindex_filter_result_init(struct 
tcindex_filter_result *r)
return tcf_exts_init(>exts, TCA_TCINDEX_ACT, TCA_TCINDEX_POLICE);
 }
 
-static void __tcindex_partial_destroy(struct rcu_head *head)
+static void __tcindex_partial_destroy(struct tcindex_data *p)
 {
-   struct tcindex_data *p = container_of(head, struct tcindex_data, rcu);
-
kfree(p->perfect);
kfree(p);
 }
 
+static void tcindex_partial_destroy_work(struct work_struct *work)
+{
+   struct tcindex_data *p = container_of(to_rcu_work(work),
+ struct tcindex_data,
+ rwork);
+
+   put_net(p->net);
+   __tcindex_partial_destroy(p);
+}
+
 static void tcindex_free_perfect_hash(struct tcindex_data *cp)
 {
int i;
@@ -333,6 +350,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, 
unsigned long base,
cp->alloc_hash = p->alloc_hash;
cp->fall_through = p->fall_through;
cp->tp = tp;
+   cp->net = net;
 
if (p->perfect) {
int i;
@@ -477,8 +495,13 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, 
unsigned long base,
rcu_assign_pointer(*fp, f);
}
 
-   if (oldp)
-   call_rcu(>rcu, __tcindex_partial_destroy);
+   if (oldp) {
+   if (oldp->net && maybe_get_net(oldp->net))
+   tcf_queue_work(>rwork,
+  tcindex_partial_destroy_work);
+   else
+   __tcindex_partial_destroy(oldp);
+   }
return 0;
 
 errout_alloc:
@@ -570,7 +593,10 @@ static void tcindex_destroy(struct tcf_proto *tp,
walker.fn = tcindex_destroy_element;
tcindex_walk(tp, );
 
-   call_rcu(>rcu, __tcindex_destroy);
+   if (maybe_get_net(p->net))
+   tcf_queue_work(>rwork, tcindex_destroy_work);
+   else
+   __tcindex_destroy(p);
 }
 
 
-- 
2.20.1



Bug#921995: kauth: Insecure handling of arguments in helpers

2019-02-10 Thread Scott Kitterman
Package: src:kauth
Version: 5.28.0-2
Severity: grave
Tags: security upstream patch
Justification: user security hole

See the KDE announce list [1].  It includes reference to a fix [2].  This is
CVE-2019-7443.

Scott K


[1] https://mail.kde.org/pipermail/kde-announce/2019-February/11.html
[2] 
https://cgit.kde.org/kauth.git/commit/?id=fc70fb0161c1b9144d26389434d34dd135cd3f4a



Bug#921997: stretch-pu: package ca-certificates-java/20170929~deb9u1

2019-02-10 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Control: block 921748 with -1

Hi,

ca-certificates-java is uninstallable on armhf: #874276

The proposed patch has only been build-tested (on amd64), the resulting
(arch:all) package has *not* been tested on armhf at all.
But it does not look like it could make the situation worse.
The package has *not* been uploaded, waiting for an explicit ACK.


Andreas
diff -Nru ca-certificates-java-20170531+nmu1/debian/changelog 
ca-certificates-java-20170929~deb9u1/debian/changelog
--- ca-certificates-java-20170531+nmu1/debian/changelog 2017-06-15 
17:33:00.0 +0200
+++ ca-certificates-java-20170929~deb9u1/debian/changelog   2019-02-11 
05:34:52.0 +0100
@@ -1,3 +1,21 @@
+ca-certificates-java (20170929~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Mon, 11 Feb 2019 05:34:52 +0100
+
+ca-certificates-java (20170929) unstable; urgency=low
+
+  [ Gianfranco Costamagna ]
+  * Team upload.
+  * Ack previous NMU, thanks
+
+  [ Rico Tzschichholz ]
+  * Fix temporary jvm-*.cfg generation on armhf (Closes: #874276)
+- the armhf installation path is different from other architectures.
+
+ -- Rico Tzschichholz   Wed, 27 Sep 2017 17:17:59 +0200
+
 ca-certificates-java (20170531+nmu1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru ca-certificates-java-20170531+nmu1/debian/jks-keystore.hook.in 
ca-certificates-java-20170929~deb9u1/debian/jks-keystore.hook.in
--- ca-certificates-java-20170531+nmu1/debian/jks-keystore.hook.in  
2017-05-31 14:39:26.0 +0200
+++ ca-certificates-java-20170929~deb9u1/debian/jks-keystore.hook.in
2017-09-27 17:17:59.0 +0200
@@ -53,7 +53,11 @@
 # the jre is not yet configured, but jvm.cfg is needed to run it
 temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
 mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
+if [ "$arch" == "armhf" ]; then
+printf -- "-client KNOWN\n-server ALIASED_TO -client\n" > $temp_jvm_cfg
+else
+printf -- "-server KNOWN\n" > $temp_jvm_cfg
+fi
 fi
 
 if dpkg-query --version >/dev/null; then
diff -Nru ca-certificates-java-20170531+nmu1/debian/postinst.in 
ca-certificates-java-20170929~deb9u1/debian/postinst.in
--- ca-certificates-java-20170531+nmu1/debian/postinst.in   2017-05-31 
14:39:26.0 +0200
+++ ca-certificates-java-20170929~deb9u1/debian/postinst.in 2017-09-27 
17:17:59.0 +0200
@@ -100,7 +100,11 @@
 # the jre is not yet configured, but jvm.cfg is needed to run 
it
 temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
 mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
+if [ "$arch" == "armhf" ]; then
+   printf -- "-client KNOWN\n-server ALIASED_TO -client\n" 
> $temp_jvm_cfg
+else
+   printf -- "-server KNOWN\n" > $temp_jvm_cfg
+fi
 fi
 
 trap do_cleanup EXIT


Bug#921999: regionset FTCBFS: fails to pass cross tools to make

2019-02-10 Thread Helmut Grohne
Source: regionset
Version: 0.1-3.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

regionset fails to cross build from source, because the upstream
Makefile does not pick up the environment variables passed by cdbs and
thus uses plain gcc. dh_auto_build passes them as makefile variables and
thus sidesteps this issue. Once using dh_auto_build, regionset cross
builds successfully. Please consider applying the attached patch.

Helmut
diff -u regionset-0.1/debian/changelog regionset-0.1/debian/changelog
--- regionset-0.1/debian/changelog
+++ regionset-0.1/debian/changelog
@@ -1,3 +1,10 @@
+regionset (0.1-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Feb 2019 06:17:27 +0100
+
 regionset (0.1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u regionset-0.1/debian/rules regionset-0.1/debian/rules
--- regionset-0.1/debian/rules
+++ regionset-0.1/debian/rules
@@ -5,0 +6,4 @@
+
+$(cdbs_make_build_stamps):
+   dh_auto_build
+   touch $@


Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

2019-02-10 Thread Carsten Schoenert
Hi,

Am 10.02.19 um 23:31 schrieb Mykola Nikishov:
> Carsten Schoenert  writes:
> 
>> The issue in question isn't breaking any policy, raises security issues,
>> makes the package not usable or is provoking any data loss, so a
>> severity of critical, grave or serious isn't a correct tagging.
>> Decreasing the severity to normal.
>>
>> [1] https://www.debian.org/Bugs/Developer#severities
> 
> important:
> a bug which has a major effect on the usability of a package,
> without rendering it completely unusable to everyone.
> 
> Does this one fit the bill?

is the *usability* really affected? Is this package (in detail the UI)
working badly in this version? I don't think so.

Instead of discussing the severity of the bug report it would be more
helpful to figure out which installed packages or files are useless so
we can solve this issue technically.
If you can help to identify the really required files and summarize
these here in this bug report would help to get the issue solved.

-- 
Regards
Carsten Schoenert



Bug#919317: [Pkg-shadow-devel] Bug#919317: shadow: French documentation translation update

2019-02-10 Thread Alban Vidal
Control: tag -1 |upstream|
Control: tag -1 |pending|

---

Dear Maintainer,

Merge request sended in upstream project:
https://github.com/shadow-maint/shadow/pull/153

Regards,

Alban




signature.asc
Description: OpenPGP digital signature


Bug#921972: lintian-brush: when d/compat is missing

2019-02-10 Thread Jelmer Vernooij
On Sun, Feb 10, 2019 at 07:08:52PM +, Dmitry Bogatov wrote:
> please consider following patch to avoid warnings, when there is no
> `debian/compat'.
Thanks for the patch! Applied in master.

> By the way, it is quite unfortunate, that fixer API disallow early
> sys.exit(0).
Agreed, that would be good to fix. A workaround is to
use sys.exit(2) to exit early without a description.

Jelmer



Bug#921921: live-config: Buster Live LXQt does not autologin

2019-02-10 Thread Daniel Lewart
Alf, et al,

> it would be nice if one would point me to such an image.

http://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/
  * debian-live-testing-amd64-lxqt.iso  2019-02-07 14:22  2.3G

It should be overwritten Mon Feb 11, but I would expect this
issue to remain.

Peace!
Dan



Bug#921921: live-config: Buster Live LXQt does not autologin

2019-02-10 Thread Alf Gaida
Hi Daniel,

given that only KDE and LXQt use sddm as DM the patch looks right.

Thanks for the link, the next builds in a few days will look much nicer
and more like an mature debian flavour. But yay, the first official
Debian LXQt live iso i've started :)

(pcmanfm-qt 0.14.0 should soon hit testing - same for lxqt-theme-debian
which will bring a proper theme with the right™ debian background, only
the metapackages need some adjustment right now)

Cheers Alf



Bug#921030: Fails to import the ansible module since its migration to Python 3

2019-02-10 Thread Samuel Henrique
Hello Gregory,

I would like to see the last version of ansible-lint shipped on Debian
Buster, thus I would like to fix this bug by uploading the last 4.0.1-1 to
unstable. It won't get to Buster before the release but as it will fix a RC
bug, it should be ok.

Are you fine with me fixing the problem? I would also like to add myself as
an uploader while doing so.

Thanks.

-- 
Samuel Henrique 


Bug#921972: lintian-brush: when d/compat is missing

2019-02-10 Thread Jelmer Vernooij
On Mon, Feb 11, 2019 at 12:14:41AM +, Jelmer Vernooij wrote:
> On Sun, Feb 10, 2019 at 07:08:52PM +, Dmitry Bogatov wrote:
> > By the way, it is quite unfortunate, that fixer API disallow early
> > sys.exit(0).
> Agreed, that would be good to fix. A workaround is to
> use sys.exit(2) to exit early without a description.
This should be fixed in master; a fixer can now not provide a description so
long as it doesn't make any changes.



Bug#921991: libregex-clojure: warning is printed when library is loaded

2019-02-10 Thread Elana Hashman
Package: libregex-clojure
Version: 1.1.0-2
Severity: minor

When libregex-clojure is loaded, the following warning is printed:


WARNING: cat already refers to: #'clojure.core/cat in namespace:
net.cgrand.regex, being replaced by: #'net.cgrand.regex/cat

I believe this behaviour is also present in the autopkgtests. The
upstream package does not do this, we should be consistent.


signature.asc
Description: PGP signature


Bug#921992: RM: python-mailmanclient python-mailmanclient-doc -- RoQA; NBS; builds only python3-mailmanclient

2019-02-10 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Hi,

please clean up the cruft from python-mailmanclient

python-mailmanclient |3.2.0-1 | all
python-mailmanclient-doc |3.2.0-2 | all

as of 3.2.0-3 only python3-mailmanclient is built.

Andreas



Bug#921991: libregex-clojure: warning is printed when library is loaded

2019-02-10 Thread Alex Miller
This is just a warning that there is name shadowing happening. Everything
will work as expected, so it's not a problem.

It's also easy to fix in the code in question by excluding the `cat` name
from clojure.core to avoid the shadowing, but it's not required.

Would just add cat to the list of excluded symbols here:
https://github.com/cgrand/regex/blob/master/src/net/cgrand/regex.clj#L5

I created a PR for it here: https://github.com/cgrand/regex/pull/9

Alex





On Sun, Feb 10, 2019 at 7:36 PM Elana Hashman  wrote:

> Package: libregex-clojure
> Version: 1.1.0-2
> Severity: minor
>
> When libregex-clojure is loaded, the following warning is printed:
>
>
> WARNING: cat already refers to: #'clojure.core/cat in namespace:
> net.cgrand.regex, being replaced by: #'net.cgrand.regex/cat
>
> I believe this behaviour is also present in the autopkgtests. The
> upstream package does not do this, we should be consistent.
> ___
> Pkg-clojure-maintainers mailing list
> pkg-clojure-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-clojure-maintainers


Bug#919477: Any reason why acl2 will not propagate now?

2019-02-10 Thread Camm Maguire
???

Take care,
-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



Bug#919982: apt-setup: preseeded installation hangs at "Use a network mirror?"

2019-02-10 Thread Steve McIntyre
[ Dropping Lucas from CC here... ]

Hi Wolfgang,

Finally getting back to this - it's been a busy couple of weeks...!

On Sat, Jan 26, 2019 at 11:24:40AM +0100, Wolfgang Schweer wrote:
>Hi Steve,
>
>On Fri, Jan 25, 2019 at 11:58:08PM +, Steve McIntyre wrote:
>> So I've been looking through this code again, and the corresponding
>> code in apt-setup that uses these values. Last time I played with
>> apt-setup, I added a table to describe what d-i will do based on the
>> information in cd_type, to explain exactly what d-i expects:
>> 
>> # Various different image types look different here:
>> #
>> # Image Type   cd_type
>> ###
>> # netinst  "not_complete"
>> # full CD sets (default desktop)   "full_cd"
>> # desktop-specific CD images   "full_cd/single"
>> # DVD  "dvd"
>> # bluray   "bluray"
>> # multi-arch CD/DVD"not_complete"
>> # live "live"
>
>Thanks for checking the code and providing this table.
>
>The Debian Edu BD image (bluray) is generated using COMPLETE=0, see: 
>https://salsa.debian.org/images-team/setup/blob/master/buster/cronjob.weekly#L268
> 
>because otherwise it turned out to be too big (~21 GiB).
>This image is intended for offline installations, no mirror useable.
>
>With this setting the Edu image differs from the stock BD/DLBD ones 
>where COMPLETE=0 is missing and the default (COMPLETE=1) takes effect, 
>see:
>https://salsa.debian.org/images-team/setup/blob/master/buster/cronjob.weekly#L169

Right.

>> The changes you've imported from the debian-edu fork of debian-cd
>> clearly don't match up with these, and that's a problem.
>
>Agreed; sorry for that.
>
>> We'll come back to this again shortly. To help with that, could you
>> describe exactly what debian-edu is expecting here please, i.e. what
>> the settings in cd_type mean for the debian-edu installer?
>
>I tried to understand the code that is used to write the content, see:
>https://salsa.debian.org/images-team/debian-cd/blob/master/tools/start_new_disc#L179
>
>If I understood correctly, for all cases with COMPLETE=0 the content of 
>cd_type is 'not_complete'.

Correct.

>If the EDU BD image has 'blueray/not_complete' then this content matches 
>the blueray*) case in apt-setup, see:
>https://sources.debian.org/src/apt-setup/1:0.145/generators/50mirror/#L104
>and the image is usable for offline installation.
>This is the only change that is actually needed for the Edu BD image.

Right - that's the information I was looking for. :-) If the Edu
images are doing nothing special (in terms of Edu setup) then that
makes life easier for me!

>Commit 
>https://salsa.debian.org/images-team/debian-cd/commit/15b482d49e642e21e983dba27a47b4fc2d8b90b4
>incorrectly altered the setting 'not_complete' to 'cd/not_complete' for 
>netinst, causing this bug. Sorry for not noticing it. 
>  
>> I'm worried that we may not have a clear solution here that can match 
>> the current expectations of both d-i and and the debian-edu setup.
>
>Hopefully I managed to clarify the Edu setup intention.

Definitely, thanks!

With a type of bluray/not_complete, we'll then get the following
behaviour from the current apt-setup code:

 * 41cdset will ask if you want to scan more media (the multi-line
   "if" code around L60 will *not* match)

 * 50mirror will *not* ask about using a mirror, as you say above
   (will match "bluray*" in L104

Is that what you're looking for? If not, we can tweak further to get
the right behaviour. To be fair, the interfaces here are not great,
and well overdue for some changes to make things clearer...

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



Bug#684432: Microsoft final Waring

2019-02-10 Thread Mohd Tarmize bin Ahmad




Update your account

Our record indicates that your account has not been updated, which may result 
in the closure of your account.
 If you do not update your account, you will no longer be able to send and 
receive emails, and also you will be
 denied access to many of our latest enhanced conversations, contacts, and 
attachments.
Take a minute to update your account for a faster and more complete mailing 
experience.

Click Here to Update your account
Note: Failure to update your mailbox will result in a permanent deletion of 
your account.

Many Thanks,
The security team

Copyright © 2018 Webmail .Inc . All rights reserved.



Bug#921996: guymager FTCBFS: uses wrong qmake, missing Build-Depends for lrelease

2019-02-10 Thread Helmut Grohne
Source: guymager
Version: 0.8.8-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

guymager fails to cross build from source, because it uses the wrong
qmake. For cross building we need to use -qmake on Debian
and that's what dh_auto_configure does. I note that the guymager
packaging uses an in-tree build. A lot of debian/rules' complexity (in
particular clean rules) could go away if dropping the --builddirectory
(in my patch).  It also fails running lrelease due to missing a
dependency on qt5-qmake:native. The attached patch fixes both (but
leaves the in-tree build). Please consider applying it.

Helmut
diff --minimal -Nru guymager-0.8.8/debian/changelog 
guymager-0.8.8/debian/changelog
--- guymager-0.8.8/debian/changelog 2018-08-30 13:38:17.0 +0200
+++ guymager-0.8.8/debian/changelog 2019-02-10 16:42:36.0 +0100
@@ -1,3 +1,12 @@
+guymager (0.8.8-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure use a cross qmake.
++ Missing Build-Depends: qt5-qmake:native for using lrelease.
+
+ -- Helmut Grohne   Sun, 10 Feb 2019 16:42:36 +0100
+
 guymager (0.8.8-2) unstable; urgency=medium
 
   * [7ffc3b5] Include patch to fix ftbfs with GCC-8. Thanks to Hilko
diff --minimal -Nru guymager-0.8.8/debian/control guymager-0.8.8/debian/control
--- guymager-0.8.8/debian/control   2018-03-22 10:15:15.0 +0100
+++ guymager-0.8.8/debian/control   2019-02-10 16:42:36.0 +0100
@@ -13,6 +13,7 @@
  libprocps-dev,
  libssl-dev,
  libudev-dev,
+ qt5-qmake:native,
  qtbase5-dev,
  qttools5-dev-tools,
  quilt,
diff --minimal -Nru guymager-0.8.8/debian/rules guymager-0.8.8/debian/rules
--- guymager-0.8.8/debian/rules 2018-05-18 10:27:32.0 +0200
+++ guymager-0.8.8/debian/rules 2019-02-10 16:42:34.0 +0100
@@ -3,6 +3,7 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
+export QT_SELECT=qt5
 
 %:
dh $@
@@ -10,7 +11,7 @@
 override_dh_auto_configure:
dh_quilt_patch
dh_testdir
-   qmake -qt5 DEFINES+="SPLASH_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR_QT=\'\\\"/usr/share/qt5/translations\\\"\'"
+   dh_auto_configure --builddirectory=. -- 
DEFINES+="SPLASH_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR_QT=\'\\\"/usr/share/qt5/translations\\\"\'"
touch configure-stamp
 
 override_dh_auto_build:
@@ -27,7 +28,7 @@
rm -f build-stamp configure-stamp
# dpkg-buildpackage starts with cleaning, so we have to be sure that 
there's a
# Makefile (and thus call qmake):
-   qmake -qt5
+   dh_auto_configure --builddirectory=.
$(MAKE) clean
# remove leftover files:
rm -f .qmake.stash compileinfo.cpp manuals/guymager.1


Bug#874276: ca-certificates-java: fails to install on armhf: Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'

2019-02-10 Thread Andreas Beckmann
Followup-For: Bug #874276

Let's try to fix this in ca-certificates-java for stretch, the openjdk-8
fix does not seem to be effective for stretch.
https://bugs.debian.org/921997


Andreas



Bug#922004: transition: clamav

2019-02-10 Thread Scott Kitterman
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Even though we are after the transition deadline, we would like to have
permission to go ahead with the clamav transition.  Typically we keep clamav
updated in stable for effectiveness reasons and we plan to do the same now.
In order to do that, we need to do sid/buster first.

Status of preparations:

clamav 0.101.1+dfsg-2 is in experimental and has built on all release archs
for which it has been tried (it's been waiting a week for mips64el/mipsel).

It's ready for unstable/buster.

rdepends:

dansguardian (still and issue for stable, but removed from unstable/buster),
maintianed fork e2guardian uses clamd, not libclamav, so not an issue.

libclamunrar: Update split from clamav source and uploaded to experimental.

python-clamav: Source changes needed.  Patched version uploaded to
experimental.

havp: Source changes needed.  New upstream release with fixes uploaded to
experimental (upstream only incorporates Debian patches and this change).

c-icap-modules: binNMU only - tested rebuild locally.

pg-snakeoil: binNMU only - tested rebuild locally.


Ben file (note: this is what reportbug generated, the auto one is fine):

title = "clamav";
is_affected = .depends ~ "libclamav7" | .depends ~ "libclamav9";
is_good = .depends ~ "libclamav9";
is_bad = .depends ~ "libclamav7";

Note that for the packages that need sourceful uploads, I am an uploader, so
no external maintainer coordination is required.

Scott K



Bug#922005: RM: mash [mips mips64el mipsel s390x hppa hurd-i386 ia64 powerpc ppc64 sparc64] -- ROM; Does not build on all architectures due to new Build-Depends

2019-02-10 Thread Andreas Tille
Package: ftp.debian.org
Severity: normal

Hi,

due to the new dependency libmurmurhash which is not yet build on all
architectures mash is not build on all architectures where it has build
before.  The background is that the new version of mash (as many other
Debian packages) was shipping a code copy of libmurmurhash which was
even less portable than the libmurmurhash package.  There is work
ongoing to make libmurmurhash building on all supported architectures
but since we are approaching the freeze this will not happen right in
time.  So please remove the said architectures for the time beeing to
enable mash migrating to testing.

Thank you for your work as ftpmaster

   Andreas.



Bug#922003: RFS: blastem/0.6.2.1-1 -- Fast and accurate Genesis emulator

2019-02-10 Thread Carlos Donizete Froes
Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: blastem
   Version : 0.6.2.1-1
   Upstream Author : Michael Pavone 
 * URL : https://www.retrodev.com/blastem
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  blastem - Fast and accurate Genesis emulator

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.2.1-1.dsc

  More information about BlastEm can be obtained from 
https://gitlab.com/coringao/blastem.

  Changes since the last upload:

  blastem (0.6.2.1-1) unstable; urgency=medium

  * New upstream release
  * Fixed the FTBFS due to enabled hardening build flags

  Regards,
   Carlos Donizete Froes [a.k.a coringao]



Bug#919356: Licensing of include/linux/hash.h

2019-02-10 Thread Domenico Andreoli
On Mon, Feb 11, 2019 at 12:08:32AM +0100, Kristian Fiskerstrand wrote:
> On 1/23/19 9:50 AM, Domenico Andreoli wrote:
> > Ben Finney  writes:
> >> Domenico Andreoli  writes:

[...]

> >>> the only knot left is now the license of hash.h
> >>>
> >>> This file is also present in the kernel [0] with an updated copyright
> >>> but still without license.

[...]

> >> To know that work (that file) is free software, we need a clear grant of
> >> some specific license, for that work.
> >>
> >> If the work is not free, it would be incorrect to have the work in Debian.
> > 
> > Is it possible that for the kernel it is instead correct because it is,
> > as whole, covered by its COPYING?
> > 
> >> Alternatives, for complying with the Debian Free Software Guidelines with
> >> this package, include:
> >>
> >> * Find a credible grant of license under some GPL-compatible free
> >>   license to that exact file. Document that explicit grant in the Debian
> >>   package. This demonstrates the work is DFSG-free.
> >>
> >> * Convince ???dwarves-dfsg??? upstream to replace that file with a 
> >> different
> >>   implementation (I don't know whether such an implementation exists)
> >>   under a license compatible with the same version of GNU GPL. Document
> >>   that explicit grant in the Debian package. This demonstrates the
> >>   modified work is DFSG-free.
> >>
> >> * Replace that file in Debian only, with a different implementation as
> >>   above. Document that explicit grant in the Debian package. This
> >>   demonstrates the modified Debian package is DFSG-free.
> >>
> >> * Move the work to the ???non-free??? area.
> >>
> >> * Remove the work altogether.
> >>
> >> Those are in descending order of (my recommended) preference.

[...]

> It was [pointed out] by one of our license group that [hash.h]  is the
> same that has a GPL-2+ in [fio] which has a signed-off-by.
> 
> References:
> [pointed out]
> https://bugs.gentoo.org/677586#c1
> 
> [hash.h]
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c

Yes, the Signed-off-by is from Jens Axboe (in CC) but he's not the
original author, I guess he just copied the file as Arnaldo did. The
file he committed has not any reference to the license.

> [fio]
> https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright

I'm afraid that this entry in wrong. I'll seek confirmation with Martin 
Steigerwald.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature


Bug#922006: please move dkimpy-milter to python3

2019-02-10 Thread Daniel Kahn Gillmor
Package: dkimpy-milter
Version: 1.0.0-1

Hi Scott--

I see that python3-milter exists now.  it would be great to move
dkimpy-milter to python3 as well, so that mailserver administrators
using dkimpy-milter don't need to have python2 installed.

If you want a hand with the transition, i'd be happy to help.

Regards,

  --dkg


signature.asc
Description: PGP signature


Bug#891434: grub-efi: System fails to boot after "No space left on device" on EFI variable storage

2019-02-10 Thread Niels Thykier
On Fri, 14 Dec 2018 10:22:49 +0100 Ralf Jung  wrote:
> Hi,
> 
> > Fixing this does seem like it would be a good idea for general
> > robustness against dodgy firmware (this is not the first iteration of
> > problems along these lines).  It would take some development work, but
> > hopefully not too much.
> > 
> > Things that GRUB can't do, as far as I can tell:
> > 
> >  * I don't think there's a way for GRUB to check whether it will be
> >possible to recreate a boot entry later; as I understand it, that
> >depends on various low-level details, including firmware-specific
> >quirks.
> >
> >  * Even detecting that nothing changed would require cooperation from
> >efibootmgr, since the encoding of the EFI variable is an
> >implementation detail there (so we can't just read it out and
> >compare), and efibootmgr doesn't expose a way for GRUB to say "set
> >this configuration, but only if it's different from what's already
> >there".
> > 
> > However, I think GRUB can at least manage to delete all but one entry
> > from the same distributor rather than all of them, and if it finds one
> > remaining entry then it can modify that rather than writing a brand new
> > variable.  As I understand it, that would probably be enough to fix this
> > bug?
> 
> Assuming that modification works even when the variable storage is (close to)
> full, then yes, that would at least keep the device bootable which would be a
> big improvement.
> 
> Kind regards,
> Ralf
> 
> 

Hi Colin,

Thanks for proposing this solution. :)

I also think it would be a good solution for now that will hopefully
avoid most of these errors. :)

Thanks,
~Niels



Bug#921439: matrix-synapse: Delete self-signed certificates during upgrade to version 0.99

2019-02-10 Thread Joseph Nuthalapati
Dear maintainer,

After going through the detailed documentation[1] on how the
matrix-synapse ACME client works, I found that obtaining certificates
using it is neither as automatic or easy as I expected.

Since deleting the self-signed certificates isn't the only step
involved, we should let the administrator handle the upgrade to 0.99 or
1.0. Reusing the server's Let's Encrypt certificate is provided as an
alternate option (which is what I'm planning to do in my case).

Automatically deleting the certificates during the Debian package
installation seems like a bad idea. I will close this issue.

1. https://github.com/matrix-org/synapse/blob/master/docs/ACME.md

-- 
Regards,
Joseph Nuthalapati




signature.asc
Description: OpenPGP digital signature


Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

2019-02-10 Thread Mykola Nikishov
Carsten Schoenert  writes:

> Instead of discussing the severity of the bug report it would be more
> helpful

It is much more helpful to read original message in full:

> Yes, it uses 4 OpenSans-*.ttf fonts. fonts-open-sans already provides
> these fonts and is about 2 Mbytes in size.

> I've submitted PR 
> https://salsa.debian.org/webext-team/lightbeam/merge_requests/1

and only then hit 'Reply'.

-- 
Mykola

Libre/Free Java Software Engineer
https://manandbytes.gitlab.io/



Bug#921439: matrix-synapse: Delete self-signed certificates during upgrade to version 0.99

2019-02-10 Thread Joseph Nuthalapati
Closing since the suggested fix is unsafe and incomplete.

-- 
Regards,
Joseph Nuthalapati




signature.asc
Description: OpenPGP digital signature


<    1   2   3