date:20200513

Source: php-redis
Version: 4.2.0-1 5.2.1+4.3.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Cyril Bouthors  wishes no longer to be uploader of php-redis.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#960537: [Python-modules-team] Bug#960537: Bug#960537: python3-html5lib: DeprecationWarning in collections import (will be failure with python3.9)

On Wednesday, May 13, 2020 2:45:48 PM EDT Scott Kitterman wrote:
> On Wednesday, May 13, 2020 1:14:54 PM EDT Scott Kitterman wrote:
> > Package: python3-html5lib
> > Version: 1.0.1-3
> > Severity: normal
> > 
> > Currently with python3.7 or 3.8:
> > DeprecationWarning: Using or importing the ABCs from 'collections' instead
> > of from 'collections.abc' is deprecated, and in 3.9 it will stop working
> > from collections import Mapping
> > 
> > When we get python3.9 it'll be:
> > 
> > Python 3.9.0a2+ (heads/master:b0d4949, Dec 20 2019, 11:38:30)
> > [GCC 8.3.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > 
> > >>> import html5lib
> > 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File
> > 
> > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/__i
> > n
> > it__.py", line 25, in  from .html5parser import HTMLParser, parse,
> > parseFragment
> > 
> >   File
> > 
> > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/htm
> > l
> > 5parser.py", line 8, in  from . import _tokenizer
> > 
> >   File
> > 
> > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_to
> > k
> > enizer.py", line 16, in  from ._trie import Trie
> > 
> >   File
> > 
> > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tr
> > i
> > e/__init__.py", line 3, in  from .py import Trie as PyTrie
> > 
> >   File
> > 
> > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tr
> > i
> > e/py.py", line 6, in  from ._base import Trie as ABCTrie
> > 
> >   File
> > 
> > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tr
> > i
> > e/_base.py", line 3, in  from collections import Mapping
> > ImportError: cannot import name 'Mapping' from 'collections'
> > (/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/collections/__init__.py)
> > 
> > I noticed this because python-bleach is looking into updating their
> > vendored copy (we don't use it) [1].  This change has been in html5lib
> > for some time [2], but with no release coming, I think we should fix it in
> > Debian.
> 
> It looks like there is also:
> 
> src/pip/_vendor/html5lib/treebuilders/dom.py:from collections import
> MutableMapping
> 
> which will be a problem.
> 
> Scott K

Here's the patch that pip is carrying in their vendor tree, which looks right 
to me:

https://github.com/pypa/pip/blob/master/tools/automation/vendoring/patches/
html5lib.patch

Scott K


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

Bug#960552: O: libdevice-usb-pcsensor-hidtemper-perl -- Perl module to interface to the HidTEMPer thermometers

Package: wnpp

The current maintainer of libdevice-usb-pcsensor-hidtemper-perl, Cyril Bouthors 
,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libdevice-usb-pcsensor-hidtemper-perl
Binary: libdevice-usb-pcsensor-hidtemper-perl
Version: 2:0.04-1
Maintainer: Cyril Bouthors 
Uploaders: Cyril Bouthors 
Build-Depends: debhelper (>= 7), perl, libdevice-usb-perl
Architecture: any
Standards-Version: 3.9.4
Format: 1.0
Files:
 c9db7ffb6a0fcaa857d9d9671028e8b6 1421 
libdevice-usb-pcsensor-hidtemper-perl_0.04-1.dsc
 b778565303df4a28c6a727a324c41e0b 11665 
libdevice-usb-pcsensor-hidtemper-perl_0.04.orig.tar.gz
 ae51e422c46f6bef4c391e3954540f64 1424 
libdevice-usb-pcsensor-hidtemper-perl_0.04-1.diff.gz
Checksums-Sha256:
 6e26dc51a14acc9f44a981fefde90de0e1d003ce21b44ef57b0c9ef39ab5bd17 1421 
libdevice-usb-pcsensor-hidtemper-perl_0.04-1.dsc
 a0adcbdc3f365ade57ac37a787177ca4efd551e01d4f2728aa9809aaf8f50711 11665 
libdevice-usb-pcsensor-hidtemper-perl_0.04.orig.tar.gz
 c7c54b8f6fdf376cd02b55890615d29f7c1bfc289d8c349caa8dc21c4961e518 1424 
libdevice-usb-pcsensor-hidtemper-perl_0.04-1.diff.gz
Homepage: 
http://search.cpan.org/dist/Device-USB-PCSensor-HidTEMPer/lib/Device/USB/PCSensor/HidTEMPer/TEMPer.pm
Package-List: 
 libdevice-usb-pcsensor-hidtemper-perl deb perl optional
Directory: pool/main/libd/libdevice-usb-pcsensor-hidtemper-perl
Priority: source
Section: perl

Package: libdevice-usb-pcsensor-hidtemper-perl
Source: libdevice-usb-pcsensor-hidtemper-perl (2:0.04-1)
Version: 2:0.04-1+b1
Installed-Size: 93
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: perl, libdevice-usb-perl
Description-en: Perl module to interface to the HidTEMPer thermometers
 This module is a simplified interface to the HidTEMPer thermometers created by
 PCSensor.
Description-md5: 5ca80cdd5bdcb008276de72073690698
Homepage: 
http://search.cpan.org/dist/Device-USB-PCSensor-HidTEMPer/lib/Device/USB/PCSensor/HidTEMPer/TEMPer.pm
Tag: devel::lang:perl, devel::library, implemented-in::c,
 implemented-in::perl, role::devel-lib
Section: perl
Priority: optional
Filename: 
pool/main/libd/libdevice-usb-pcsensor-hidtemper-perl/libdevice-usb-pcsensor-hidtemper-perl_0.04-1+b1_amd64.deb
Size: 33212
MD5sum: 35a2238f3ab32d9475146386d6015665
SHA256: a81d1e3673a057371788edbebeca3e073078e80ae67c03986b17b108056d575f

Package: libdevice-usb-pcsensor-hidtemper-perl
Version: 2:0.04-1
Installed-Size: 138
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: perl, libdevice-usb-perl
Description-en: Perl module to interface to the HidTEMPer thermometers
 This module is a simplified interface to the HidTEMPer thermometers created by
 PCSensor.
Description-md5: 5ca80cdd5bdcb008276de72073690698
Homepage: 
http://search.cpan.org/dist/Device-USB-PCSensor-HidTEMPer/lib/Device/USB/PCSensor/HidTEMPer/TEMPer.pm
Tag: devel::lang:perl, devel::library, implemented-in::c,
 implemented-in::perl, role::devel-lib
Section: perl
Priority: optional
Filename: 
pool/main/libd/libdevice-usb-pcsensor-hidtemper-perl/libdevice-usb-pcsensor-hidtemper-perl_0.04-1_amd64.deb
Size: 41818
MD5sum: 48f2a2b368c7e48c09fd858bd61e32e0
SHA256: 061201b8957787b5ae57b4da96d4e16e9780057b718a5eeabcf4084d72e44f63

Bug#960549: O: libapache2-mod-watchcat -- Process monitoring Apache module

Package: wnpp

The current maintainer of libapache2-mod-watchcat, Cyril Bouthors 
,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libapache2-mod-watchcat
Binary: libapache2-mod-watchcat
Version: 1.1.2-1
Maintainer: Cyril Bouthors 
Uploaders: Cyril Bouthors 
Build-Depends: debhelper (>= 7.0.50), apache2-dev, libwcat1, dpkg-dev (>= 
1.16.1~), libwcat1-dev, quilt
Architecture: any
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 9a115ed2f90c8970e5dc7dc0d40645bd 1470 libapache2-mod-watchcat_1.1.2-1.dsc
 9896c6e150c447ec9481283588eba4ae 7102 libapache2-mod-watchcat_1.1.2.orig.tar.gz
 bcc654d8e9567487f3f9ac87396cd6ab 2208 
libapache2-mod-watchcat_1.1.2-1.debian.tar.xz
Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=collab-maint/libapache2-mod-watchcat.git;a=summary
Vcs-Git: git://anonscm.debian.org/collab-maint/libapache2-mod-watchcat.git
Checksums-Sha256:
 02facd2990d01eb20ae869208e32943c49d973e5acfc2a15b805625435da4a69 1470 
libapache2-mod-watchcat_1.1.2-1.dsc
 25d482f5fa9e67f9777ed73aaa87f728b0d40fe3e7b70f50c3efa8351fcd56d6 7102 
libapache2-mod-watchcat_1.1.2.orig.tar.gz
 e8763b5bf7ed3766787840b89e18350db238bbe3319ce310b5362291562945d4 2208 
libapache2-mod-watchcat_1.1.2-1.debian.tar.xz
Homepage: http://oss.digirati.com.br/mod_watchcat/
Package-List: 
 libapache2-mod-watchcat deb web optional arch=any
Directory: pool/main/liba/libapache2-mod-watchcat
Priority: source
Section: misc

Package: libapache2-mod-watchcat
Source: libapache2-mod-watchcat (1.1.2-1)
Version: 1.1.2-1+b2
Installed-Size: 37
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: libc6 (>= 2.4), libwcat1, apache2-api-20120211, watchcatd
Description-en: Process monitoring Apache module
 A bug or malicious attacks to machine can lock up a process, leading to a
 deadlock or an unexpected condition. For example: an Apache httpd with
 mod_(php|perl|lua|your_preferred_script_language) running a bad script. When
 the monitored process locks up, the watchcat helps killing him. It is the best
 thing to do.
Description-md5: 879871e0a76d7954604313440dcef302
Homepage: http://oss.digirati.com.br/mod_watchcat/
Section: web
Priority: optional
Filename: 
pool/main/liba/libapache2-mod-watchcat/libapache2-mod-watchcat_1.1.2-1+b2_amd64.deb
Size: 7512
MD5sum: db3d67a4951c293b29e9b871eb226ce9
SHA256: 5a6e0b797a0909eb769e3752b6b62c57ffc6a37bd60739e26eb03d6f120fcc47

Package: libapache2-mod-watchcat
Version: 1.1.2-1
Installed-Size: 68
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: libc6 (>= 2.2.5), libwcat1, apache2-api-20120211, watchcatd
Description-en: Process monitoring Apache module
 A bug or malicious attacks to machine can lock up a process, leading to a
 deadlock or an unexpected condition. For example: an Apache httpd with
 mod_(php|perl|lua|your_preferred_script_language) running a bad script. When
 the monitored process locks up, the watchcat helps killing him. It is the best
 thing to do.
Description-md5: 879871e0a76d7954604313440dcef302
Homepage: http://oss.digirati.com.br/mod_watchcat/
Section: web
Priority: optional
Filename: 
pool/main/liba/libapache2-mod-watchcat/libapache2-mod-watchcat_1.1.2-1_amd64.deb
Size: 7386
MD5sum: c42bbe8af0960235eec55847dbe2cd03
SHA256: f983e907c705c6f1d11f77d9762c47ca969682eef98a130db6b5de1d2daee619

Bug#960553: O: libnet-google-safebrowsing2-perl -- Perl extension for the Google Safe Browsing v2 API

Package: wnpp

The current maintainer of libnet-google-safebrowsing2-perl, Cyril Bouthors
,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libnet-google-safebrowsing2-perl
Binary: libnet-google-safebrowsing2-perl
Version: 1.07-6
Maintainer: Cyril Bouthors
Uploaders: Cyril Bouthors
Build-Depends: debhelper (>= 8.0.0), libnet-ipaddress-perl, libtext-trim-perl,
libmime-base64-urlsafe-perl, libtext-string-hexconvert-perl,
libfile-slurp-perl, libwww-perl, libdigest-hmac-perl
Architecture: all
Standards-Version: 3.9.4
Format: 1.0
Files:
f1ed8814a09d9a4aee1fa9423c5c2dab 1463
libnet-google-safebrowsing2-perl_1.07-6.dsc
359d9ab2cbb9c0983e813a0817987029 27143
libnet-google-safebrowsing2-perl_1.07.orig.tar.gz
8829c12a934135a5df4783beffb9024a 3021
libnet-google-safebrowsing2-perl_1.07-6.diff.gz
Checksums-Sha256:
ffe77739d76ac0ded4f55e7976993ec2392106cb9bd75580a5c5111bac28be6d 1463
libnet-google-safebrowsing2-perl_1.07-6.dsc
a8058312e042f7cbe1f87ef8bc72f688834bbbe9faf357ebd58b58bd4bfcf5d4 27143
libnet-google-safebrowsing2-perl_1.07.orig.tar.gz
a4cf78460c833aee8bde99c8df090e4059d51f8dfd961033b2c7824a568ffcfd 3021
libnet-google-safebrowsing2-perl_1.07-6.diff.gz
Homepage: http://search.cpan.org/~jsobrier/Net-Google-SafeBrowsing2/
Package-List:
libnet-google-safebrowsing2-perl deb perl extra
Directory: pool/main/libn/libnet-google-safebrowsing2-perl
Priority: source
Section: misc

Package: libnet-google-safebrowsing2-perl
Version: 1.07-6
Installed-Size: 181
Maintainer: Cyril Bouthors
Architecture: all
Depends: libtext-trim-perl, libnet-ipaddress-perl, libmime-base64-urlsafe-perl,
libtext-string-hexconvert-perl, libwww-perl, liburi-perl, libdigest-hmac-perl,
libfile-slurp-perl
Suggests: libdbd-sqlite3-perl
Description-en: Perl extension for the Google Safe Browsing v2 API
The library passes most of the unit tests listed in the API documentation. See
the documentation
(http://code.google.com/apis/safebrowsing/developers_guide_v2.html) for more
details about the failed tests.
.
The Google Safe Browsing database must be stored and managed locally.
Net::Google::SafeBrowsing2::Sqlite uses Sqlite as the storage back-end,
Net::Google::SafeBrowsing2::MySQL uses MySQL. Other storage mechanisms
(databases, memory, etc.) can be added and used transparently with this module.
.
You may want to look at "Google Safe Browsing v2: Implementation Notes"
(http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf), a
collection of notes and real-world numbers about the API. This is intended for
people who want to learn more about the API, whether as a user or to make their
own implementation.
.
The source code is available on github at
https://github.com/juliensobrier/Net-Google-SafeBrowsing2.
.
If you do not need to inspect more than 10,000 URLs a day, you can use
Net::Google::SafeBrowsing2::Lookup with the Google Safe Browsing v2 Lookup API
which does not require to store and maintain a local database.
.
IMPORTANT: If you start with an empty database, you will need to perform
several updates to retrieve all the Google Safe Browsing information. This may
require up to 24 hours. This is a limitation of the Google API, not of this
module. See "Google Safe Browsing v2: Implementation Notes" at
http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf.
Description-md5: a0886817950a0da531b13ccdfe7dfa72
Homepage: http://search.cpan.org/~jsobrier/Net-Google-SafeBrowsing2/
Tag: devel::lang:perl, devel::library, implemented-in::perl
Section: perl
Priority: optional
Filename:
pool/main/libn/libnet-google-safebrowsing2-perl/libnet-google-safebrowsing2-perl_1.07-6_all.deb
Size: 53778
MD5sum: 7e8490813ac7c02e3d7440ee23c34089
SHA256: 178428565c1e326c9de815c247332365af54394e6a41eae61e18b5ba24c1b230

Bug#960550: O: libwcat1 -- Process monitoring library

Package: wnpp

The current maintainer of libwcat1, Cyril Bouthors ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libwcat1
Binary: libwcat1, libwcat1-dev
Version: 1.1-1.1
Maintainer: Cyril Bouthors 
Uploaders: Cyril Bouthors 
Build-Depends: debhelper (>= 7.0.50~), dpkg-dev (>= 1.16.1~)
Architecture: any
Standards-Version: 3.9.4
Format: 1.0
Files:
 e29dac712b3acdbc58ea23c59fe91f04 1806 libwcat1_1.1-1.1.dsc
 4dc7c2ce67aff5274ebb8e8461420f16 12793 libwcat1_1.1.orig.tar.gz
 6c6b947ab6dfdfcf32570ff1270ba46a 1342 libwcat1_1.1-1.1.diff.gz
Checksums-Sha256:
 fb180836f82428cf8e8a4ba526ba1748abb067a6bdf7383b1d51bf29f374e668 1806 
libwcat1_1.1-1.1.dsc
 fad3ad82deb8c67099cd2ef8fa89f7295788af0c76b16568678800c7445a5c8e 12793 
libwcat1_1.1.orig.tar.gz
 dc41bc3c2af96ffb7c4683a905f7e1143df0dfdc6d33ae8e8b777e2d42c5c321 1342 
libwcat1_1.1-1.1.diff.gz
Homepage: http://oss.digirati.com.br/watchcatd/
Package-List: 
 libwcat1 deb web optional arch=any
 libwcat1-dev deb libdevel optional arch=any
Directory: pool/main/libw/libwcat1
Priority: source
Section: misc

Package: libwcat1
Version: 1.1-1.1
Installed-Size: 27
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: libc6 (>= 2.4)
Description-en: Process monitoring library
 A bug or malicious attacks to machine can lock up a process, leading to a
 deadlock or an unexpected condition. For example: an Apache httpd with
 mod_(php|perl|lua|your_preferred_script_language) running a bad script. When
 the monitored process locks up, the watchcat helps killing him. It is the best
 thing to do.
Description-md5: 277b29345a5007de740ce9bcc8528fa9
Homepage: http://oss.digirati.com.br/watchcatd/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libw/libwcat1/libwcat1_1.1-1.1_amd64.deb
Size: 4674
MD5sum: 0a5f32c3c41beccd1f0b704526f302c5
SHA256: cce02d6050f57678f080be834a188e5a0597a295e3a43a54f126f27102d8e952

Package: libwcat1-dev
Source: libwcat1
Version: 1.1-1.1
Installed-Size: 12
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: libwcat1 (= 1.1-1.1)
Description-en: Process monitoring library
 A bug or malicious attacks to machine can lock up a process, leading to a
 deadlock or an unexpected condition. For example: an Apache httpd with
 mod_(php|perl|lua|your_preferred_script_language) running a bad script. When
 the monitored process locks up, the watchcat helps killing him. It is the best
 thing to do.
Description-md5: 277b29345a5007de740ce9bcc8528fa9
Homepage: http://oss.digirati.com.br/watchcatd/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/libw/libwcat1/libwcat1-dev_1.1-1.1_amd64.deb
Size: 2186
MD5sum: ae3460db1c4568bf77a56da018a86f48
SHA256: 777b2bef87ec13a360a1db20de1fcd68de2f337d269108b4cde01361c31a0647

Bug#945739: symeig - RM?

2020-05-13 Thread Scott Talbert


Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: symeig -- RoQA; package obsolete; blocking py2 removal

Bug#960551: O: php-nrk-predis -- Flexible and feature-complete PHP client library for the Redis key-value store

Package: wnpp

The current maintainer of php-nrk-predis, Cyril Bouthors ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: php-nrk-predis
Binary: php-nrk-predis
Version: 1.0.0-1
Maintainer: Cyril Bouthors 
Uploaders: Cyril Bouthors 
Build-Depends: debhelper (>= 8.0.0)
Architecture: any
Standards-Version: 3.9.6
Format: 1.0
Files:
 b9bbe31e1f81d8af332b400c1ad88315 1112 php-nrk-predis_1.0.0-1.dsc
 9eebc7c50072ad916239380280fbd017 107307 php-nrk-predis_1.0.0.orig.tar.gz
 e635a8158fb8caeb368b64f44ba134f8 2032 php-nrk-predis_1.0.0-1.diff.gz
Checksums-Sha256:
 877b44053908e2f13e881b59794f3c52fd8d0bec6a41719f1f606b1d6f225d19 1112 
php-nrk-predis_1.0.0-1.dsc
 c5b58119b4a90c2d252ea41bbb8dbfc3a6abdd182270a703e02778ca61ec4db9 107307 
php-nrk-predis_1.0.0.orig.tar.gz
 91c1da883d41385e7f7e5ba3149db6150f192079faa011f434efdcf141e3cd09 2032 
php-nrk-predis_1.0.0-1.diff.gz
Homepage: https://github.com/nrk/predis
Package-List: 
 php-nrk-predis deb php optional arch=any
Directory: pool/main/p/php-nrk-predis
Priority: optional
Section: misc

Package: php-nrk-predis
Source: php-nrk-predis (1.0.0-1)
Version: 1.0.0-1+b1
Installed-Size: 650
Maintainer: Cyril Bouthors 
Architecture: amd64
Replaces: libphp-predis
Provides: libphp-predis
Conflicts: libphp-predis
Description-en: Flexible and feature-complete PHP client library for the Redis 
key-value store
 The library does not require any additional extension loaded in PHP but it can
 be optionally paired with the phpiredis (https://github.com/nrk/phpiredis)
 C-based extension to lower the overhead of serializing and parsing the Redis
 protocol. Predis is also available in an asynchronous fashion through the
 experimental client provided by the Predis\Async
 (http://github.com/nrk/predis-async) library.
 .
 For a list of frequently asked questions about Predis see our FAQ
 (https://github.com/nrk/predis/blob/master/FAQ.md). More details are available
 on the official wiki (http://wiki.github.com/nrk/predis) of the project.
Description-md5: 89d8866579519ce5a826cbe4dcccace1
Homepage: https://github.com/nrk/predis
Section: php
Priority: optional
Filename: pool/main/p/php-nrk-predis/php-nrk-predis_1.0.0-1+b1_amd64.deb
Size: 73304
MD5sum: d60c3268e2e9a3e38bdcb33b9707fe56
SHA256: d33147dfb422f3582f81629b3c25f63e9edc3055ef2ee9c3b43cfc212a66d5bb

Package: php-nrk-predis
Version: 1.0.0-1
Installed-Size: 626
Maintainer: Cyril Bouthors 
Architecture: amd64
Replaces: libphp-predis
Provides: libphp-predis
Conflicts: libphp-predis
Description-en: Flexible and feature-complete PHP client library for the Redis 
key-value store
 The library does not require any additional extension loaded in PHP but it can
 be optionally paired with the phpiredis (https://github.com/nrk/phpiredis)
 C-based extension to lower the overhead of serializing and parsing the Redis
 protocol. Predis is also available in an asynchronous fashion through the
 experimental client provided by the Predis\Async
 (http://github.com/nrk/predis-async) library.
 .
 For a list of frequently asked questions about Predis see our FAQ
 (https://github.com/nrk/predis/blob/master/FAQ.md). More details are available
 on the official wiki (http://wiki.github.com/nrk/predis) of the project.
Description-md5: 89d8866579519ce5a826cbe4dcccace1
Homepage: https://github.com/nrk/predis
Section: php
Priority: optional
Filename: pool/main/p/php-nrk-predis/php-nrk-predis_1.0.0-1_amd64.deb
Size: 74632
MD5sum: 370c2cd4c1772f578bfacfd14288465b
SHA256: 1b0c8c123ffbaa397deda587607e7f533525bea695ad8f9e62ce8e52ae04dd70

Bug#960554: O: watchcatd -- Process monitoring daemon

Package: wnpp

The current maintainer of watchcatd, Cyril Bouthors ,
has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: watchcatd
Binary: watchcatd
Version: 1.2.1-3.1
Maintainer: Cyril Bouthors 
Uploaders: Cyril Bouthors 
Build-Depends: debhelper (>= 7.0.50~), libevent-dev, dpkg-dev (>= 1.16.1~)
Architecture: any
Standards-Version: 3.9.4
Format: 1.0
Files:
 f76bc4ce849ddeb2d280dc9feb6c4163 1782 watchcatd_1.2.1-3.1.dsc
 04afc3ea770ae35e91ab86f22c16d2d3 29842 watchcatd_1.2.1.orig.tar.gz
 26af0d3de2833a1b124c228bab813b04 2447 watchcatd_1.2.1-3.1.diff.gz
Checksums-Sha256:
 3000afc337f1df344b1b3a5ef0c3cbb24d275ddda48702dd00d251d031b857e5 1782 
watchcatd_1.2.1-3.1.dsc
 acb66980bec17e984684c9214c4b252696deb320981dff3c241e3812c1a739fd 29842 
watchcatd_1.2.1.orig.tar.gz
 0812565cbd180ca0185effa1a3950778861915e09fe612c7df04f414c7d3188a 2447 
watchcatd_1.2.1-3.1.diff.gz
Homepage: http://oss.digirati.com.br/watchcatd/
Package-List: 
 watchcatd deb admin optional arch=any
Directory: pool/main/w/watchcatd
Priority: source
Section: misc

Package: watchcatd
Source: watchcatd (1.2.1-3.1)
Version: 1.2.1-3.1+b1
Installed-Size: 96
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: libc6 (>= 2.14), libevent-2.1-7 (>= 2.1.8-stable)
Description-en: Process monitoring daemon
 A bug or malicious attacks to machine can lock up a process, leading to a
 deadlock or an unexpected condition. For example: an Apache httpd with
 mod_(php|perl|lua|your_preferred_script_language) running a bad script. When
 the monitored process locks up, the watchcat helps killing him. It is the best
 thing to do.
Description-md5: db81a4d901976cfdec650aa77ea40e7a
Homepage: http://oss.digirati.com.br/watchcatd/
Section: admin
Priority: optional
Filename: pool/main/w/watchcatd/watchcatd_1.2.1-3.1+b1_amd64.deb
Size: 20904
MD5sum: 16008ab7cdfad2bc18d7cbe0be192c1b
SHA256: 0d8f4b00d2846457a420f8daba18d2397a8049bbe72ced1f3d1774959659867b

Package: watchcatd
Version: 1.2.1-3.1
Installed-Size: 83
Maintainer: Cyril Bouthors 
Architecture: amd64
Depends: libc6 (>= 2.14), libevent-2.1-6 (>= 2.1.8-stable)
Description-en: Process monitoring daemon
 A bug or malicious attacks to machine can lock up a process, leading to a
 deadlock or an unexpected condition. For example: an Apache httpd with
 mod_(php|perl|lua|your_preferred_script_language) running a bad script. When
 the monitored process locks up, the watchcat helps killing him. It is the best
 thing to do.
Description-md5: db81a4d901976cfdec650aa77ea40e7a
Homepage: http://oss.digirati.com.br/watchcatd/
Section: admin
Priority: optional
Filename: pool/main/w/watchcatd/watchcatd_1.2.1-3.1_amd64.deb
Size: 20932
MD5sum: ec25dcc4a37633773b7b7e6789360bda
SHA256: f3c6a17b9ed4862355d66290b5e3cfa6a3bde2c30a323760e2a035046409757a

Bug#960442: apt-listbugs: after Ctrl-C apt fails exit 2 even though apt-listbugs exit 0

2020-05-13 Thread Francesco Poli

Control: reassign -1 apt 2.1.1
Control: affects -1 + apt-listbugs

On Tue, 12 May 2020 18:24:47 +0200 Francesco Poli wrote:

[...]
> Unless you disagree, I am going to reassign your bug report to apt and
> merge it with [#832593].

Dear Jochen, I am reassigning the bug report right now.

Dear APT Development Team,
I received a [new bug] report for apt-listbugs about the behavior after
Ctrl+C.

[new bug]: 

The described behavior seems to be consistent with the current
[incarnation] of bug [#832593].

[incarnation]: 
[#832593]: 

Do I understand correctly that the patch mentioned in [message #85] has
not been applied to apt yet?
Could you please explain why?

[message #85]: 

I am going to merge this [new bug] with [#832593].

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgp4gGdjVRm1S.pgp
Description: PGP signature

Bug#927684: dunstify is missing from package

2020-05-13 Thread Nikos Tsipinakis

Hi,

dunstify wasn't included in the default installation target before,
but this has now been changed upstream. The next upload/release
will also include dunstify.

notify-send indeed can't define actions.

On Tue, 12 May 2020, at 15:52, Jakson Alves de Aquino wrote:
> I'm using dunstify in scripts to send messages to dunst,
> including the definition of actions. Is notify-send capable of
> defining actions? I couldn't find this capability in its man page.
> So, I believe that other users would benefit from dunstify being
> available in a Debian package.
> 
> Thank you!
> 
> -- 
> Jakson Aquino
>

Bug#960548: python3-pyparsing: DeprecationWarning in collections import (will be failure with python3.9)

Package: python3-pyparsing
Version: 2.4.7-1
Severity: normal

Currently there is just a warning, but once we switch to python3.9 the
following line will fail:

from collections import MutableMapping, Mapping

This is already fixed upstream [1].  It's an easy enough fix (probably
much easier than jumping to pyparsing 3.0), so we ought to go ahead and
do it.  Note that the upstream fix may not be compatible with the pypy
package, so we may want something slightly different, similar to [2].

Scott K

[1] https://github.com/pyparsing/pyparsing/blob/master/pyparsing_archive.py#L109
[2] https://patch-diff.githubusercontent.com/raw/mozilla/bleach/pull/533.diff

Bug#945739: symeig - RM?

2020-05-13 Thread Yaroslav Halchenko

the last changelog msg I see is

symeig (1.5-2) unstable; urgency=low

  * Deprecating symeig as a separate package -- functionality was 
included in
scipy (>=0.7.0), please use scipy.linalg.eigh instead.
  * Transitional packages became architecture 'all' instead of 'any'
  * Boosted policy to 3.8.3:
- -dbg got correct "section: debug" and "priority: extra"

 -- Yaroslav Halchenko   Mon, 16 Nov 2009 
08:55:44 -0500


so indeed it is time for it to RiP ;)  please RM

On Wed, 13 May 2020, Scott Talbert wrote:

> Hi,

> It seems that symeig has no (longer?) reverse depends and it seems to be
> abandoned upstream.  Is the best solution just to remove it?

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#930781: python3-socks: Deprecation warning emitted on import

On Thu, 20 Jun 2019 09:53:06 -0400 Jamie Bliss  wrote:
> Package: python3-socks
> Version: 1.6.8+dfsg-1
> Severity: normal
> 
> Dear Maintainer,
> 
> PySocks 1.6.8 has a deprecated import and a warning is emitted on import. 
This
> is triggered by importing requests, an extremely common HTTP library. It has
> been fixed in upstream 1.7.0
> 
> This happens for any software that uses requests, whether or not they depend 
on
> PySocks. It just happens for every application that uses it as soon as
> python3-socks is installed on a system.
> 
> In addition, this warning becomes user-visible if the application surfaces
> warnings in some way (in a log or on stdout).

Assuming the warning in question is:

/usr/lib/python3/dist-packages/socks.py:58
  /usr/lib/python3/dist-packages/socks.py:58: DeprecationWarning: Using or 
importing the ABCs from 'collections' instead of from 'collections.abc' is 
deprecated since Python 3.3, and in 3.9 it will stop working
from collections import Callable

It'll become fatal as soon as we go to python3.9, so this package really 
should be updated.

Scott K

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

Bug#945739: symeig - RM?

2020-05-13 Thread Scott Talbert


Hi,

It seems that symeig has no (longer?) reverse depends and it seems to be 
abandoned upstream.  Is the best solution just to remove it?


Thanks,
Scott

Bug#947776: python3-nautilus 1.2.3-3 solved the problem

2020-05-13 Thread Bjoern Schiessle

Hi,

updating python3-nautilus to version 1.2.3-3 from unstable solved the
problem for me.

Cheers,
Björn

Bug#960301: firefox-esr: [regression] cannot find the microphone

2020-05-13 Thread Francesco Poli

On Wed, 13 May 2020 07:35:00 +0900 Mike Hommey wrote:

> If I dget 
> https://snapshot.debian.org/archive/debian/20200408T025735Z/pool/main/f/firefox-esr/firefox-esr_68.7.0esr-1.dsc,
>  I get a debian/control that doesn't contain anything about libvpx. 
> debian/control.in does, but that should be irrelevant.

Maybe I understood what happens: I added a changelog stanza to document
the rebuilding against current sid and that stanza had distribution set
to UNRELEASED.

Does this explain why I obtained the wrong debian/control?

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgptt0cfU7eCS.pgp
Description: PGP signature

Bug#960529: Info received (Bug#960529: libc6: After update the integrated camera (uvcvideo) is not longer detected)

2020-05-13 Thread Reiner Nix

Hi,

now, I have tried again to start a video conference (just to check connecting 
zoom to an alternative device) ... and this laptop works with zoom and jitsi 
without any further config change. Very strange.

I guess that this ticket can be closed and apologize for any inconvenience 
caused by the ticket.

Best regards
Reiner

Bug#956395: openscap_1.2.17-0.1_source.changes REJECTED

2020-05-13 Thread Boyuan Yang

Hi,

在 2020-05-13星期三的 08:30 +0200，Håvard Flaget Aasen写道：
> Hi Boyuan,
> 
> Thanks for reviewing and uploading this.
> 
> On 13.05.2020 04:37, Debian FTP Masters wrote:
> > 
> > Source-only uploads to NEW are not allowed.
> > 
> > binary:python3-openscap is NEW.
> 
> Do you think you could upload it again, so it can enter the NEW queue?

Re-uploaded to the NEW queue.

-- 
Best,
Boyuan Yang


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

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

2020-05-13 Thread Olivier Humbert


Le 2020-05-13 20:25, Alexandre Lymberopoulos a écrit :

Package: wnpp
Severity: wishlist

* Package name: hydrogen
  Version : 1.0.0
  Upstream Author : Hydrogen Audio Team 
* URL : http://hydrogen-music.org/
* License : GPLv2
  Programming Lang: C++
  Description : advanced drum machine/step sequencer

This is a request for repackaging hydrogen, since the last version
relayed on Qt4 (no longer in Debian). This new version based on Qt5 and
could be brought back to the distro..

Thanks in advance.

Best,
Alexandre


Hi.
Please note that there isn't such a "1.0.0" version yet. We're still on 
a beta2 release.

Hope that helps.
Olivier

Bug#960545: mark golang-github-russross-blackfriday-dev Multi-Arch: foreign

Package: golang-github-russross-blackfriday-dev
Version: 1.5.2+git20200218.41c5fcc-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:abci src:acbuild src:badger

golang-github-russross-blackfriday-dev is another go library that
happens to be in the build dependency tree of many source packages that
build architecture dependent packages. I've listed three affected
example packages above.  Since it is Architecture: all, it cannot
satisfy cross Build-Depends at all. Fortunately, marking it Multi-Arch:
foreign is a good option here as it doesn't have any maintainer scripts
nor dependencies. Please consider applying the attached patch to move
cross building go packages forward.

Helmut
diff --minimal -Nru 
golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/changelog 
golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/changelog
--- golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/changelog   
2020-03-12 15:51:46.0 +0100
+++ golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/changelog   
2020-05-13 21:16:51.0 +0200
@@ -1,3 +1,11 @@
+golang-blackfriday (1.5.2+git20200218.41c5fcc-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-russross-blackfriday-dev Multi-Arch: foreign. (Closes:
+#-1)
+
+ -- Helmut Grohne   Wed, 13 May 2020 21:16:51 +0200
+
 golang-blackfriday (1.5.2+git20200218.41c5fcc-1) unstable; urgency=medium
 
   * New upstream version 1.5.2+git20200218.41c5fcc
diff --minimal -Nru golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/control 
golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/control
--- golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/control 2020-03-12 
15:49:52.0 +0100
+++ golang-blackfriday-1.5.2+git20200218.41c5fcc/debian/control 2020-05-13 
21:16:49.0 +0200
@@ -19,6 +19,7 @@
 
 Package: golang-github-russross-blackfriday-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Conflicts: golang-blackfriday-dev
 Provides: golang-blackfriday-dev

Bug#960546: mark easygen Multi-Arch: foreign

Source: easygen
Version: 4.1.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:ffcvt

ffcvt fails to cross build from source, because it fails running easygen
with an Exec format error (after figuring out how to annotate the main
go dependency). Since easygen is a tool for transforming textual formats
(yaml and templates), it seems fairly safe to conclude that its
interface is architecture-independent. That'd make it eligible for being
marked Multi-Arch: foreign. Once doing so, ffcvt will use the build
architecture easygen, which can be run. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru easygen-4.1.0/debian/changelog 
easygen-4.1.0/debian/changelog
--- easygen-4.1.0/debian/changelog  2019-12-28 16:54:38.0 +0100
+++ easygen-4.1.0/debian/changelog  2020-05-13 18:32:35.0 +0200
@@ -1,3 +1,10 @@
+easygen (4.1.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark easygen Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 13 May 2020 18:32:35 +0200
+
 easygen (4.1.0-1) unstable; urgency=medium
 
   * New upstream version 4.1.0
diff --minimal -Nru easygen-4.1.0/debian/control easygen-4.1.0/debian/control
--- easygen-4.1.0/debian/control2019-12-28 16:54:38.0 +0100
+++ easygen-4.1.0/debian/control2020-05-13 18:31:44.0 +0200
@@ -19,6 +19,7 @@
 
 Package: easygen
 Architecture: any
+Multi-Arch: foreign
 Built-Using: ${misc:Built-Using}
 Depends: ${misc:Depends},
 #${shlibs:Depends}

Bug#960543: ITP: vim-ale -- Asynchronous Lint Engine for Vim 8 and NeoVim

2020-05-13 Thread Nicholas Guriev

Package: wnpp
Severity: wishlist
Owner: Nicholas Guriev 
Control: forwarded -1 https://github.com/dense-analysis/ale/issues/3160

* Package name: vim-ale
  Version : 2.6.0
  Upstream Author : w0rp 
* URL : https://github.com/dense-analysis/ale
* License : BSD-2-Clause
  Programming Lang: VimScript
  Description : Asynchronous Lint Engine for Vim 8 and NeoVim

ALE (Asynchronous Lint Engine) is a plugin providing linting (syntax checking
and semantic errors) in NeoVim 0.2.0+ and Vim 8 while you edit your text files,
and acts as a Vim Language Server Protocol client.

I have done some of work on packaging, you can see a Git repository in my
namespace at salsa.d.o.

https://salsa.debian.org/mymedia/vim-ale/-/tree/mymedia/master

Bug#960544: ITP: vim-vader -- simple vimscript test framework

2020-05-13 Thread Nicholas Guriev

Package: wnpp
Severity: wishlist
Owner: Nicholas Guriev 

* Package name: vim-vader
  Upstream Author : Junegunn Choi
* URL : https://github.com/junegunn/vader.vim
* License : Expat (MIT-like)
  Programming Lang: VimScript
  Description : simple vimscript test framework

Vader.vim is a simple tool designed to help you write VimScript tests in a
readable way. It will be a dependency of the vim-ale package.

I have done some of work on packaging, you can see a Git repository in my
namespace at salsa.d.o.

https://salsa.debian.org/mymedia/vim-vader/-/tree/mymedia/master

Bug#960542: pinentry: debian/tests/simple-tty is sloppy in its attempt to avoid a race condition

2020-05-13 Thread Daniel Kahn Gillmor

Package: src:pinentry
Version: 1.1.0-4
Severity: wishlist

in debian/tests/simple-tty in pinentry, we just added a 2.0s sleep to
avoid a race condition, where the password would be entered before
pinentry-tty had finished writing out its prompt.

It would be nice to instead have that test read the pty and wait for the
prompt before sending the password, rather than an arbitrary 2s sleep.

this would make the normal test run faster (avoiding an arbitrary 2s
timeout) and still avoid the worst race conditions.  I don't know
whether a final race condition would remain though: there might be a gap
if pinentry-tty is suspended by the OS between writing out the prompt
and listening on the pty.  That would be "interesting" to discover.

   --dkg


signature.asc
Description: PGP signature

Bug#960541: RFP: elixir-tesla -- Tesla Elixir Library

2020-05-13 Thread Jeffrey Cliff

Package: wnpp
Severity: wishlist

* Package name: elixir-tesla
  Upstream Author :  Alexander Strizhakov
* URL :
https://git.pleroma.social/pleroma/elixir-libraries/tesla/
* License : MIT
  Programming Lang: Elixir
  Description : Tesla is an HTTP client loosely based on Faraday. It
embraces the concept of middleware when processing the request/response
cycle.

Tesla is built around the concept of composable middlewares. This is very
similar to how Plug Router works.
<#basic>

Bug#960537: [Python-modules-team] Bug#960537: python3-html5lib: DeprecationWarning in collections import (will be failure with python3.9)

On Wednesday, May 13, 2020 1:14:54 PM EDT Scott Kitterman wrote:
> Package: python3-html5lib
> Version: 1.0.1-3
> Severity: normal
> 
> Currently with python3.7 or 3.8:
> DeprecationWarning: Using or importing the ABCs from 'collections' instead
> of from 'collections.abc' is deprecated, and in 3.9 it will stop working
> from collections import Mapping
> 
> When we get python3.9 it'll be:
> 
> Python 3.9.0a2+ (heads/master:b0d4949, Dec 20 2019, 11:38:30)
> [GCC 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> import html5lib
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File
> "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/__in
> it__.py", line 25, in  from .html5parser import HTMLParser, parse,
> parseFragment
>   File
> "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/html
> 5parser.py", line 8, in  from . import _tokenizer
>   File
> "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tok
> enizer.py", line 16, in  from ._trie import Trie
>   File
> "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tri
> e/__init__.py", line 3, in  from .py import Trie as PyTrie
>   File
> "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tri
> e/py.py", line 6, in  from ._base import Trie as ABCTrie
>   File
> "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tri
> e/_base.py", line 3, in  from collections import Mapping
> ImportError: cannot import name 'Mapping' from 'collections'
> (/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/collections/__init__.py)
> 
> I noticed this because python-bleach is looking into updating their
> vendored copy (we don't use it) [1].  This change has been in html5lib
> for some time [2], but with no release coming, I think we should fix it in
> Debian.

It looks like there is also:

src/pip/_vendor/html5lib/treebuilders/dom.py:from collections import 
MutableMapping

which will be a problem.

Scott K


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

Bug#924591: fastboot can't install ROM

2020-05-13 Thread Anders Boström

Hi!

I just tried to use fastboot from Debian buster (1:8.1.0+r23-5) to
reinstall my old Nexus 7 tablet, using the provided
flash-all.sh script.

When executing:
fastboot -w update image-nakasi-ktu84p.zip

It failed with:

/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
mke2fs failed: 1

Downgrading fastboot and all android-packages to stretch solves the
problem.

How can this be only "Severity: wishlist"?

/ Anders

Bug#946187: ITP: starship -- any news?

2020-05-13 Thread Daniele Tricoli

Hello meskio,
thanks for pinging me!

On Tue, May 12, 2020 at 07:02:58PM +0200, meskio wrote:
> I'm a happy user of starship and I will love to see it in debian. Is there 
> any 
> news about this package? Any blockers?

Not any serius blocker, I was only slowed down by the COVID19 sutuation here
in Italy. But no need to worry, I'm fine and I was already planning to work on
it the full weekend to push this! :)

> Thanks for working on it.

Thanks for pinging, knowing that I will not the only one that would use it is
encouraging.

I will post updates here!

Kind regards,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org

signature.asc
Description: PGP signature

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

2020-05-13 Thread Sebastian Ramacher

Hi

On 2020-05-13 15:25:44 -0300, Alexandre Lymberopoulos wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: hydrogen
>   Version : 1.0.0
>   Upstream Author : Hydrogen Audio Team 
> * URL : http://hydrogen-music.org/
> * License : GPLv2
>   Programming Lang: C++
>   Description : advanced drum machine/step sequencer
> 
> This is a request for repackaging hydrogen, since the last version
> relayed on Qt4 (no longer in Debian). This new version based on Qt5 and
> could be brought back to the distro..

FWIW, the old packaing is available at
https://salsa.debian.org/multimedia-team/hydrogen. If anyone is
interested in taking care of hydrogen, one can start from there.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#959719: obs-studio: use the libsimde-dev package

2020-05-13 Thread Sebastian Ramacher

On 2020-05-04 15:22:39 +0200, Michael R. Crusoe wrote:
> Package: obs-studio
> Version: 25.0.3+dfsg1-2
> Severity: normal
> 
> I've made a merge request at 
> https://salsa.debian.org/multimedia-team/obs-studio/-/merge_requests/2
> to use the packaged "simde" library instead of the code copy in
> upstream's source.
> 
> >From the changelog
> 
> * debian/patches:
>   - Use the SIMD Everywhere headers from libsimde-dev, instead of upstream's
> code copy
> * debian/control:
>   - Build-dep on libsimde-dev
>   - Add "Built-Using: ${simde:Built-Using}" to all the binary packages to
> document the version of libsimde-dev used, as required to keep that
> version in the Debian archive, which is needed to fulfill the GPL
> * debian/copyright:
>   - exclude libobs/util/simde/* as we will use the files from libsimde-dev
> * debian/rules:
>   - Include the recommended flags for SIMDe, especially important for
> non-X86 architectures

Thanks for the MR. I'll take a look the next time I update the package.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#960540: git-buildpackage: Documentation unclear about pristine-tar when upstream source comes from git

2020-05-13 Thread Matthijs Kooijman

Package: git-buildpackage
Version: 0.9.15
Severity: normal

Hi Guido,

I'm trying to figure out whether I need pristine-tar or not, and I can't
quite figure it out based on the documentation.

I understand that, when upstream supplies a tarball, you can use
`gbp import-orig --pristine-tar` to import the tarball along with
pristine-tar data, and then `gbp buildpackage --pristine-tar` will
recreate the pristine tarball again (if needed).

However, what if there is no upstream tarball and sources are
merged using git directly? Is having a pristine tarball still relevant?
I can imagine that when multiple people check out the packaging repo and
build a package, they want to have the exact same tarball, so it would
make sense to:
 - When a tarball is first created, commit pristine-tar data for it.
 - When a tarball is created later, use the pristine-tar info to
   recreate an identical tarball.

Or does the `git archive` used to create tarballs from git already
produce consistent tarballs (since there is no upstream tarball to
match, this would be sufficient)? I could not find anything in the git
archive manpage to suggest this, nor any details about what
`pristine-tar` actually *does* to reason about this. A quick try shows
that gbp does indeed manage to reproduce the same tarball twice, but
that gives no guarantees about the same result with different git
versions and different machines, of course.

I was further confused by the gbp buildpackage manpage. It says:

> When gbp buildpackage doesn't find a suitable upstream tarball it will
> create one either using pristine-tar™ or git archive. These options
> determine how the tarball is created:

This is a bit confusing, I had expected that `git archive` would create a
tarball and then pristine-tar would be used to make it pristine. I later
read the `pristine-tar` manpage and noticed that pristine-tar actually
creates the files from git directly (combining upstream commit and the
pristine-tar commit), so no git archive involved.

Also, it says:

> --git-pristine-tar
>  Use pristine-tar when generating the upstream tarball if it doesn't
>  exist. If this mode is enabled the --git-upstream-tag,
>  --git-upstream-tree options have no effect.

More confusion: If gbp-buildpackage is supposed to generate a
pristine-tar delta when the tarball is first created from git, I would
think I needed to pass `--git-pristine-tar`, but *also*
`--git-upstream-tag` (or `--git-upstream-tree`) to allow gbp to locate
the right upstream commit to base the tarball on?

Later, I learned from the `pristine-tar` manpage that the pristine-tar
commit actually contains the git tree id of the commit used to create
it, so when recreating the tarball, pristine-tar can find the right
commit on its own.

But when creating the tarball the first time, `gbp buildpackage` *does*
require the upstream commit, right?

Or is the workflow to, on the first build for a new upstream version,
run buildpackage without `--pristine-tar` to create the tarball and then
run `pristine-tar` manually? I don't think so, since there is also `gbp
--git-pristine-tar-commit`:

> --git-pristine-tar-commit
>  Commit the pristine-tar delta to the pristine-tar branch if a new
>  tarball was generated and the pristine-tar data isn't already there.

Or does this option maybe disable `--git-pristine-tar` when there is no
pristine-tar data yet, and thus "reactivate" the `--git-upstream-*`
options?

If so (and if pristine-tar is still needed without upstream tarballs),
the workflow could be to always run:

gbp --git-pristine-tar --git-pristine-tar-commit 
--git-upstream-tag=v%(version)s

And that would then *create* a tarball and pristine-tar data when no
pristine-tar data is present yet, or *use* it (and ignore upstream-tag)
when pristine-tar data *is* present? A quick shows that this might
indeed work like this.

I would be grateful if you could clarify some of this for me. Updating
the docs would be even better, but maybe I can find some time to have a
look at that if you can clarify things here first :-)

Somewhat related: Is git archive even used at all? I ran 0.9.15 with
`--git-verbose`, which seems to print all individual git commands ran,
but I did not see git archive in there? Or is it just not printed?

Gr.

Matthijs

Bug#960538: Acknowledgement (RFP: ffsend -- A fully featured Firefox Send command line client)

2020-05-13 Thread Alexandre Lymberopoulos

I'm sorry. The language in which ffsend is written is Rust, not C++ as I
wrote in the first message.

By the way the Rust team was copied in the original message.

Thanks in advance.

Best, Alexandre

On May 13 2020, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 960538: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960538.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   pkg-rust-maintain...@alioth-lists.debian.net
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 960...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 960538: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960538
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

-- 
===
Alexandre Lymberopoulos - lym...@ime.usp.br - http://www.ime.usp.br/~lymber
Instituto de Matemática e Estatística - Universidade de São Paulo
===

Bug#960539: RFP: hydrogen -- advanced drum machine/step sequencer repackaging

2020-05-13 Thread Alexandre Lymberopoulos

Package: wnpp
Severity: wishlist

* Package name: hydrogen
  Version : 1.0.0
  Upstream Author : Hydrogen Audio Team 
* URL : http://hydrogen-music.org/
* License : GPLv2
  Programming Lang: C++
  Description : advanced drum machine/step sequencer

This is a request for repackaging hydrogen, since the last version
relayed on Qt4 (no longer in Debian). This new version based on Qt5 and
could be brought back to the distro..

Thanks in advance.

Best,
Alexandre
-- 
===
Alexandre Lymberopoulos - lym...@ime.usp.br - http://www.ime.usp.br/~lymber
Instituto de Matemática e Estatística - Universidade de São Paulo
===

Bug#960516: fcitx crashes when using fcitx-rime

2020-05-13 Thread Tong

I have same bug. It looks like the ABI is broken in yaml-cpp. Similar bug here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1786775 


Detailed stack trace for rime_deployer:

Program received signal SIGSEGV, Segmentation fault.
0x77e24023 in std::__shared_ptr_access::_M_get (this=0x840fc08548c08949) at 
/usr/include/c++/9/bits/shared_ptr_base.h:1020
1020  _M_get() const noexcept
(gdb) bt
#0  0x77e24023 in std::__shared_ptr_access::_M_get (this=0x840fc08548c08949) at 
/usr/include/c++/9/bits/shared_ptr_base.h:1020
#1  std::__shared_ptr_access::operator-> (this=0x840fc08548c08949) 
at /usr/include/c++/9/bits/shared_ptr_base.h:1015
#2  YAML::detail::node_ref::type (this=0x840fc08548c08949) at 
/usr/include/yaml-cpp/node/detail/node_ref.h:25
#3  YAML::detail::node::type (this=0x7797ea94 <__GI___libc_malloc+116>) at 
/usr/include/yaml-cpp/node/detail/node.h:30
#4  YAML::Node::Type (this=0x7fffdf70) at 
/usr/include/yaml-cpp/node/impl.h:89
#5  0x77e1f425 in rime::ConfigData::ConvertFromYaml (node=..., 
compiler=0x0) at ./src/rime/config/config_data.cc:252
#6  0x77e20712 in rime::ConfigData::LoadFromFile (this=0x5557e430, 
file_name="installation.yaml", compiler=compiler@entry=0x0) at 
./src/rime/config/config_data.cc:68
#7  0x77e1b88b in rime::Config::LoadFromFile 
(this=this@entry=0x5557e400, file_name="installation.yaml") at 
/usr/include/c++/9/bits/shared_ptr_base.h:1020
#8  0x77f00b54 in rime::SchemaUpdate::Run (this=0x7fffe310, 
deployer=0x5557a3f0) at ./src/rime/lever/deployment_tasks.cc:331
#9  0x89e6 in main (argc=, argv=) at 
./tools/rime_deployer.cc:114

Bug#925391: task-japanese-desktop and others: Gnome-wayland compatible input method

2020-05-13 Thread Holger Wansing

Hi Osamu,

Osamu Aoki  wrote:
> Package: tasksel
> Version: 3.51
> Severity: normal
> 
> We will ship wayland enabled Gnome as the default for Buster!
> So we need to adjust to this environment.
> 
> Trying to enable current default input method for Japanese under wayland
> caused big side effect.  So the feature to enable uim requires user to
> manually enable this work around intentionally (this still needs to be
> unblocked)
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925160
> 
> So for default install, it is essential to use ibus family which is
> upstream supported.  im-config doesn't need to do anything.  gnome takes
> catrare by gnome-session in main.c which hard codes ibus there.  (I
> know, japanese liek uim, Chinese like fcitx)
> 
> Proposed task data
> ==
> 
> In light of this, I propose to change task-japanese-desktop to the
> following:
> 
> task-japanese-desktop (kmuto)
>   --\ Depends (1)
> --- tasksel (= 3.50)
>   --\ Recommends (11)
> --- ibus-mozc | ibus-anthy | ibus-skk | ibus-kkc
> --- firefox-esr-l10n-ja | firefox-l10n-ja
> --- fonts-ipafont
> --- fonts-vlgothic
> --- libreoffice-help-ja
> --- libreoffice-l10n-ja
> --- poppler-data

Slightly late for Buster :(
Is this still valid for Bullseye?

I attached a patch, to set it up as proposed above.

Holger


> Here, simply picking one of the ibus-* pulls in all you need  via
> recommends.  Configuration utility is gnome-shell script provided by
> Gnome.  gnome-shell already requires gir1.2-ibus-1.0 thus installs
> libibus-1.0-5.  So going with ibus is upstream choice.
> 
> FYI: OLD SETTINGS are the following
> task-japanese-desktop
>   --\ Depends (1)
> --- tasksel (= 3.50)
>   --\ Recommends (11)
> --- anthy
> --- firefox-esr-l10n-ja | firefox-l10n-ja
> --- fonts-ipafont
> --- fonts-vlgothic
> --- libreoffice-help-ja
> --- libreoffice-l10n-ja
> --- mozc-utils-gui
> --- poppler-data
> --- uim
> --- uim-anthy
> --- uim-mozc
> 
> Other consideration:
> 
> 
> Traditional DMs on X:
> =
> im-config pulled in by the dependency will automatically set up system
> including configuration dialog.  So this change has minimal impact.  
> 
> Why ibus-mozc as the first choice? 
> ==
> I know anthy currently suffers conversion errors.  I suspect
> inconsistent encoding of its dictionary data is the root cause.  It
> looks like the conversion to UTF-8 had errors. (This is not ibus
> problem.  It is same under uim or fcitx.
> 
> KDE seems to chose SCIM?  Should we care?
> =
> 
> plasma-desktop  depends on libscim8v5 from SCIM family.  Should we care
> like what we do for Gnome?  I have no answer.
> 
> All I know is KDE doesn't play nice with ibus.  You can kill ibus icon
> program with mouse click.  No easy way to get back.
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922334
> 
> I wonder these input methods may better move to 
> task such as 
>task-japanese-gnome-desktop 
>task-japanese-kde-desktop
> Then they can have their own way.  (Of course, we may leave out other DM
> people.)
> 
> What is going to happen on Chinese tasks
> 
> They love fcitx.  Does anyone know what they do.  we may have answer
> there too.
> 
> Long term:
> ==
> 
> If we can use trigger to update choice of configuration im-config
> calcurate when user process starts in advance, then enabling im-config
> even for wayland may be an option.  But it's too late for buster.
> 
> Also, I think if someone knows better than me and have time, make
> current ibus related code in gnome-session/gnome-shell to be
> patched/extended to allow other input methods to be used.
> 
> We need volunteer for it.  (Including option to replace im-config input
> method configuration system to Ubuntu equivalent, if that solves.)


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index e5efda6a..738933fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,8 @@ tasksel (3.60) UNRELEASED; urgency=medium
 fonts-noto-core and fonts-noto-ui-core. Closes: #949766
   * Drop no-longer existing kde-l10n-* packages from various tasks.
 Closes: #949694
+  * task-japanese-desktop: switch to Gnome-wayland compatible input method
+(ibus). Closes: #925391
 
  -- Holger Wansing   Sun, 05 Apr 2020 17:23:01 +0200
 
diff --git a/debian/control b/debian/control
index 74400639..1a2c137c 100644
--- a/debian/control
+++ b/debian/control
@@ -1334,14 +1334,10 @@ Description: Japanese desktop
  This task localises the desktop in Japanese.
 Depends: ${misc:Depends},
 Recommends:
+	ibus-mozc | ibus-anthy | ibus-skk | ibus-kkc,
 	firefox-esr-l10n-ja | firefox-l10n-ja,
 	fonts-vlgothic,
 	fonts-ipafont,
-	uim,
-	uim-anthy,
-	uim-mozc,
-

Bug#960524: Please provide a startup script for installations not using systemd

2020-05-13 Thread Rob J. Epping

Package: zram-tools
Version: 0.3.2.1-1
Severity: normal

Dear Maintainer,

Debian allows for other init systems as well, please provide startup
scripts for these too.

Looking at the script /usr/sbin/zramswap, a quick solution could be to
move this script to /ets/init.d

THNX && GRTNX,
RobJE

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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- no debconf information

Bug#960538: RFP: ffsend -- A fully featured Firefox Send command line client

2020-05-13 Thread Alexandre Lymberopoulos

Package: wnpp
Severity: wishlist

* Package name: ffsend
  Version : 0.2.61
  Upstream Author : Tim Visée < 3a4fb3964f@sinenomine.email>
* URL : https://github.com/timvisee/ffsend
* License : GNU GPL-3.0
  Programming Lang: C++
  Description : Easily and securely share files and directories from the 
command line through a safe, private and encrypted link using a single simple 
command. Files are shared using the Send service and may be up to 1GB (2.5GB 
authenticated). Others are able to download these files with this tool, or 
through their web browser.

It is always desirable to have command-line options for any piece of
software. It comes more relevant when it provides access to such an
important feature like Firefox Send for sharing (large) files
securely. I do not know any other software packaged in Debian for this
purpose.

I have no experience maintaining packages, unfortunately I can't help in
here.

Thanks in advance, Alexandre
-- 
===
Alexandre Lymberopoulos - lym...@ime.usp.br - http://www.ime.usp.br/~lymber
Instituto de Matemática e Estatística - Universidade de São Paulo
===

Bug#960132: mdadm: mdcheck_start.service trying to start unexisting file

2020-05-13 Thread Павел Мотырев

Bug affects all versions since release 4.1-1 - systemd services for
mdcheck was created in
0004-mdcheck-add-systemd-unit-files-to-run-mdcheck.patch
(https://sources.debian.org/patches/mdadm/4.1-1/0004-mdcheck-add-systemd-unit-files-to-run-mdcheck.patch/)

Bug#960301: firefox-esr: same here: webRTC problem

2020-05-13 Thread Andreas B. Mundt

Package: firefox-esr
Version: 68.8.0esr-1
Followup-For: Bug #960301

Dear Mike,

I can confirm the issue here.  Since the last upgrade of firefox, I'm
not able to use firefox for webRTC sessions anymore.  To be sure, I
checked with an old laptop: Before the upgrade it worked fine, after
the upgrade it doesn't.  Chromium works fine so far.

Best regards,

  Andi
  


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-7
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.13.12-1
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10.1.0-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.44.7-4
ii  libsqlite3-0  3.31.1-5
ii  libstartup-notification0  0.12-6
ii  libstdc++610.1.0-1
ii  libx11-6  2:1.6.9-2+b1
ii  libx11-xcb1   2:1.6.9-2+b1
ii  libxcb-shm0   1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

Bug#960271: PATCH

2020-05-13 Thread Salvatore Bonaccorso

HI Alex,

On Tue, May 12, 2020 at 02:05:14PM +0100, Alex Bennée wrote:
> 
> This patch adds Christian Borntraeger's patch (467d12f5c784) to the
> package build. It seemed to build OK following these steps:
> 
>   wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118.tar.xz
>   ./debian/bin/genorig.py linux-4.19.118.tar.xz
>   make -f debian/rules orig
>   make -f debian/rules source
>   dpkg-buildpackage
> 
> Once I install the package I can build QEMU again.

Thanks, queued up the cherry-picked commit in our buster branch, tough
this will be dropped as soon we reach 4.19.120 for rebase.

https://salsa.debian.org/kernel-team/linux/-/commit/a4fb2a7b7688f3a7cb36e17b9d8c661ac44a41a4

Regards,
Salvatore

Bug#960527: libcroco: CVE-2020-12825

2020-05-13 Thread Salvatore Bonaccorso

Hi Simon,

On Wed, May 13, 2020 at 05:02:32PM +0100, Simon McVittie wrote:
> On Wed, 13 May 2020 at 17:21:44 +0200, Salvatore Bonaccorso wrote:
> > CVE-2020-12825[0]:
> > | libcroco through 0.6.13 has excessive recursion in
> > | cr_parser_parse_any_core in cr-parser.c, leading to stack consumption.
> 
> Mitigation: here are the only things in >= stable that depend on libcroco:
> 
> - gnome-shell, cinnamon: I don't think these parse untrusted CSS, only
>   CSS that comes from GNOME Shell itself or a Shell extension (which can
>   execute arbitrary code with the user's privileges *anyway*, so they're
>   inherently trusted).
> 
>   gnome-shell in unstable contains a cut-down fork of croco, in which
>   the developers are deleting unused code and redoing what's left in Rust,
>   using Mozilla's underlying parser; similar reasoning applies to that.
> 
>   cinnamon is basically a fork of an old version of GNOME Shell, so it's
>   still using libcroco.
> 
> - gettext: seems to be part of term-styled-ostream, an ANSI terminal text
>   highlighting library[1], rather than parsing anything untrusted.
> 
>   There is a vendored copy included, but Debian uses the system copy.
> 
> - librsvg in stable
> 
>   In unstable, librsvg was rewritten in Rust, using Mozilla's underlying
>   parser.
> 
> - libccss in stable
> 
>   This package is unmaintained upstream and was removed from
>   testing/unstable.
> 
> (I suspect the GNOME team might end up orphaning libcroco, now that no
> GNOME components depend on it any more.)
> 
> I think the only one of those that's potentially of interest from the
> point of view of denial-of-service in a long-running process is librsvg in
> stable, and even that seems more likely to be used as a batch-mode tool,
> via imagemagick or rsvg-convert(1) or similar.

Thanks for your analysis and overview. FWIW, the issue was marked
earlier no-dsa for stretch and buster, so if/whenever a fix arise
might be enough to adress it via a point release.

Regards,
Salvatore

Bug#960537: python3-html5lib: DeprecationWarning in collections import (will be failure with python3.9)

Package: python3-html5lib
Version: 1.0.1-3
Severity: normal

Currently with python3.7 or 3.8:
DeprecationWarning: Using or importing the ABCs from 'collections' instead of
from 'collections.abc' is deprecated, and in 3.9 it will stop working
  from collections import Mapping

When we get python3.9 it'll be:

Python 3.9.0a2+ (heads/master:b0d4949, Dec 20 2019, 11:38:30)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import html5lib
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/__init__.py",
 line 25, in 
from .html5parser import HTMLParser, parse, parseFragment
  File 
"/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/html5parser.py",
 line 8, in 
from . import _tokenizer
  File 
"/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tokenizer.py",
 line 16, in 
from ._trie import Trie
  File 
"/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_trie/__init__.py",
 line 3, in 
from .py import Trie as PyTrie
  File 
"/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_trie/py.py",
 line 6, in 
from ._base import Trie as ABCTrie
  File 
"/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_trie/_base.py",
 line 3, in 
from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' 
(/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/collections/__init__.py)

I noticed this because python-bleach is looking into updating their
vendored copy (we don't use it) [1].  This change has been in html5lib
for some time [2], but with no release coming, I think we should fix it in
Debian.

Scott K

[1] https://patch-diff.githubusercontent.com/raw/mozilla/bleach/pull/533.diff
[2] 
https://github.com/html5lib/html5lib-python/blob/master/html5lib/_trie/_base.py#L3

Bug#960536: locales: $LANGUAGE and $LC_ALL are not set

2020-05-13 Thread José Antonio Jiménez Madrid

Package: locales
Version: 2.28-10
Severity: minor
Tags: l10n

Hi,

I upgraded yesterday to Buster and in the process of upgrading packages I got
the following perl warning in several packages:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "es_ES.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


In some places I have found "a way to fix it", but this not works for me. I
followed the steps.

export LANGUAGE=es_ES.UTF-8
export LANG=es_ES.UTF-8
export LC_ALL=es_ES.UTF-8
locale-gen
dpkg-reconfigure locales


selecting the generation of all locales and to use es_ES.UTF-8 in the debconf
window. But the problem persists.
Also I have tried to change to another locales, like

en_US.UTF-8

but LANGUAGE and LC_ALL keep unset. Coming back to my original locale does not
fix the problem.

I do not know whether this can be related with bugs:

#687522
#724456


I can make test, send log files,... to find what is causing this problem.

Thank you for your great work !!

Sincerely,
Jose









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

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

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc-bin   2.28-10
ii  libc-l10n  2.28-10

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: All locales
* locales/default_environment_locale: es_ES.UTF-8

Bug#960516: fcitx crashes when using fcitx-rime

2020-05-13 Thread frrcela

Package: fcitx-rime
Version: 0.3.2-7

Dear Maintainer,

Yesterday I upgraded my Debian testing system from testing package-sources, 
unfortunately I found that fcitx-rime had a bug which crashed fcitx today. If 
fcitx-rime is the default input scheme of fcitx, then fcitx can not launch(Ctrl 
+ Space not work) no matter in Xorg or Wayland Gnome. If fcitx-rime is not the 
default input scheme, then fcitx will crash once switching to fcitx-rime. 
However, fcitx will work fine if I use other input scheme rather than 
fcitx-rime.

This is the error report(from running command `fcitx` then switch to 
fcitx-rime):

(ERROR-5872 ime.c:432) fcitx-keyboard-in-tel-kagapa already exists
(ERROR-5872 ime.c:432) fcitx-keyboard-cm-mmuock already exists
=
FCITX 4.2.9.7 -- Get Signal No.: 11
Date: try "date -d @1589372300" if you are using GNU date ***
ProcessID: 5872
fcitx(+0x1927)[0x55bfebc90927]
/lib/x86_64-linux-gnu/libc.so.6(+0x3b7e0)[0x7f40c13387e0]
/lib/x86_64-linux-gnu/librime.so.1(_ZN4YAML4NodeD1Ev+0x21)[0x7f40b776e121]
/lib/x86_64-linux-gnu/librime.so.1(_ZN4rime10ConfigData12LoadFromFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_14ConfigCompilerE+0x1d7)[0x7f40b776b747]
/lib/x86_64-linux-gnu/librime.so.1(_ZN4rime18InstallationUpdate3RunEPNS_8DeployerE+0x3cd)[0x7f40b784f7dd]
/lib/x86_64-linux-gnu/librime.so.1(_ZN4rime8Deployer7RunTaskERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost3anyE+0xb3)[0x7f40b7727c83]
/lib/x86_64-linux-gnu/librime.so.1(RimeStartMaintenance+0xb6)[0x7f40b7708286]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x2e16)[0x7f40b78ece16]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-rime.so(+0x34ac)[0x7f40b78ed4ac]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x111ea)[0x7f40c15221ea]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x14388)[0x7f40c1525388]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(FcitxInstanceSwitchIMByIndex+0x95)[0x7f40c1525fb5]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0x15083)[0x7f40c1526083]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(FcitxInstanceProcessKey+0x956)[0x7f40c1526f36]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-ipc.so(+0x6a70)[0x7f40ba424a70]
/lib/x86_64-linux-gnu/libdbus-1.so.3(+0x26c8d)[0x7f40c0f74c8d]
/lib/x86_64-linux-gnu/libdbus-1.so.3(dbus_connection_dispatch+0x334)[0x7f40c0f657e4]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x28b8)[0x7f40c0fbb8b8]
/usr/lib/x86_64-linux-gnu/fcitx/fcitx-dbus.so(+0x29d1)[0x7f40c0fbb9d1]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(+0xa38a)[0x7f40c151b38a]
/lib/x86_64-linux-gnu/libfcitx-core.so.0(FcitxInstanceRun+0x57)[0x7f40c151bb27]
fcitx(+0x12bf)[0x55bfebc902bf]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f40c1323e0b]
fcitx(+0x133a)[0x55bfebc9033a]

Package info:

Package: fcitx-rime
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 403
Maintainer: Debian Input Method Team 
Architecture: amd64
Multi-Arch: same
Version: 0.3.2-7
Depends: fcitx-bin, fcitx-data (>= 1:4.2.8.1), fcitx-modules, librime-data, 
libc6 (>= 2.14), libfcitx-config4 (>= 4.2.7), libfcitx-qt5-1 (>= 1.0.0), 
libgcc-s1 (>= 3.0), libqt5core5a (>= 5.12.2), libqt5gui5 (>= 5.7.0) | 
libqt5gui5-gles (>= 5.7.0), libqt5widgets5 (>= 5.0.2), librime1 (>= 
1.5.3+dfsg1-5~), libstdc++6 (>= 5.2)
Recommends: fcitx (>= 1:4.2.8.1)
Breaks: fcitx (<< 1:4.2.0)

Package: fcitx
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 50
Maintainer: Debian Input Method Team 
Architecture: all
Version: 1:4.2.9.7-3
Depends: fcitx-bin, fcitx-data, fcitx-modules
Recommends: fcitx-config-gtk | kde-config-fcitx, fcitx-frontend-all | 
fcitx-frontend-fbterm, fcitx-ui-classic | fcitx-ui-light, im-config (>= 0.5)
Suggests: fcitx-m17n, fcitx-tools
Conffiles:
 /etc/X11/xinit/xinput.d/fcitx 16f80add1cac78453353a128af575771

I am using Linux version 5.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 9.3.0 (Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)

Distributor ID:    Debian
Description:    Debian GNU/Linux bullseye/sid
Release:    testing
Codename:    bullseye
APT prefers: testing
APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Bug#960529: libc6: After update the integrated camera (uvcvideo) is not longer detected

2020-05-13 Thread Aurelien Jarno

Hi,

On 2020-05-13 17:45, Reiner Nix wrote:
> Package: libc6
> Version: 2.30-7
> Severity: normal
> 
> After running this morning an upgrade, the camera integrated into my Laptop 
> (Thinkpad T530) is not longer available.

Why do you think the issue is related to libc6? Do you have a list of
packages you have upgraded?

Also how do you check if the camera is available or not? Is it listed
for example in the output of the 'lsusb' command?

Regards,
Aurelien

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

Bug#960534: transition: KDEPIM and KDE Frameworks

2020-05-13 Thread Sandro Knauß

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

KCalCore and KContacts have moved from KDEPIM to KDE Frameworks. In
Frameworks KDE guarantees ABI stability, so it is possible to get rid of
the virtual packages approach and use normal symbols files to track
dependencies.

I will upload KDE Frameworks together with KDEPIM. As KDEPIM needs the
new Frameworks anyways. Outside KDEPIM and KDE Frameworks there are only some 
other packages,
that needs a normal binary upload. I checked these packages already,
that they build successfully:

digikam
kgpg
kio-gdrive
kjots
kmymoney
kraft
zanshin

Ben file:

title = "kdepim 20.04";
is_affected = .depends ~ /libk.*5-19\.08/ | .depends ~ /libk.*5-20\.04/;
is_good = .depends ~ /libk.*5-20\.04/;
is_bad = .depends ~ /libk.*5-19\.08/;

title = "KCalCore to Frameworks";
is_affected = .depends ~ /libkf5calendarcore5abi2/;
is_good = ! .depends ~ /libkf5calendarcore5-19\.08/;
is_bad = .depends ~ /libkf5calendarcore5-19\.08/;

title = "KContacts to Frameworks";
is_affected = .depends ~ /libkf5contacts5/;
is_good = ! .depends ~ /libkf5contacts5-19\.08/;
is_bad = .depends ~ /libkf5contacts5-19\.08/;

Bug#960535: python3-websocket: Update to the latest version, 0.57.0

2020-05-13 Thread Trygve Aaberge

Package: python3-websocket
Severity: wishlist

Dear Maintainer,

Please update python3-websocket to the latest upstream version which
currently is 0.57.0, released in December 2019.

Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled

2020-05-13 Thread Jochen Sprickerhof


Hi Anton,

* Anton Zinoviev  [2020-05-13 15:16]:

Well, the package is not unusable.  It is usable by all X programs which
do not rely on fontconfig.


I agree.


On the other hand, programs which rely on fontconfig should probably use
the fonts in fonts-terminus-otb instead of the fonts in this package.
Practically, this means that most users should install
fonts-terminus-otb instead xfonts-terminus.


I'm ok with that, except I found that I had to adopt the width of the 
otb version by 0.85 to resemble the one of the pcf. Specifically I 
compared Terminus:pixelsize=14 to ter-u14n_iso-8859-1.pcf.gz in the 
suckless terminal st, setting cwscale=0.85 in the config. Is the 
different width on purpose?



I don't like the fact that after upgrade the Terminus fonts are not
enabled.  But I am not sure what is the proper fix for this.  One
possible course of action would be to:

1. rename xfonts-terminus => xfonts-terminus-pcf
2. create an empty package xfonts-terminus depending on both
  xfonts-terminus-pcf and fonts-terminus-otb

But isn't this an overkill?


I agree, maybe add a Recommends: fonts-terminus-otb so people upgrading 
from xfonts-terminus still have a working setup?


Cheers Jochen


signature.asc
Description: PGP signature

Bug#960533: apt: parser error : xmlParseEntityRef

2020-05-13 Thread Nicolas Patrois

Package: apt
Version: 2.1.1
Severity: normal

Dear Maintainer,

I don’t know if it is an apt bug or not.
Just after having read the sources, apt complains about malformed XML files:

Entity: line 4: parser error : xmlParseEntityRef: no name
e original message barList of languages in a config file instead iso-codesFind
&
^
Entity: line 8: parser error : EntityRef: expecting ';'
- get haircut @s 24 @r d  14 @o r
   ^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y  4  11  2, 3, 4, 5, 6, 7, 8  TU
   ^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y  4  11  2, 3, 4, 5, 6, 7, 8  TU
^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y  4  11  2, 3, 4, 5, 6, 7, 8  TU
  ^
Entity: line 11: parser error : EntityRef: expecting ';'
@r y  4  11  2, 3, 4, 5, 6, 7, 8  TU
 ^
I didn’t have this message since today.



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "i386";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-image-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-headers-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-headers-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-modules-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-modules-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^gnumach-image-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^gnumach-image-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^.*-modules-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^.*-modules-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^.*-kernel-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^.*-kernel-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-tools-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-tools-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.4\.0-2-686-pae$";
APT::NeverAutoRemove:: "^linux-source-4\.17\.0-3-686-pae$";
APT::NeverAutoRemove:: "^linux-source-5\.4\.0-2-686-pae$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "0";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "[ ! -f

Bug#955695: probably because of libsmali-java update from 2.3.3 to 2.4

2020-05-13 Thread Hans-Christoph Steiner



My guess is that this issue was caused by the libsmali-java update from
2.3.3 to 2.4.  Hopefuilly its a small fix.

Bug#960532: pulseaudio: Pulseaudio reselect HDMI output with each application

2020-05-13 Thread José Antonio Jiménez Madrid

Package: pulseaudio
Version: 12.2-4+deb10u1
Severity: normal

Hi,

I upgraded yesterday to Buster. After upgrade sound stopped to work. I purged
timidity and now I can select the output between my two audio devices. My lspci
output is:

00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio
Controller
02:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio
Controller (rev a1)

PROBLEM: If I set the output the Intel device it works for one application,
when I try to open other application the output is set to NVIDIA HDMI.
Playing with the sound preferences, when I am choosing between the different
outputs of my Intel device, it suddenly change to the HDMI output. If I reset
the Intel device I cannot hear any sound, so I have to close the application
(music player as example) to open it again.

It would be very nice that pulseaudio does not change the sound output I have
set to utilise. Also, I would appreciate that pulseaudio remember the sound
settings between reboots and does not change automatically to HDMI.

I removed my local pulseaudio configuration files, but the situation is not
fixed. System configuration files are the provided by package. I have touched
nothing.

At this moment I have turn off the HDMI output to prevent to be automatically
selected when I change between applications.

If you need more information, I will be very happy to provide logs, config
files, to perform test,

Thank you so much for your great work !!

Sincerely,

Jose
















-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   1.1.8-1
ii  libasound2-plugins   1.1.8-1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libdbus-1-3  1.12.16-1
ii  libgcc1  1:8.3.0-6
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-9
ii  liborc-0.4-0 1:0.4.28-3.1
ii  libpulse012.2-4+deb10u1
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   8.3.0-6
ii  libsystemd0  241-7~deb10u4
ii  libtdb1  1.3.16-2+b1
ii  libudev1 241-7~deb10u4
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 10.2019051400
ii  pulseaudio-utils 12.2-4+deb10u1

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.16-1
ii  libpam-systemd 241-7~deb10u4
ii  rtkit  0.11-6

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 241-7~deb10u4

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
#

Bug#960531: acorn: Drop build dependency on node-babel-preset-airbnb

2020-05-13 Thread Pirate Praveen


Package: src:acorn
Version: 6.2.1+ds+~cs11.24.3-2
Severity: important
Control: block 960433 by -1

We'd like to remove src:node-babel from the archive in favor of 
src:node-babel7. [1]
node-babel-helper-builder-react-jsx - BLOCKED by 
node-babel-plugin-transform-react-jsx 
node-babel-plugin-transform-react-jsx - BLOCKED by 
node-babel-preset-react node-babel-preset-react BLOCKED by 
node-babel-preset-airbnb node-babel-preset-airbnb - 960433 - blocked by 
acorn



I'd have liked to try fixing it myself, but the git repo is in a bit of 
mess. It uses git-dpm to manage patches but new upstream version is not 
recongnized by git-dpm. Also I'm not sure if git-dpm works well with 
multiple tarballs ("multiple upstream tarballs are implemented but 
could need some testing"). [2]


$ git-dpm prepare
git-dpm: WARNING: 'upstream' has changes not yet recorded! (perhaps you 
need record-new-upstream?)


I guess bp import-orig was used to import new upstream release.

[1] https://wiki.debian.org/Javascript/Nodejs/Transitions/Babel7
[2] https://wiki.debian.org/PackagingWithGit/GitDpm

Bug#960530: mark golang-github-kr-pty-dev Multi-Arch: foreign

Package: golang-github-kr-pty-dev
Version: 1.1.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:acbuild src:badger src:balboa

golang-github-kr-pty-dev is another go library that happens to be in the
build dependency tree of many source packages that build architecture
dependent packages. I've listed three affected example packages above.
Since it is Architecture: all, it cannot satisfy cross Build-Depends at
all. Fortunately, marking it Multi-Arch: foreign is a good option here
as it doesn't have any maintainer scripts nor dependencies. Please
consider applying the attached patch to move cross building go packages
forward.

Helmut
diff --minimal -Nru golang-pty-1.1.6/debian/changelog 
golang-pty-1.1.6/debian/changelog
--- golang-pty-1.1.6/debian/changelog   2019-08-07 14:20:47.0 +0200
+++ golang-pty-1.1.6/debian/changelog   2020-05-13 17:28:45.0 +0200
@@ -1,3 +1,10 @@
+golang-pty (1.1.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-kr-pty-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 13 May 2020 17:28:45 +0200
+
 golang-pty (1.1.6-1) unstable; urgency=medium
 
 New upstream version 1.1.6
diff --minimal -Nru golang-pty-1.1.6/debian/control 
golang-pty-1.1.6/debian/control
--- golang-pty-1.1.6/debian/control 2019-08-07 14:20:14.0 +0200
+++ golang-pty-1.1.6/debian/control 2020-05-13 17:28:42.0 +0200
@@ -18,6 +18,7 @@
 
 Package: golang-github-kr-pty-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Breaks: golang-pty-dev (<< 0.0~git20151007.0.f7ee69f-1~)
 Provides: golang-pty-dev

Bug#959481: alpine: does not connect with TLS to smtp/imap server

2020-05-13 Thread Eduardo Chappa


On Wed, 13 May 2020, Βασίλειος A. Ζοῦκος wrote:


I think that the problem has been solved and I would like to thank
all of you for your prompt responses.


I am glad to read the problem is solved, but I would like to encourage 
Debian to not to do this kind of changes by default in its encryption 
library. Instead, my adivce is that the reasons that lead to these changes 
be taken as a minimum of what Debian should support. There are many users 
that for valid reasosn cannot use more modern encryption protocols, and so 
when I support software, I have to support users to use the low encryption 
protocol if that is all they can afford, but make the default the high 
encryption protocols. That is what encryption libraries offer, and users 
should be able to pick using lower encryption protocols, if they so wish 
to, or only use high encryption protocols, if they can do so, but that 
should be a choice of a user on a case by case basis, not a blanket rule 
to apply to everyone. This is an example of what could happen when you 
decide to do so. We might see this experience become a FAQ if Debian 
continues to do this.


--
Eduardo

Bug#960527: libcroco: CVE-2020-12825

2020-05-13 Thread Simon McVittie

On Wed, 13 May 2020 at 17:21:44 +0200, Salvatore Bonaccorso wrote:
> CVE-2020-12825[0]:
> | libcroco through 0.6.13 has excessive recursion in
> | cr_parser_parse_any_core in cr-parser.c, leading to stack consumption.

Mitigation: here are the only things in >= stable that depend on libcroco:

- gnome-shell, cinnamon: I don't think these parse untrusted CSS, only
  CSS that comes from GNOME Shell itself or a Shell extension (which can
  execute arbitrary code with the user's privileges *anyway*, so they're
  inherently trusted).

  gnome-shell in unstable contains a cut-down fork of croco, in which
  the developers are deleting unused code and redoing what's left in Rust,
  using Mozilla's underlying parser; similar reasoning applies to that.

  cinnamon is basically a fork of an old version of GNOME Shell, so it's
  still using libcroco.

- gettext: seems to be part of term-styled-ostream, an ANSI terminal text
  highlighting library[1], rather than parsing anything untrusted.

  There is a vendored copy included, but Debian uses the system copy.

- librsvg in stable

  In unstable, librsvg was rewritten in Rust, using Mozilla's underlying
  parser.

- libccss in stable

  This package is unmaintained upstream and was removed from
  testing/unstable.

(I suspect the GNOME team might end up orphaning libcroco, now that no
GNOME components depend on it any more.)

I think the only one of those that's potentially of interest from the
point of view of denial-of-service in a long-running process is librsvg in
stable, and even that seems more likely to be used as a batch-mode tool,
via imagemagick or rsvg-convert(1) or similar.

smcv

[1] Yes, really.

Bug#960529: libc6: After update the integrated camera (uvcvideo) is not longer detected

2020-05-13 Thread Reiner Nix

Package: libc6
Version: 2.30-7
Severity: normal

After running this morning an upgrade, the camera integrated into my Laptop 
(Thinkpad T530) is not longer available.




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

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.1.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.74
pn  glibc-doc  
ii  libc-l10n  2.30-7
ii  locales2.30-7

-- debconf information:
  glibc/restart-services:
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/disable-screensaver:
* libraries/restart-without-asking: true
  glibc/restart-failed:
  glibc/kernel-not-supported:

Bug#960528: src:wiredtiger: Builds on other 64bit architectures

2020-05-13 Thread Stefano Rivera

Package: src:wiredtiger
Version: 2.9.3+ds-1
Severity: normal

Ubuntu has been carrying a patch to keep wiredtiger building on other
architectures. It looks like upstream has been taking patches to port to
64bit architectures.

Wiredtiger has been reliably building in Ubuntu on arm64, ppc64el, and
s390x, as well as amd64. Verified with 3.2.1 on Debian porterboxes, too.

So, maybe allow building on any 64bit arch? Or the ones it is known to
build on?

SR

Bug#960527: libcroco: CVE-2020-12825

2020-05-13 Thread Salvatore Bonaccorso

Source: libcroco
Version: 0.6.13-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libcroco/-/issues/8

Hi,

The following vulnerability was published for libcroco.

CVE-2020-12825[0]:
| libcroco through 0.6.13 has excessive recursion in
| cr_parser_parse_any_core in cr-parser.c, leading to stack consumption.


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-2020-12825
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12825
[1] https://gitlab.gnome.org/GNOME/libcroco/-/issues/8

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#960501: src:speex: Maintainer and NMU disagree on VCS location

2020-05-13 Thread Boyuan Yang

Hi all,

在 2020-05-13星期三的 11:57 +0100，Simon McVittie写道：
> Source: speex
> Version: 1.2~rc1.2-1
> Severity: normal
> X-Debbugs-Cc: Boyuan Yang 
> 
> speex_1.2rc1.2-1 (the most recent maintainer upload, in 2014) has:
> 
> Vcs-Git: git://git.debian.org/users/ron/speex.git
> 
> which no longer exists. The closest equivalent appears to be
> ;.
> 
> The speex_1.2rc1.2-1.1 NMU has:
> 
> Vcs-Git: https://salsa.debian.org/debian/speex.git
> 
> which appears to be an independent re-import, without full history.
> 
> It is not usually considered appropriate for an NMU to change the
> canonical VCS location where a package is maintained. If the package
> is still maintained by its maintainer of record, any changes to the VCS
> platform/location should have been approved by that maintainer.
> 
> Alternatively, if the package is unmaintained
> and is being "salvaged", the salvaging process
> <
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> >
> should have been followed, which does not seem to have happened here.
> 
> To the maintainer: please make a maintainer upload, acknowledging
> the NMU changes (or rejecting them, if they are inappropriate) and
> setting the VCS to the maintainer's preferred location. If that is not
> https://salsa.debian.org/debian/speex.git then someone will also need
> to ask the salsa.debian.org administrators to delete that repository.
> 
> To possible future NMU'ers: please use the maintainer's preferred
> VCS location, if that can be determined, instead of starting a new
> VCS location.

Thanks for raising this issue. I was not aware of 
https://salsa.debian.org/ron/speex at all when making that NMU.

Ron: please feel free to update the Vcs-* fields with the new maintainer
upload. Let me know if you need any help.

-- 
Regards,
Boyuan Yang


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

Bug#957007: arpack: ftbfs with GCC-10

2020-05-13 Thread Petersson, Oegmundur

Hello,

The attached patch fixes the bug you reported below; it simply replaces scalar 
variables as actual arguments in calls to various print routines in ARPACK with 
(/ scalar /) to turn them into a rank 1 array with a single entry. The dummy 
arguments are defined as datatype(*) so the error reported by gcc is correct.

Best regards

Ögmundur



On Fri, 17 Apr 2020 10:56:33 + Matthias Klose  wrote:
> Package: src:arpack
> Version: 3.7.0-3
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
>
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.
>
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc10-20200225/arpack_3.7.0-3_unstable_gcc10.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
>   apt-get -t=experimental install g++
>
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped
The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.


arpack_gcc10.patch
Description: arpack_gcc10.patch

Bug#944738: Also occurs with openjdk-14-jdk 14.0.1+7-1

2020-05-13 Thread Felicia P

I can confirm that this jlink related bug also occurs with Debian 
openjdk-14-jdk:amd64 14.0.1+7-1.  I installed Oracle JDK 14.0.1 
https://jdk.java.net/14/  and the problem does not occur.

Bug#960526: ITP: azure-kusto-python -- Microsoft Azure Kusto (Azure Data Explorer) SDK for Python

2020-05-13 Thread Luca Boccassi

Package: wnpp
Severity: wishlist
Owner: "Luca Boccassi" 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: azure-kusto-python
  Version : 0.0.45
  Upstream Author : Microsoft
* URL : https://github.com/Azure/azure-kusto-python
* License : MIT
* Programming Lang: Python
* Description : Microsoft Azure Kusto (Azure Data Explorer) SDK for Python

Client library in Python that makes it easy to interface with Azure Kusto
databases.

Initially I will only enable azure-kusto-data, a Python module which
allows to write scripts to extract data from Kusto.
The other module in this source, azure-kusto-ingest, allows to upload
data and has additional dependencies. I might enable it in the near
future.

-- 
Kind regards,
Luca Boccassi


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

Bug#960525: mark golang-github-mattn-go-runewidth-dev Multi-Arch: foreign