Bug#934950: dafny: unsatisfiable build-dependency in sid

[Benjamin Barenblat]

Having dafny drop out of the archive would be fine with me – I’ve had an
active RFA out for over a year (https://bugs.debian.org/903143), and
nobody seems interested. I’ll officially orphan it and request ftpmaster
removal.

Bug#934964: RFP: afl++ -- security related binary fuzzer (fork of American Fuzzy Lop)

[Daniel Stender]

Package: wnpp
Severity: wishlist

* Package name: afl++
  Version : 2.53c
  Upstream Author : Marc Heuse 
* URL : https://github.com/vanhauser-thc/AFLplusplus
* License : Apache-2.0
  Programming Lang: C
  Description : security related binary fuzzer (fork of American Fuzzy Lop)

This is a fork of American Fuzzy Lop [1], which isn't actively further developed
anymore [2]. The latest release of AFL++ includes a lot new features, fixes and
improvements.

Packaging this would replace AFL in the Debian archive [3], which doesn't build 
with
LLVM >= 7 [4], and therefore is going to be removed so that LLVM 6 could be 
finally
dropped.

Thanks,
Daniel Stender

[1] https://github.com/google/afl

[2] https://twitter.com/Dor3s/status/1154737061787660288

[3] https://tracker.debian.org/pkg/afl

[4] https://bugs.debian.org/912785

Bug#892264: Hy 0.17.0

[Tristan Seligmann]

Go for it! Maintainer should probably be DPMT anyway.

On Sat, 17 Aug 2019 at 01:31, Tianon Gravi  wrote:

> On Tue, 4 Jun 2019 at 16:59, Tianon Gravi  wrote:
> > I've updated Git with what I think is finally successful packaging of
> > a newer Hy version (0.17.0 ATM).  It requires updated "python-astor"
> > (I tested 0.8.0) and "python-rply" (I tested 0.7.7), which I don't
> > have time to chase down properly right now.
>
> Hi Tristan!  To this end (getting Hy 0.17.0 in the archive) I've
> updated Git for "python-rply" to 0.7.7 (from 0.7.4), but I wanted to
> reach out before uploading to check whether you're OK with this
> version bump?
>
> (You're the human listed in Maintainer/Uploaders :D)
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
>


-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Bug#934963: ITP: libio-interactive-tiny-perl -- minimalist utility module for interactive I/O

[Clement Hermann]

Package: wnpp
Owner: Clément Hermann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libio-interactive-tiny-perl
  Version : 0.2
  Upstream Author : Daniel Muey 
* URL : https://metacpan.org/release/IO-Interactive-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : minimalist utility module for interactive I/O

IO::Interactive::Tiny provides the useful subset of IO::Interactive’s
functionality in the form of only having is_interactive().

It also gains ::Tiny-ness by reducing large deps: it doesn not use version,
Carp, or Scalar::Util

The package will be maintained under the umbrella of the Debian Perl Group.

Note: this module's main purpose in Debian is to avoid using embedding copies of
this module at build time.
--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#934962: syncthing: FTBFS with 'build cache is disabled by GOCACHE=off, but required as of Go 1.12'

[Bruno Kleinert]

Package: syncthing
Version: 1.1.4~ds1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

I tried to rebuild the package with sbuild+schroot in a sid environment. It
fails however:

[…]
cd _build/src/github.com/syncthing/syncthing && go run script/genassets.go gui
> lib/auto/gui.files.go
build cache is disabled by GOCACHE=off, but required as of Go 1.12
make[1]: *** [debian/rules:54: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:34: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
[…]

I'm unfamiliar with Go and a naive attempt to just comment out 'export GOCACHE
:= on' in debian/rules didn't fix it :)

Cheers - Bruno



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

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

Versions of packages syncthing depends on:
ii  libc6  2.28-10

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on flutschi

+==+
| syncthing 1.1.4~ds1-2 (amd64)Sat, 17 Aug 2019 10:38:00 + |
+==+

Package: syncthing
Version: 1.1.4~ds1-2
Source Version: 1.1.4~ds1-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-20f91603-84b7-4313-bf4f-79a22bee8ce0' with 
'<>'
I: NOTICE: Log filtering will replace 'build/syncthing-1MZIJj/resolver-fVddDr' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/srv/mirror/debian sid InRelease [149 kB]
Get:1 file:/srv/mirror/debian sid InRelease [149 kB]
Get:2 file:/srv/mirror/debian sid/main amd64 Packages [8431 kB]
Ign:2 file:/srv/mirror/debian sid/main amd64 Packages
Get:2 file:/srv/mirror/debian sid/main amd64 Packages [8431 kB]
Get:3 https://cdn-aws.deb.debian.org/debian sid InRelease [149 kB]
Fetched 149 kB in 1s (136 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/fuddl/debian/syncthing/syncthing_1.1.4~ds1-2.dsc exists in 
/home/fuddl/debian/syncthing; copying to chroot
I: NOTICE: Log filtering will replace 
'build/syncthing-1MZIJj/syncthing-1.1.4~ds1' with '<>'
I: NOTICE: Log filtering will replace 'build/syncthing-1MZIJj' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 10), dh-exec, dh-golang, golang-any, 
genxdr, golang-github-rcrowley-go-metrics-dev, 
golang-github-prometheus-client-golang-dev (>= 0.9.0), 
golang-github-bkaradzic-go-lz4-dev, golang-golang-x-text-dev, 
golang-golang-x-net-dev, golang-golang-x-crypto-dev, 
golang-github-calmh-du-dev, golang-github-calmh-luhn-dev, 
golang-github-calmh-xdr-dev, golang-github-thejerf-suture-dev (>= 3.0.0), 
golang-github-juju-ratelimit-dev, golang-github-vitrun-qart-dev, 
golang-github-syndtr-goleveldb-dev, golang-github-gobwas-glob-dev (>= 0.2.1), 
golang-github-jackpal-gateway-dev, 
golang-github-audriusbutkevicius-go-nat-pmp-dev, 
golang-github-d4l3k-messagediff-dev, golang-github-cznic-ql-dev, 
golang-github-golang-groupcache-dev, golang-github-oschwald-geoip2-golang-dev, 
golang-gogoprotobuf-dev (>= 1.2.1+git20190611.dadb6258), 
golang-github-lib-pq-dev, golang-github-minio-sha256-simd-dev, 
golang-github-xtaci-kcp-dev, golang-github-xtaci-smux-dev, 
golang-github-audriusbutkevicius-pfilter-dev, golang-github-ccding-go-stun-dev, 
golang-github-chmduquesne-rollinghash-dev (>= 4.0.0), golang-golang-x-time-dev, 

Bug#886884: zsh crashes when it receives a SIGQUIT signal while saving the history

[Vincent Lefevre]

Control: retitle -1 zsh sometimes crashes when it receives a SIGQUIT signal
Control: found -1 5.7.1-1
Control: tags -1 upstream

On 2018-01-10 23:07:58 +0100, Vincent Lefevre wrote:
> zsh crashes when it receives a SIGQUIT signal while saving the history.
> Thus one loses the session data.

zsh still crashed after a SIGQUIT. The command was "svn log | m",
where svn is an alias to an external command and m an alias to a
function executing "less". The "less" command had terminated, and
I was doing Ctrl-C then Ctrl-\ to interrupt the "svn log", which
crashed zsh. I could not find a core dump.

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

Bug#934961: insserv breaks startpar autopkgtest

[Paul Gevers]

Source: insserv, startpar
Control: found -1 insserv/1.20.0-2
Control: found -1 startpar/0.63-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent (one month old) upload of insserv the autopkgtest of
startpar fails in testing when that autopkgtest is run with the binary
packages of insserv from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
insservfrom testing1.20.0-2
startpar   from testing0.63-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of insserv to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package? If needed, please change the
bug's severity.

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=insserv

https://ci.debian.net/data/autopkgtest/testing/amd64/s/startpar/2751621/log.gz

Setting up insserv (1.20.0-2) ...
insserv: FATAL: service mountkernfs has to exist for service networking
insserv: FATAL: service urandom has to exist for service networking
insserv: FATAL: service mountdevsubfs has to exist for service hwclock
insserv: exiting now!
Setting up autopkgtest-satdep (0) ...
(Reading database ... 12357 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [02:13:15]: test testsuite: [---
make: Entering directory
'/tmp/autopkgtest-lxc.gu4ek7wq/downtmp/build.cYi/src/testsuite'
STARTPAR=/lib/startpar/startpar ./runtests
insserv: fopen(/etc/init.d/.depend.boot): Permission denied
error: the test init.d was not running
error: the ls command was not running
make: Leaving directory
'/tmp/autopkgtest-lxc.gu4ek7wq/downtmp/build.cYi/src/testsuite'
autopkgtest [02:13:15]: test testsuite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#934960: python-mock breaks pytest-mock autopkgtest

[Paul Gevers]

Source: python-mock, pytest-mock
Control: found -1 python-mock/3.0.5-1
Control: found -1 pytest-mock/1.7.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of python-mock the autopkgtest of pytest-mock fails
in testing when that autopkgtest is run with the binary packages of
python-mock from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
python-mockfrom testing3.0.5-1
pytest-mockfrom testing1.7.1-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of python-mock to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package? If needed, please change the
bug's severity.

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=python-mock

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pytest-mock/2752732/log.gz
=== FAILURES
===
___ TestMockerStub.test_failure_message_with_no_name
___

self = 
mocker = 

def test_failure_message_with_no_name(self, mocker):
>   self.__test_failure_message(mocker)

test_pytest_mock.py:189:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
mocker = , kwargs = {}
expected_name = 'mock', expected_message = 'Expected call: mock()\nNot
called'
stub = 
exc_info = 

def __test_failure_message(self, mocker, **kwargs):
expected_name = kwargs.get('name') or 'mock'
expected_message = 'Expected call: {0}()\nNot
called'.format(expected_name)
stub = mocker.stub(**kwargs)
with pytest.raises(AssertionError) as exc_info:
stub.assert_called_with()
>   assert str(exc_info.value) == expected_message
E   AssertionError

test_pytest_mock.py:186: AssertionError
_ TestMockerStub.test_failure_message_with_name[None]
__

self = 
mocker = , name = None

@pytest.mark.parametrize('name', (None, '', 'f', 'The Castle of
aaaggh'))
def test_failure_message_with_name(self, mocker, name):
>   self.__test_failure_message(mocker, name=name)

test_pytest_mock.py:193:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
mocker = 
kwargs = {'name': None}, expected_name = 'mock'
expected_message = 'Expected call: mock()\nNot called'
stub = 
exc_info = 

def __test_failure_message(self, mocker, **kwargs):
expected_name = kwargs.get('name') or 'mock'
expected_message = 'Expected call: {0}()\nNot
called'.format(expected_name)
stub = mocker.stub(**kwargs)
with pytest.raises(AssertionError) as exc_info:
stub.assert_called_with()
>   assert str(exc_info.value) == expected_message
E   AssertionError

test_pytest_mock.py:186: AssertionError
___ TestMockerStub.test_failure_message_with_name[]


self = 
mocker = , name = ''

@pytest.mark.parametrize('name', (None, '', 'f', 'The Castle of
aaaggh'))
def test_failure_message_with_name(self, mocker, name):
>   self.__test_failure_message(mocker, name=name)

test_pytest_mock.py:193:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
mocker = 
kwargs = {'name': ''}, expected_name = 'mock'
expected_message = 'Expected call: mock()\nNot called'
stub = 
exc_info = 

def __test_failure_message(self, mocker, **kwargs):
expected_name = kwargs.get('name') or 'mock'
expected_message = 'Expected call: {0}()\nNot
called'.format(expected_name)
stub = mocker.stub(**kwargs)
with pytest.raises(AssertionError) as exc_info:
stub.assert_called_with()
>   assert str(exc_info.value) == expected_message
E   AssertionError

test_pytest_mock.py:186: AssertionError
___ TestMockerStub.test_failure_message_with_name[f]
___

self = 
mocker = , name = 'f'

@pytest.mark.parametrize('name', (None, '', 'f', 'The Castle of
aaaggh'))
def test_failure_message_with_name(self, mocker, name):
>   self.__test_failure_message(mocker, name=name)

test_pytest_mock.py:193:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
mocker = 
kwargs = {'name': 'f'}, expected_name = 'f'
expected_message = 'Expected call: f()\nNot called'
stub = 
exc_info = 

def __test_failure_message(self, mocker, **kwargs):
expected_name = kwargs.get('name') or 'mock'
expected_message = 'Expected call: 

Bug#934959: python-mock breaks sunpy autopkgtest

[Paul Gevers]

Source: python-mock, sunpy
Control: found -1 python-mock/3.0.5-1
Control: found -1 sunpy/0.9.6-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent (one month old) upload of python-mock the autopkgtest of
sunpy fails in testing when that autopkgtest is run with the binary
packages of python-mock from unstable. It passes when run with only
packages from testing. In tabular form:
   passfail
python-mockfrom testing3.0.5-1
sunpy  from testing0.9.6-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. (On top of
that, there are *loads* of deprecation warnings, the maintainer of sunpy
probably wants to look into that).

Currently this regression is blocking the migration of python-mock to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package? If needed, please change the
bug's severity.

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=python-mock

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sunpy/2748790/log.gz

=== FAILURES
===
 test_parse_obssumm_dbase_file
_

def test_parse_obssumm_dbase_file():
"""
Ensure that all required data are extracted from the RHESSI
observing summary database file mocked in `hessi_data()`
"""
mock_file = mock.mock_open()
mock_file.return_value.__iter__.return_value = hessi_data()

dbase_data = {}
with mock.patch('sunpy.instr.rhessi.open', mock_file, create=True):
>   dbase_data = rhessi.parse_obssumm_dbase_file(None)

/usr/lib/python3/dist-packages/sunpy/instr/tests/test_rhessi.py:206:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

filename = None

def parse_obssumm_dbase_file(filename):
"""
Parse the RHESSI observing summary database file. This file
lists the
name of observing summary files for specific time ranges along
with other
info

Parameters
--
filename : `str`
The filename of the obssumm dbase file.

Returns
---
out : `dict`
Return a `dict` containing the parsed data in the dbase file.

Examples

>>> import sunpy.instr.rhessi as rhessi
>>> fname, _ = rhessi.get_obssumm_dbase_file(('2011/04/04',
'2011/04/05'))   # doctest: +REMOTE_DATA
>>> file_names = rhessi.parse_obssumm_dbase_file(fname)   #
doctest: +REMOTE_DATA
>>> file_names['filename'][::5]   # doctest: +REMOTE_DATA
['hsi_obssumm_20110401_043.fit', 'hsi_obssumm_20110406_041.fit',
'hsi_obssumm_20110411_024.fit', 'hsi_obssumm_20110416_016.fit',
'hsi_obssumm_20110421_025.fit', 'hsi_obssumm_20110426_022.fit']

References
--
|
https://hesperia.gsfc.nasa.gov/ssw/hessi/doc/guides/hessi_data_access.htm#Observing%20Summary%20Data

.. note::
This API is currently limited to providing data from whole
days only.

"""
# An example dbase file can be found at:
#
https://hesperia.gsfc.nasa.gov/hessidata/dbase/hsi_obssumm_filedb_200311.txt

with open(filename) as fd:
reader = csv.reader(fd, delimiter=' ', skipinitialspace=True)
>   _ = next(reader)  # skip 'HESSI Filedb File:' row
E   StopIteration

/usr/lib/python3/dist-packages/sunpy/instr/rhessi.py:145: StopIteration



signature.asc
Description: OpenPGP digital signature

Bug#934958: sqlalchemy breaks osmalchemy (autopkgtest)

[Paul Gevers]

Source: sqlalchemy, osmalchemy
Control: found -1 sqlalchemy/1.3.5+ds1-2
Control: found -1 osmalchemy/0.1.+3-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent (one month old) upload of sqlalchemy the autopkgtest of
osmalchemy fails in testing when that autopkgtest is run with the binary
packages of sqlalchemy from unstable. It passes when run with only
packages from testing. In tabular form:
   passfail
sqlalchemy from testing1.3.5+ds1-2
osmalchemy from testing0.1.+3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems this
changes completely broke osmalchemy as it doesn't init.

Currently this regression is blocking the migration of sqlalchemy to
testing [1] (although that needs a source-only upload nowadays as well).
Due to the nature of this issue, I filed this bug report against both
packages. Can you please investigate the situation and reassign the bug
to the right package? If needed, please change the bug's severity.

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=sqlalchemy

https://ci.debian.net/data/autopkgtest/testing/amd64/o/osmalchemy/2748426/log.gz

autopkgtest [12:12:40]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import osmalchemy; print(osmalchemy)" ; done
autopkgtest [12:12:40]: test autodep8-python3: [---
Testing with python3.7:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/osmalchemy/__init__.py", line 8,
in 
monkey_patch_sqlalchemy()
  File "/usr/lib/python3/dist-packages/osmalchemy/util/patch.py", line
39, in monkey_patch_sqlalchemy
orig_any = AssociationProxy.any
AttributeError: type object 'AssociationProxy' has no attribute 'any'
autopkgtest [12:12:40]: test autodep8-python3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#880156:

[Dawid Dziurla]

What's the current status?

Bug#934957: cups: multiple security issues (including CVEified CVE-2019-8675 and CVE-2019-8696)

[Salvatore Bonaccorso]

Source: cups
Version: 2.2.10-6
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

Filling for tracking. The recent 2.2.12[1] release includes fixes for
several security issues, two of those got CVEs and are related to SNMP
buffer overflows. [2] includes all those.

Regards,
Salvatore

 [1] https://github.com/apple/cups/releases/tag/v2.2.12
 [2] 
https://github.com/apple/cups/commit/f24e6cf6a39300ad0c3726a41a4aab51ad54c109

Bug#934810: aspell 0.60.7 available

[Agustin Martin]

Control: tag -1 +pending

El jue., 15 ago. 2019 a las 11:48, Sebastien Bacher
() escribió:
>
> Package: aspell
> Version: 0.60.7~20110707-6
>
> There is a new bugfix version available, could we get it uploaded to Debian?
> http://aspell.net/aspell-0.60.7.txt

Thanks for reminding.

I read apell-devel and was aware of this new release. Just that there
were more differences than expected with previous version and I wanted
to look better at them and guess what they fix before uploading.

Regards,

Bug#931884: pkg-kde-tools: References soon to be removed dh_gconf tool in qt-kde-team/{2,3}/commands

[Niels Thykier]

On Thu, 11 Jul 2019 21:59:56 +0200 Niels Thykier  wrote:
> Package: qt-kde-team
> Version: 0.15.29
> Severity: important
> Control: block 908845 by -1
> 
> 
> Hi,
> 
> Per Jeremy Bicha request, we are expecting to remove dh_gconf during
> the Bullseye release cycle.  Unfortunately, pkg-kde-tools appears to
> depend on this tool via its commands files:
> 
> """
> [...]
>   dh_installxfonts
>   dh_bugfiles
>   dh_lintian
>   dh_gconf
>   dh_icons
>   dh_perl
>   dh_usrlocal
> [...]
> """
> 
> https://sources.debian.org/src/pkg-kde-tools/0.15.29/qt-kde-team/2/commands/?hl=61#L61
> https://sources.debian.org/src/pkg-kde-tools/0.15.29/qt-kde-team/3/commands/?hl=61#L61
> 
> 
> Please remove this unconditional reference for Bullseye.
> 
> Thanks,
> ~Niels
> 
> 

Hi pkg-kde-tools maintainers,

Do you have an update on this bug?  AFAICT, pkg-kde-tools is now the
last package referencing dh_gconf.  I would prefer that it was fixed
before I upload a version of debhelper without dh_gconf.

Thanks,
~Niels

Bug#934956: buster-pu: package cryptsetup/2:2.1.0-5+deb10u1

[Guilhem Moulin]

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

Dear release team,

Buster's cryptsetup (2:2.1.0-5) doesn't cope well with LUKS2 headers
without any bound keyslot: adding a new key slot to such a header fails,
both via the crypt_keyslot_add_by_volume_key() API call and with
`luksAddKey --master-key`.

This alone doesn't warrant a s-p-u, but some applications seem to use
the following sequences of API calls to change a passphrase:

keyslot = crypt_volume_key_get(cd, …, volume_key, old_passphrase);
crypt_keyslot_destroy(cd, keyslot);
crypt_keyslot_add_by_volume_key(cd, 0, volume_key, new_passphrase);

This is a *very* bad idea in the first place, and they should use
crypt_keyslot_change_by_passphrase() instead: if there was only one
active keyslot and for some reason the crypt_keyslot_add_by_volume_key()
call fails (for instance due to an hardware failure, or because the
PBKDF benchmark triggers the OOM killer) then the entire volume is lost…
However the libcryptsetup bug makes it much, much worse as the call
*always* fails on LUKS2 headers without any bound keyslot.  This is what
happened in #928893 (gnome-disk-utility: disk content permanently lost
when changing LUKS password).

Using codesearch.d.n I found that (as far as sid is concerned) beside
src:cryptsetup, only src:libblockdev and src:cryptmount are calling
crypt_keyslot_destroy().  AFAICT src:cryptmount is making a sane use of
the call [0]; libblockdev is affected in Buster but per #932588 will be
fixed to use crypt_keyslot_change_by_passphrase() in the upcoming point
release.  Still there might be third party programs we don't know about,
and considering the serious risk of data loss I think it makes sense to
fix the libcryptsetup bug in the next point release, too.  Changelog
since 2:2.1.0-5 is as follows, and debdiff attached.

cryptsetup (2:2.1.0-5+deb10u1) buster; urgency=high

  * Backport upstream commits c03e3fe8, 725720df and fe4e1de5 to fix support
for LUKS2 headers without any bound keyslot.  Adding a new key slot using
the volume key was failing, both via the crypt_keyslot_add_by_volume_key()
API call and with `luksAddKey --master-key`.  The former in particular
might yield data loss if, in order to change a passphrase, an application
destroys the keyslot before adding a new one (using the volume key), cf.
#928893.  Note that doing so is *unsafe*: applications should instead use
crypt_keyslot_change_by_passphrase() from libcryptsetup >=1.6.0.
Trying to open LUKS2 volume by supplying the volume key on the command
line was also failing if there were no bound keyslot on the header.
(Closes: #934715)

 -- Guilhem Moulin   Fri, 16 Aug 2019 19:18:10 +0200

The 3 cherry-picked patches are all backported from 2.2.0 [1,2], and the
version in sid is not affected.  (The one in Stretch is not affected
either as it doesn't have LUKS2 support.)  The diff also includes unit
tests, but note that the tests in question need root access hence are
ignored by the build daemons.  I did ensure that the whole test-suite
still passes on amd64, though.

In case you're unhappy with this changeset, then I propose to only
include the first 2 patches.  IMHO what should really be fixed in Buster
is the libcryptsetup part.  For the CLI part (third patch) the risk of
data loss is lower as the volume key is stored in a file.

Thanks for considering its inclusion in Buster!  CC'ing KiBi for the d-i ack.
Cheers,
-- 
Guilhem.

[0] 
https://codesearch.debian.net/show?file=cryptmount_5.3.1-1%2Farmour-luks.c=247
[1] https://gitlab.com/cryptsetup/cryptsetup/issues/466
[2] https://gitlab.com/cryptsetup/cryptsetup/issues/470
diffstat for cryptsetup-2.1.0 cryptsetup-2.1.0

 changelog  |   16 +
 gbp.conf   |1 
 patches/Fix-getting-default-LUKS2-keyslot-encryption-paramet.patch |   56 
++
 patches/Fix-volume-key-file-if-no-LUKS2-keyslots-are-present.patch |   86 
++
 patches/Mention-limitation-of-crypt_get_volume_key_size.patch  |   20 ++
 patches/series |3 
 6 files changed, 182 insertions(+)

diff -Nru cryptsetup-2.1.0/debian/changelog cryptsetup-2.1.0/debian/changelog
--- cryptsetup-2.1.0/debian/changelog   2019-06-10 14:51:15.0 +0200
+++ cryptsetup-2.1.0/debian/changelog   2019-08-16 19:18:10.0 +0200
@@ -1,3 +1,19 @@
+cryptsetup (2:2.1.0-5+deb10u1) buster; urgency=high
+
+  * Backport upstream commits c03e3fe8, 725720df and fe4e1de5 to fix support
+for LUKS2 headers without any bound keyslot.  Adding a new key slot using
+the volume key was failing, both via the crypt_keyslot_add_by_volume_key()
+API call and with `luksAddKey --master-key`.  The former in particular
+might yield data loss if, in order to change a passphrase, an application
+  

Bug#888262: dh_strip: include debug symbols for binary maintainer "scripts"

[Niels Thykier]

Control: tags -1 wontfix

On Wed, 24 Jan 2018 13:37:40 +0100 Ansgar Burchardt 
wrote:
> Package: debhelper
> Version: 11.1.2
> Severity: wishlist
> 
> dh_strip should also include debug symbols for maintainer "scripts"
> that are binary programs in the *-dbgsym packages.
> 
> The only example I'm aware of is dash (preinst).
> 
> Ansgar
> 
> 

Hi,

I am going with a wontfix on this for now as I feel uncomfortable
deciding this unilaterally given my own observations above:

 * dash has removed its preinst script[1], so there is no longer any
   known benefit of doing this.

 * Reshuffling this part of the sequence is likely to break a lot of
   addons and packages (e.g. any addon relying on a dh_foo being able
   to insert maintscripts when injected before/after dh_strip can will
   silently do the wrong thing).  While it would obviously be done in a
   compat level, it would be a lot of churn to complete this transition.

 * It is "trivially" possible to manually override this part of the
   sequence via 3 overrides if there are still packages that need
   this[2].

Feel free to punt this to d-devel or tech-ctte[3].  If either of those
shows (rough) consensus that this change is a good trade-off or "the
right thing to do(tm)", then I am happy to implement it.

Thanks,
~Niels

[1]
https://salsa.debian.org/debian/dash/commit/020393f77a74ded57ee1bc3f1389ea0833dc5b09

[2] A la:


"""
override_dh_dwz override_dh_strip:

override_dh_installdeb:
dh_installdeb
dh_dwz
dh_strip
"""

[3] Constitutional note if tech-ctte is involved: I would consider it
"advice" and *not* an override of my decision (i.e. regular majority
would be fine).

Bug#934955: golang-1.13: CVE-2019-9512 CVE-2019-9514

[Salvatore Bonaccorso]

Source: golang-1.13
Version: 1.13~beta1-2
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/golang/go/issues/33606

Hi,

The following vulnerabilities were published for golang-1.13. The
recent issues exits as well in the current present version of
golang-1.13 in unstable and bullseye.

CVE-2019-9512[0]:
| Some HTTP/2 implementations are vulnerable to ping floods, potentially
| leading to a denial of service. The attacker sends continual pings to
| an HTTP/2 peer, causing the peer to build an internal queue of
| responses. Depending on how efficiently this data is queued, this can
| consume excess CPU, memory, or both.


CVE-2019-9514[1]:
| Some HTTP/2 implementations are vulnerable to a reset flood,
| potentially leading to a denial of service. The attacker opens a
| number of streams and sends an invalid request over each stream that
| should solicit a stream of RST_STREAM frames from the peer. Depending
| on how the peer queues the RST_STREAM frames, this can consume excess
| memory, CPU, or both.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9512
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9512
[1] https://security-tracker.debian.org/tracker/CVE-2019-9514
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9514
[2] https://github.com/golang/go/issues/33606

Regards,
Salvatore

Bug#934954: golang-1.13: CVE-2019-14809

[Salvatore Bonaccorso]

Source: golang-1.13
Version: 1.13~beta1-2
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/golang/go/issues/29098

Hi,

The following vulnerability was published for golang-1.13. The
CVE-2019-14809 seems unpatched yet as well in golang-1.13
1.13~beta1-2.

CVE-2019-14809[0]:
| net/url in Go before 1.11.13 and 1.12.x before 1.12.8 mishandles
| malformed hosts in URLs, leading to an authorization bypass in some
| applications. This is related to a Host field with a suffix appearing
| in neither Hostname() nor Port(), and is related to a non-numeric port
| number. For example, an attacker can compose a crafted javascript://
| URL that results in a hostname of google.com.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14809
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14809
[1] https://github.com/golang/go/issues/29098
[2] https://github.com/golang/go/commit/61bb56ad63992a3199acc55b2537c8355ef887b6

Regards,
Salvatore

Bug#934953: rust-exa: unsatisfiable build-dependency

[Ralf Treinen]

Source: rust-exa
Version: 0.8.0-2
Severity: serious
User: trei...@debian.org
Usertags: edos-unstallable

Hi,

rust-exa has an unsatisfiable build-dependency since 2019-06-01: it
build-depends on librust-git2-0.7-dev, which does not exist in
the archive.

-Ralf.

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Salvatore Bonaccorso]

Hi Ansgar,

On Wed, Jun 19, 2019 at 08:39:50AM +0200, Salvatore Bonaccorso wrote:
> Hi Ansgar,
> 
> On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> [...]
> > > Sure, I understand that things works like that, I'm just showing a few
> > > design points that could potentially be done differently.
> > 
> > We could also just not accept .buildinfo uploads when they don't contain
> > useful information about published binaries, that is for source-only
> > uploads.
> > 
> > Maybe I should reenable the check for this at least on security-master?
> > It was rejecting uploads that are okay for unstable/experimental so I
> > disabled it again the last time.
> 
> Thank you I think that would be a good compromise. Source-only uploads
> remain possible for security uploads, and ftp-masters and security
> team members do not need to roundtrip reuploading binary builds
> (download, rename, resign ... reupload) and instead uploads which
> contain a buildinfo file rejected giving the uploader a explanation
> why, and the possiblity to just reupload a "proper" source only one.

We had a couple of occasions still where we needed to do fetch the
builds, rename, resign and reupload the packages.

Any chance to enable the above check again? That would solve most of
or issues and people which did upload a source only upload but
containing a ${arch}.buildinfo would get their uploads rejected.

Regards,
Salvatore

Bug#934735: dh-apparmor: please improve dh integration

[Niels Thykier]

> Dear Maintainer,
> 
> It would be great if the integration with dh could be improved.
> 
> The first step would be to enable --with=apparmor support with a script
> like this (/usr/share/perl5/Debian/Debhelper/Sequence/apparmor.pm):
> 
> #! /usr/bin/perl
> # debhelper sequence file for dh_apparmor
> 
> use warnings;
> use strict;
> use Debian::Debhelper::Dh_Lib;
> 
> insert_after("dh_install", "dh_apparmor");
> 
> 1
> 
> It would also require dh_apparmor to do some guesswork and not create
> postinst scripts for binary packages not shipping anything
> apparmor-related.
> 
> Please consider implementing this.
> 
> Thanks!
> 
> 

Hi AppArmor team,

I am happy to assist with technical bits (from a debhelper side PoV) if
you have questions or best practises in this area. :)

Thanks,
~Niels

Bug#934952: stretch-pu: package icu/57.1-6+deb9u3

[GCS]

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

Hi SRMs,

There's a crash in Stretch with ICU, there's a missing NULL check in
the LocalArray class. It crashes ICU with certain options / use
case[1]. Upstream fixed it[2] and now I would like to make it to
Stretch.
Proposed update is attached.

Thanks for consideration,
Laszlo/GCS
[1] https://bugs.debian.org/893009
[2] 
https://github.com/unicode-org/icu/commit/0fd799f7eead9e29fa1dd81f8a119b5fbc88ec36#diff-c3890545a241c9db99ff727b5c4b7705
diff -Nru icu-57.1/debian/changelog icu-57.1/debian/changelog
--- icu-57.1/debian/changelog	2018-03-14 18:28:38.0 +
+++ icu-57.1/debian/changelog	2019-08-07 16:30:43.0 +
@@ -1,3 +1,9 @@
+icu (57.1-6+deb9u3) stretch; urgency=medium
+
+  * Fix pkgdata command segfault (closes: #893009).
+
+ -- Laszlo Boszormenyi (GCS)   Wed, 07 Aug 2019 16:30:43 +
+
 icu (57.1-6+deb9u2) stretch-security; urgency=high
 
   * Backport upstream security fix for CVE-2017-15422: Persian calendar
diff -Nru icu-57.1/debian/patches/pkgdata-crash.patch icu-57.1/debian/patches/pkgdata-crash.patch
--- icu-57.1/debian/patches/pkgdata-crash.patch	1970-01-01 00:00:00.0 +
+++ icu-57.1/debian/patches/pkgdata-crash.patch	2019-08-07 16:30:43.0 +
@@ -0,0 +1,66 @@
+From 0fd799f7eead9e29fa1dd81f8a119b5fbc88ec36 Mon Sep 17 00:00:00 2001
+From: Michael Ow 
+Date: Fri, 20 May 2016 20:00:53 +
+Subject: [PATCH] ICU-12531 Add null check for closeFunction
+
+X-SVN-Rev: 38757
+---
+ icu4c/source/common/unicode/localpointer.h | 13 +
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+diff --git a/icu4c/source/common/unicode/localpointer.h b/icu4c/source/common/unicode/localpointer.h
+index 35e37765c23..c86429359da 100644
+--- icu4c/source/common/unicode/localpointer.h
 icu4c/source/common/unicode/localpointer.h
+@@ -485,9 +485,6 @@ class LocalArray : public LocalPointerBase {
+  * like LocalPointer except that this subclass will use the closeFunction
+  * rather than the C++ delete operator.
+  *
+- * Requirement: The closeFunction must tolerate a NULL pointer.
+- * (We could add a NULL check here but it is normally redundant.)
+- *
+  * Usage example:
+  * \code
+  * LocalUCaseMapPointer csm(ucasemap_open(localeID, options, ));
+@@ -512,12 +509,12 @@ class LocalArray : public LocalPointerBase {
+ : LocalPointerBase(src.ptr) { \
+ src.ptr=NULL; \
+ } \
+-~LocalPointerClassName() { closeFunction(ptr); } \
++~LocalPointerClassName() { if (ptr != NULL) { closeFunction(ptr); } } \
+ LocalPointerClassName =(LocalPointerClassName &) U_NOEXCEPT { \
+ return moveFrom(src); \
+ } \
+ LocalPointerClassName (LocalPointerClassName ) U_NOEXCEPT { \
+-closeFunction(ptr); \
++if (ptr != NULL) { closeFunction(ptr); } \
+ LocalPointerBase::ptr=src.ptr; \
+ src.ptr=NULL; \
+ return *this; \
+@@ -531,7 +528,7 @@ class LocalArray : public LocalPointerBase {
+ p1.swap(p2); \
+ } \
+ void adoptInstead(Type *p) { \
+-closeFunction(ptr); \
++if (ptr != NULL) { closeFunction(ptr); } \
+ ptr=p; \
+ } \
+ }
+@@ -544,7 +541,7 @@ class LocalArray : public LocalPointerBase {
+ explicit LocalPointerClassName(Type *p=NULL) : LocalPointerBase(p) {} \
+ ~LocalPointerClassName() { closeFunction(ptr); } \
+ LocalPointerClassName (LocalPointerClassName ) U_NOEXCEPT { \
+-closeFunction(ptr); \
++if (ptr != NULL) { closeFunction(ptr); } \
+ LocalPointerBase::ptr=src.ptr; \
+ src.ptr=NULL; \
+ return *this; \
+@@ -558,7 +555,7 @@ class LocalArray : public LocalPointerBase {
+ p1.swap(p2); \
+ } \
+ void adoptInstead(Type *p) { \
+-closeFunction(ptr); \
++if (ptr != NULL) { closeFunction(ptr); } \
+ ptr=p; \
+ } \
+ }
diff -Nru icu-57.1/debian/patches/series icu-57.1/debian/patches/series
--- icu-57.1/debian/patches/series	2018-03-14 18:28:38.0 +
+++ icu-57.1/debian/patches/series	2019-08-07 16:30:43.0 +
@@ -12,3 +12,4 @@
 CVE-2017-7867_CVE-2017-7868.patch
 CVE-2017-14952.patch
 CVE-2017-15422.patch
+pkgdata-crash.patch

Bug#902288: GNOME/nautilus thumbnail helper script from /usr/share/thumbnailers fails with ENOENT due to bwrap

[James Lu]

Hello,

It would appear that this affects exe-thumbnailer[1] too: the default
bwrap settings cause thumbnails to be missing entirely on buster / GNOME
3.30.

This issue is fairly new to me, so I'll have to look at what calls in
particular are causing issues with the sandbox. (exe-thumbnailer wraps
around imagemagick, icotools, and msitools to do the bulk of its work,
so it be one of its subprocesses too.)

[1]: https://github.com/exe-thumbnailer/exe-thumbnailer/issues/13

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Hilmar Preuße]

On 16.08.19 20:11, Hector Oron wrote:

Hi Hector,

>   JFYI, a give back (package rebuild from failed state) has been triggered 
> per IRC request:
> 
> Day changed to 16 Aug 2019
> 12:08 < gnu_srs1> (11:51:02 PM) srs: Can somebody gb texlive-bin 
> 2019.20190605.51237-2 on
>   hurd-i386. It built fine locally.
> 
Built successfully!

Do you have a clue why exactly the same libtool command line now succeeds?

@Norbert: nevertheless I'd follow Karl's advice to build dvisvgm
separately. As tl-bin is now available on all arches there is no time
pressure any more.

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



signature.asc
Description: OpenPGP digital signature

Bug#934951: elasticsearch-curator: build-dependency python-elasticsearch (< 6.0.0) unsatisfiable in sid

[Ralf Treinen]

Source: elasticsearch-curator
Version: 5.2.0-1
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

elasticsearch-curator build-depends on python-elasticsearch (< 6.0.0),
but the version of that package in sid is 7.0.1-1.

-Ralf.

Bug#934950: dafny: unsatisfiable build-dependency in sid

[Ralf Treinen]

Source: dafny
Version: 1.9.7-1
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi, dafny build-depends on mono-devel and on mono-reference-assemblies-4.0.
However, the current version of mono-devel in sid (5.18.0.240+dfsg-3)
declares a Breaks with mono-reference-assemblies-4.0 (<< 5.0~). This
makes the build-dependencies of dafny unsatisfiable in sid.

-Ralf.

Bug#934949: clips: build-depends on removed package pdf2htmlex

[Ralf Treinen]

Source: clips
Version: pdf2htmlex
Severity: serious
Version: 6.30-4
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

clips build-depends on pdf2htmlex which was removed from unstable on
2019-04-01.

-Ralf

Bug#934948: Unnecessary dependencies vs multiple binary packages

[Pirate Praveen]

Package: tech-ctte

Hi members of CTTE,

I'd like to bring to your notice a disagreement with ftp masters about adding 
multiple binary packages when the same source package has code targeting 
multiple environments. I have been told already that CTTE cannot overrule an 
ftp master decision, so I'm just asking for opinion of the CTTE. If your 
opinion is favorable to me, it can help me if decide to start a GR eventually.

I was also told to contact CTTE and DPL before going for a GR by js team 
members.

Packages with disagreement are node-autoprefixer and ruby-task-list.

Though ftp masters stated on irc, node-autoprefixer will not be accepted, it 
was eventually accepted and in the archive. But ruby-task-list was rejected.

If I follow ftp master recommendation, node-autoprefixer binary should just 
provide libjs-autoprefixer . But it means anyone installing libjs-autoprefixer 
will have nodejs installed, even though libjs-autoprefixer can work without 
nodejs installed (it will be served by a web server and executed by a browser).

In the same way, ruby-task-list binary should provide node-deckar01-task-list. 
So anyone installing node-deckar01-task-list will get ruby and other 
dependencies of ruby-task-list installed even though it is not necessary. Same 
way anyone installing ruby-task-list will get nodejs unnecessarily.

Alternatively, if I drop nodejs and ruby dependencies, any package depending on 
ruby-task-list will have to add ruby-task-list's dependencies as its own 
dependencies.

Summary of the situation, initially shared with Ruby and JS teams: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-August/034881.html

Initial discussion with ftp masters (readable via a matrix client): 
https://matrix.to/#/!saEdMDOolDMHFHsdhS:matrix.org/$15495421281854XktcP:poddery.com

I have to copy each message from riot separately.

Here it is,

Me: please review node-autoprefixer, it adds libjs-autoprefixer binary required 
to replace embedded copy of autoprefixer.js in ruby-autoprefixer-rails

waldi: 
Pirate ‍ Praveen: you have been asked to not do that

me: waldi: this time there is a valid reason
unlike the previous cases

waldi: Pirate ‍ Praveen: no. nodejs as dependency is no reason

me: waldi: I'd like to ask this as an official statement from ftp team and I'd 
like to challenge it with CTTE
should I open a bug agianst ftp.debian.org?

ScottK: Pirate ‍ Praveen: CTTE can't overrule FTP team.
The only way to overrule a delegate is GR.
Just so you know what you're in for.

Gannef, and yes, open a bug.

highvoltage: Pirate ‍ Praveen: fwiw, I know that that path will take you 
nowhere, the ftp teams's advice here is sound and upwards of 99% of DDs will 
agree with their judgement here, it's going to be futile to fight it, I suggest 
you rather find a better solution for the package, that's a better way to spend 
your (and everybody elses) energy

me: highvoltage: fine, at least let this be on record

highvoltage: policy is quite clear on it and there's even an entire wiki page 
on the topic (https://wiki.debian.org/EmbeddedCodeCopies), I guess if you need 
further records on that, then that's your business

waldi: highvoltage: it's not about code copies. but about adding additional 
binary packages just to avoid one dependency

me: Ganneff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

highvoltage: ew that's even worse

Clint: ...

Gannef: it does sound like a plenty bad idea

And some more...

Bug asking ftp masters for official statement (no response till now): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628

I think such policies should be applied consistently to all packages (it was 
inconsistently applied in the two packages I refer) and published (currently 
there is no official statement).

The outcomes could be,

a) CTTE agrees with ftp masters in rejecting ruby-task-list source package with 
node-deckar01-task-list binary added to existing ruby-task-list binary 
(currently in the master branch of 
https://salsa.debian.org/ruby-team/ruby-task-list).

b) CTTE disagree with the rejection of ruby-task-list source package with 
node-deckar01-task-list binary added to existing ruby-task-list binary. But 
since CTTE cannot overrule ftp masters, the decision stands unless overruled by 
a GR.

Thanks
Praveen
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#931483: konsole: Konsole will not launch from mate-panel or from KDE Application Launcher.

[Martin Steigerwald]

Hi David.

Well as Maxy could not reproduce it and it is no issue for you anymore, 
I'd rather wait whether there someone else has the same issue. It could 
be reopened then or a new bug reported.

I see no real benefit in keeping a bug open cause it *may* be relevant to 
someone else. Let's see whether it is actually an issue for some else.

If that is okay with you, there is no need to reply.

BTW Debian has already been released as Debian 10 aka Buster. But let's 
not discuss other issues with sound cards or whatever else in this bug 
report, there is always debian-kde mailing list you can ask about help 
with issues you have¹. Please for bug reports always keep focused on the 
original issue.

[1] https://lists.debian.org/debian-kde/

Best,
Martin


D.J.J. Ring, Jr. - 16.08.19, 22:18:08 CEST:
> Martin,
> 
> It is only working because I installed Arch Linux and I'm not running
> Debian because of the problems with getting sound card detected with
> the Debian installer. I'll wait until the release.
> 
> So maybe this bug should stay, but I cannot help because I am not
> using Debian now because I cannot run espeak-ng in console and that's
> important to me.
[…]
-- 
Martin