Bug#935379: [Pkg-javascript-devel] Bug#935379: pkg-js-tools: add Depends on grunt

[Xavier]

Le 22/08/2019 à 07:30, mer...@debian.org a écrit :
> Package: pkg-js-tools
> Version: 0.9.7
> 
> Hello,
> 
> nodejs buildsystem uses grunt, thus pkg-js-tools should pull in grunt.

Hi, sorry but I don't understand this issue. pkg-js-tools has already a
grunt auto_build

Bug#935379: pkg-js-tools: add Depends on grunt

[merkys]

Package: pkg-js-tools
Version: 0.9.7

Hello,

nodejs buildsystem uses grunt, thus pkg-js-tools should pull in grunt.

Best,
Andrius

Bug#935378: lektor: Package the admin UI

[Sunil Mohan Adapa]

Package: lektor
Version: 3.1.1-1
Severity: wishlist

Dear Maintainer,

lektor has an administration UI that allows users to edit pages using a CMS
like interface. This is typically accessed by running 'lektor serve', then
visiting http://127.0.0.1:5000/ and clicking on the edit button on the top
right corner of the static page.

Currently, lektor's Debian package does not build the administration interface
present in the directory lektor/admin/. This results in 404 errors generated by
visiting the administrator interface of lektor. Administration interface is
usually built by running 'make build-js' in the root directory. This in-turn
uses 'npm' and several node modules. Most of these node modules seem to be
already packaged for Debian.

Please consider building and packaging the administration UI for lektor as part
of the lektor's Debian package.

Lektor being used by the FreedomBox project and we are considering making it
available for users as a FreedomBox app. Thank you for packaging lektor.

--
Sunil



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

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

Versions of packages lektor depends on:
ii  python33.7.3-1
ii  python3-babel  2.6.0+dfsg.1-1
ii  python3-click  7.0-1
ii  python3-exif   2.1.2-1
ii  python3-flask  1.0.2-3
ii  python3-inifile0.4-1
ii  python3-jinja2 2.10-2
ii  python3-mistune0.8.4-1
ii  python3-pip18.1-5
ii  python3-pkg-resources  40.8.0-1
ii  python3-requests   2.21.0-1
ii  python3-watchdog   0.9.0-1

lektor recommends no packages.

lektor suggests no packages.

-- no debconf information

Bug#935377: run-mailcap: "my" variable $file masks earlier declaration in same scope

[martin f krafft]

Package: mime-support
Version: 3.63
Severity: minor
File: /usr/bin/run-mailcap

Since the last update, run-mailcap now produces the following 
warning on every run:


 "my" variable $file masks earlier declaration in same scope at 
/usr/bin/run-mailcap line 339.

I don't understand the logic around line 339, but it doesn't look 
like the current code is intentional. Could there be a bug? Or at 
the very least, one of the "my" needs to go…


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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.6-9.2
ii  file  1:5.37-5
ii  xz-utils  5.2.4-1

mime-support suggests no packages.

--
no debconf information


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#934314: GnuTLS race causes HTTPS bad requests

[Ian Eure]

Tatsuya Kinoshita  writes:


Anyway, this bug will be fixed in the Emacs 26.3 release.

Is there any chance of that getting included in 10.1 or 10.2?  I 
was hoping one of the upcoming bugfix releases might get a new 
Emacs with the fix included.


I’m aware of the workarounds, but I think they’re inadvisable, 
particularly for folks using Emacs for things like email, even 
more so if they’re going to be required until bullseye.


 -- Ian

Bug#934947: #934947 → Problem solved

[Timur Irikovich Davletshin]

Problem was in /etc/fonts/local.conf which disables embedded bitmaps
(embeddedbitmap option).

Regards,

Timur.

Bug#935376: RM: buffycli -- ROM; Unmaintained & dependencies about to be removed

[martin f krafft]

Package: ftp.debian.org
Severity: normal

As requested in Bug#935375.

--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#925232: RM: libbuffy-bindings -- ROM; Not used/maintained

[Scott Kitterman]

On Mon, 25 Mar 2019 11:52:08 -0400 Scott Kitterman  
wrote:
> On Thu, 21 Mar 2019 15:47:53 +0100 Enrico Zini  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > Hello,
> > 
> > I don't use/maintain libbuffy-bindings anymore.
> > 
> > I'd like to get it removed from unstable/testing/buster before it ends
> > up in a stable release.

Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935375 to give the 
buffycli maintainer warning.

Scott K

Bug#935375: buffycli: Depends on to be removed libs

[Scott Kitterman]

Package: buffycli
Version: 0.7-1
Severity: serious
Justification: Policy 3.5

The libbuffy-bindings/libbuffy maintainer has requested these packages
be removed from Debian.  Please either request rm of this package or
port it to no longer require the libbuffy bindings.

Scott K

Bug#935223: 935223

[Antonio Russo]

I have a port of kcollectd to qt5 that I've been running locally for last few 
months.
Is it possible to get this included, and the package brought back?

Bug#935374: mate-desktop-environment: recommends the installation of gvfs-fuse

[Juan Picca]

Package: mate-desktop-environment
Severity: normal

With the default instalation of mate desktop using tasksel (package
`task-mate-desktop`) the package `gvfs-fuse` does not install.
`gvfs-fuse` is needed to access the filesystems mounted with gio
from the console.
As an example, when a user mounts a samba shared folder using `gio
mount`, the package is needed to access the files from the console
(accessing to `/run/user/$UID/gvfs`).

The calculation of the reverse dependencies for `gvfs-fuse`
(`apt-cache rdepends gvfs-fuse`) shown that the majority of desktops
installs it (with the exception of kde and lxde):

* gnome-core: depends
* pcmanfm-qt: recommends (pcmanfm-qt is a dependency of lxqt-core)
* pcmanfm: recommends (pcmanfm is a dependency of lxde-core)
* nemo: recommends (nemo is a dependency of cinnamon-core)
* cinnamon-core: recommends

Why i think that the recommends dependency need to be added to the
package mate-desktop-environment instead of
mate-desktop-environment-core?
According to the description of the packages, the package
mate-desktop-environment *recommends* the standard set of applications
of the mate desktop meanwhile the package mate-desktop-environment-core
*depends* on a very basic set of programs in order to start the
desktop session.

Bug#935373: gpsbabel: workaround for "garmin_fit" files that occasionally have "Bad endian field"

[Tim Connors]

Package: gpsbabel
Version: 1.6.0+ds-5
Severity: normal
Tags: patch upstream

I have a device that occasionally seems to forget to initialise parts
of itself.  When it does this, the "garmin_fit" tracks it save aren't
readable by gpsbabel.  Normally they are.  The symptom is:

24874,32> gpsbabel -i garmin_fit -f can\'t-read-0545.fit -o gpx -F 
/tmp/0545.gpx
fit: Bad endian field

When run with the attached patch though (which may need to be refined
to perhaps require the user to first set a "ignore_endian_errors"
flag, or just treat it as Situation Normal and just send the output to
the debug logs instead), the output file appears to be entirely valid.
The patch ends up just treating the endian uint8 as a boolean:

--- a/garmin_fit.cc
+++ b/garmin_fit.cc
@@ -253,7 +253,7 @@
   // second byte is endianness
   def->endian = fit_getuint8();
   if (def->endian > 1) {
-fatal(MYNAME ": Bad endian field\n");
+warning(MYNAME ": Bad endian field: %d\n",def->endian);
   }
   fit_data.endian = def->endian;


The result I get on my two example files are:

0-0-12:11:01, Thu Aug 22 tconnors@weinberg:~/tracks (bash)
24875,33> gpsbabel -i garmin_fit -f can\'t-read-0545.fit -o gpx -F 
/tmp/0545.gpx
fit: Bad endian field: 229
fit: Bad endian field: 186
0-0-12:20:08, Thu Aug 22 tconnors@weinberg:~/tracks (bash)
24876,34> gpsbabel -i garmin_fit -f can\'t-read-0545-2.fit -o gpx -F 
/tmp/0545-2.gpx
fit: Bad endian field: 19
fit: Bad endian field: 69


I'll see whether I can upload an example file exhibiting the problem...


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

Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gpsbabel depends on:
ii  libc6 2.28-6
ii  libgcc1   1:8.3.0-6
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libshp2   1.4.0-1
ii  libstdc++68.3.0-6
ii  libusb-0.1-4  2:0.1.12-30
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gpsbabel recommends:
ii  gpsbabel-doc  1.5.4-2

gpsbabel suggests no packages.

-- no debconf information

Bug#929923: missing dictionaries.xcu confuses non-US English locales (e.g. en_AU)

[Trent W. Buck]

Rene Engelhard wrote:
> On Wed, Aug 21, 2019 at 03:44:36PM +1000, Trent W. Buck wrote:
> > I still advocate solving only MY problem, with a simple change:
> > 
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=929923;filename=929923.patch;msg=22
> 
> And I still say that it at least for en_GB is wrong.
> As said: color vs. colour.
> You say that Australia is used to both, OK, I believe so - but I don't think 
> so
> for en_GB.

As I hinted before, mythes-en-us already contains "colour",
though admittedly not in all cases:

bash5$ grep -Fc color /usr/share/mythes/th_en_US_v2.dat
960
bash5$ grep -Fc colour /usr/share/mythes/th_en_US_v2.dat
661

A quick analysis of Debian 10's mythes-en-us [1] shows,

  * About 4.3% of the words are valid British-only words ((276K - 208K) ÷ 1.6M).
  * About 3.8% of the words are valid American-only words ((269K - 208K) ÷ 
1.6M).

So according to hunspell (the same spell-checker LibreOffice uses),
th_en_US_v2.dat is actually more British than American :-)


[1]

bash5$ dpkg-query -W mythes-en-us hunspell hunspell-en-us hunspell-en-gb
hunspell1.7.0-2
hunspell-en-gb  1:6.2.0-1
hunspell-en-us  1:2018.04.16-1
mythes-en-us1:6.2.0-1

bash5$ wc -w /usr/share/mythes/th_en_US_v2.dat | numfmt --to si   # how 
many words in total?
1.6M /usr/share/mythes/th_en_US_v2.dat
bash5$ hunspell -l -d en_US,en_GB /usr/share/mythes/th_en_US_v2.dat | wc -l 
| numfmt --to si  # how many words misspelt in "both" english varieties (i.e. 
false positives)?
208K
bash5$ hunspell -l -d en_US /usr/share/mythes/th_en_US_v2.dat | wc -l | 
numfmt --to si  # how many words misspelt in en_US?
276K
bash5$ hunspell -l -d en_GB /usr/share/mythes/th_en_US_v2.dat | wc -l | 
numfmt --to si  # how many words misspelt in en_GB?
269K



PS: Out of curiosity, I looked up some references re "colour" specifically.

The OED is different enough from en-GB to have its own locale 
(en-GB-oxendict), but
AFAIK it is nevertheless the primary reference for en-GB spelling.
I don't have a dead-tree version; it's online version appears to live here:

https://www.lexico.com/en/definition/color
https://www.lexico.com/en/definition/colour
https://www.lexico.com/en/definition/-our

which simply has rather dogmatic labels "US" and "British",
though it notes that "-our" is merely a "variant spelling".

Fowler (1e) definition of "colo(u)r" (p. 83) directs me to
"See -OR & -OUR", which says

   It is not worth while either to resist such a gradual change or
   to fly in the face of national sentiment by trying to hurry it.

   The American abolition of -our [...] has probably retarded
   rather than quickened English progress in the same direction.

For en-AU, the AGPS Style Manual (5e) on §3.1 through §3.18
(pp. 39-42) simply advises doing whatever Macquarie says.
I don't have a copy of Macquarie handy, and
the online version is paywalled.

Bug#935222: RM: kate4 -- ROM; Obsolete libs - Qt4 removal

[Scott Kitterman]

On Tue, 20 Aug 2019 23:18:51 -0400 Scott Kitterman  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> No longer needed for KDE4.

Process with kde4libs rm when filed.

Scott K

Bug#935219: RM: kactivities -- ROM; Obsolete libs - Qt4 removal

[Scott Kitterman]

On Tue, 20 Aug 2019 23:16:01 -0400 Scott Kitterman  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Not needed for KDE4 anymore.
> 
Process after kde-runtime removal.

Scott K

Bug#935243: Does not work with Thunderbird

[martin f krafft]

Hey,

I downgraded to 60.0.8, but the extensions are apparently also not 
supported. See screenshot attached.


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

"the strength of women comes from the fact
that psychology cannot explain us.
men can be analyzed, women merely adored."
 -- oscar wilde


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#935243: Does not work with Thunderbird

[martin f krafft]

Quoting "Mechtilde Stehmann", who wrote on 2019-08-21 at 20:16 Uhr +0200:

you installed thunderbird from experimental.
In sid I found thunderbird version 1:60.8.0-1.
So webext-tbsync is very usefull in unstable.


Oh right, I am sorry, I have thunderbird pinned to experimental, and 
I forgot about that. I've removed the pin now.


I hope 68 comes out soon. Alternatively, would it be possible to 
package the updated extensions to experimental?


Thanks,

--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

i don't want to get myself into a hot babe situation.
   -- jonathan mcdowell, #debian-uk, 6 jul 2009


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#934483: Processed: Re: Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae

[Ben Hutchings]

Control: reassign -1 virtualbox-guest-dkms 6.0.10-dfsg-4

On Tue, 2019-08-20 at 14:03 +, Debian Bug Tracking System wrote:
> Processing control commands:
> 
> > reassign -1 src:linux

No, this is not our problem to fix.  In answer to your question, which
*wasn't* cc'd to debian-kernel:

> Ben, do you have any clue? should the code include  
> instead?

Yes I think so.  I don't know how it ever worked before.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.



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

Bug#935372: influxdb-python: Please drop python2 support

[Steve Langasek]

Package: influxdb-python
Version: 5.2.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Hi Alexandre,

As you may know, we we are in the process of deprecating python2 in Debian
for the next release.  In Ubuntu, I've identified that it may be useful to
accelerate this deprecation for pandas and its reverse-dependencies, because
the pandas tests appear to have bit-rotted for python2 on one architecture,
and it would be better to remove the python2 bits rather than invest in
fixing them.

influxdb-python build-depends on python-pandas, and is a leaf package with
no python2 reverse dependencies, so I've gone ahead and uploaded the
attached patch to Ubuntu which drops the python2 module.  It should be
possible to upload this change to Debian at your convenience.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru influxdb-python-5.2.0/debian/control 
influxdb-python-5.2.0/debian/control
--- influxdb-python-5.2.0/debian/control2018-08-28 09:44:31.0 
-0700
+++ influxdb-python-5.2.0/debian/control2019-08-21 16:27:58.0 
-0700
@@ -4,17 +4,9 @@
 Maintainer: Alexandre Viau 
 Build-Depends: debhelper (>= 9),
dh-python,
-   python-all,
-   python-setuptools,
python3-all,
python3-setuptools
-Build-Depends-Indep: python-requests (>= 1.0.3),
- python-mock,
- python-requests-mock (>= 0.5.1),
- python-six (>= 0.1.9),
- python-nose,
- python-pandas,
- python3-requests,
+Build-Depends-Indep: python3-requests,
  python3-mock,
  python3-requests-mock (>= 0.5.1),
  python3-six (>= 0.1.9),
@@ -26,20 +18,6 @@
 Homepage: https://pypi.python.org/pypi/influxdb
 Testsuite: autopkgtest-pkg-python
 
-Package: python-influxdb
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- python-requests (>= 1.0.3),
- python-six (>= 0.1.9)
-Description: Client for InfluxDB - Python 2.7
- API bindings for InfluxDB. Supports both InfluxDB v0.8 and InfluxDB >= 0.9.
- InfluxDB is an open source distributed time series database with no external
- dependencies. It's useful for recording metrics, events, and performing
- analytics.
- .
- This package contains the Python 2.7 module.
-
 Package: python3-influxdb
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru influxdb-python-5.2.0/debian/python-influxdb.pyremove 
influxdb-python-5.2.0/debian/python-influxdb.pyremove
--- influxdb-python-5.2.0/debian/python-influxdb.pyremove   2018-08-28 
09:44:31.0 -0700
+++ influxdb-python-5.2.0/debian/python-influxdb.pyremove   1969-12-31 
16:00:00.0 -0800
@@ -1 +0,0 @@
-influxdb*.egg-info/SOURCES.txt
diff -Nru influxdb-python-5.2.0/debian/rules influxdb-python-5.2.0/debian/rules
--- influxdb-python-5.2.0/debian/rules  2018-08-28 09:44:31.0 -0700
+++ influxdb-python-5.2.0/debian/rules  2019-08-21 16:27:44.0 -0700
@@ -7,4 +7,4 @@
 export INFLUXDB_PYTHON_SKIP_SERVER_TESTS=True
 
 %:
-   dh $@ --with python2,python3 --buildsystem=pybuild
+   dh $@ --with python3 --buildsystem=pybuild

Bug#935371: RFP: notqmail -- Collaborative successor to qmail

[Kjetil Kjernsmo]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: p...@smarden.org

* Package name: notqmail
  Version : 1.07
* URL : https://notqmail.org
* License : Mostly public domain 
  Programming Lang: C
  Description : Collaborative successor to qmail

notqmail is software for running an email server. notqmail is a
community-driven fork of qmail, beginning where netqmail left off:
providing stable, compatible, small releases to which existing qmail
users can safely update. notqmail also aims higher: developing an
extensible, easily packaged, and increasingly useful modern mail
server.

As it is built on netqmail, which is already in Debian, the current
packaging should be easy to reuse, and it will start out with the
stable base as a starting point.

Bug#935138: closed by Chris Lamb (Bug#935138: fixed in lintian 2.19.0)

[Chris Lamb]

Hi Guillem,

> The commit message had a typo, so it percolated into the changelog,
> the former cannot be fixed, but the latter can. :)
> 
>   s/Upstream:Version/Upstream-Version/

Done in:

  
https://salsa.debian.org/lintian/lintian/commit/71d551c1cb2bb59b4f3de06a0fa8aa7be5ffadd2

Many thanks for spotting this.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#935138: closed by Chris Lamb (Bug#935138: fixed in lintian 2.19.0)

[Guillem Jover]

Hi!

On Wed, 2019-08-21 at 17:27:17 +, Debian Bug Tracking System wrote:
> Changes:
>  lintian (2.19.0) unstable; urgency=medium
>  .
[…]
>[ Chris Lamb ]
[…]
>* Also check for "${source:Upstream:Version}" etc. in the
>  version-substvar-for-external-package tag, not just
>  "${source:Version}". (Closes: #935138)
[…]

The commit message had a typo, so it percolated into the changelog,
the former cannot be fixed, but the latter can. :)

  s/Upstream:Version/Upstream-Version/

In addition I notice that the code will now match the non-supported
substvar Source-:Upstream-Version. I guess the easiest way to fix
that is to remove matching on Source-Version which is unsupported
now by dpkg-dev anyway.

Thanks,
Guillem

Bug#935370: buster-pu: package lacme/0.5-1+deb10u1

[Guilhem Moulin]

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

Dear release team,

Per RFC 8555 sec 6.3 the Let's Encrypt folks are deprecating
unauthenticated GETs from their v2 API.  Support for these requests will
be removed on *Nov 01 2019* (so likely between Debian 10.1 and 10.2) [0].

lacme uses the v2 API by default since 0.5, and removing support for
unauthenticated GETs means that applying for certificate issuance will
stop working.  Replacing GETs with POST-as-GETs is trivial (debdiff
attached), and I'd like to fix that in Buster via s-p-u.

(0.6 from Sid is not affected, and neither is 0.2 from Stretch as the
latter supports only the v1 API.)

Cheers,
-- 
Guilhem.

[0] 
https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets
diffstat for lacme-0.5 lacme-0.5

 changelog |   10 +
 gbp.conf  |2 
 patches/0002-Issue-GET-and-POST-as-GET-requests.patch |  121 ++
 patches/series|1 
 4 files changed, 133 insertions(+), 1 deletion(-)

diff -Nru lacme-0.5/debian/changelog lacme-0.5/debian/changelog
--- lacme-0.5/debian/changelog  2018-05-09 14:17:19.0 +0200
+++ lacme-0.5/debian/changelog  2019-08-22 00:14:42.0 +0200
@@ -1,3 +1,13 @@
+lacme (0.5-1+deb10u1) buster; urgency=medium
+
+  * Link to RFC 8555  instead of the
+ACME I-D URL.
+  * Issue GET and POST-as-GET requests (RFC 8555 sec. 6.3) for the
+authorizations, order and certificate URLs.   Let's Encrypt will remove
+support of unauthenticated GETs from the V2 API on 01 Nov 2019.
+
+ -- Guilhem Moulin   Thu, 22 Aug 2019 00:14:42 +0200
+
 lacme (0.5-1) unstable; urgency=medium
 
   * New upstream release, adding support for v2 ACME endpoints.
diff -Nru lacme-0.5/debian/gbp.conf lacme-0.5/debian/gbp.conf
--- lacme-0.5/debian/gbp.conf   2018-05-09 14:17:19.0 +0200
+++ lacme-0.5/debian/gbp.conf   2019-08-22 00:14:42.0 +0200
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch = master
-debian-branch = debian
+debian-branch = debian-buster
 upstream-tag = upstream/%(version)s
 debian-tag = debian/%(version)s
 pristine-tar = False
diff -Nru 
lacme-0.5/debian/patches/0002-Issue-GET-and-POST-as-GET-requests.patch 
lacme-0.5/debian/patches/0002-Issue-GET-and-POST-as-GET-requests.patch
--- lacme-0.5/debian/patches/0002-Issue-GET-and-POST-as-GET-requests.patch  
1970-01-01 01:00:00.0 +0100
+++ lacme-0.5/debian/patches/0002-Issue-GET-and-POST-as-GET-requests.patch  
2019-08-22 00:14:42.0 +0200
@@ -0,0 +1,121 @@
+From f9d5e53cac1c002e5983efc18e42f5a21444b182 Mon Sep 17 00:00:00 2001
+From: Guilhem Moulin 
+Date: Wed, 21 Aug 2019 17:29:19 +0200
+Subject: Issue GET and POST-as-GET requests (RFC 8555 sec. 6.3)
+
+For the  authorizations, order and certificate URLs.
+See RFC 8555 sec. 7.1.
+---
+ client|   22 +++---
+ lacme-accountd.md |2 +-
+ lacme.md  |2 +-
+ 3 files changed, 13 insertions(+), 13 deletions(-)
+
+--- a/client
 b/client
+@@ -165,16 +165,16 @@ sub request_json_decode($;$$) {
+ #
+ # JSON-encode the hash reference $h and send it to the ACME server $uri
+ # encapsulated it in a JSON Web Signature (JWS).
+-# https://tools.ietf.org/html/draft-ietf-acme-acme-12
++# https://tools.ietf.org/html/rfc8555
+ #
+-sub acme($@) {
+-my $uri = shift;
++sub acme($;$) {
++my ($uri, $h) = @_;
+ die "Missing nonce\n" unless defined $NONCE;
+ 
+ # Produce the JSON Web Signature: RFC 7515 section 5
+ my %header = ( alg => 'RS256', nonce => $NONCE, url => $uri );
+ defined $KID ? ($header{kid} = $KID) : ($header{jwk} = $JWK);
+-my $payload = encode_base64url(json()->encode({ @_ }));
++my $payload = defined $h ? encode_base64url(json()->encode($h)) : "";
+ my $protected = encode_base64url(json()->encode(\%header));
+ my $data = $protected .'.'. $payload;
+ $S->printflush($data, "\r\n");
+@@ -204,7 +204,7 @@ sub acme_resource($%) {
+ request(HEAD => $RES{newNonce});
+ }
+ my $uri = $RES{$r} // die "Unknown resource '$r'\n";
+-acme($uri, @_);
++acme($uri, {@_});
+ }
+ 
+ # Set the key ID (registration URI)
+@@ -237,7 +237,7 @@ if ($COMMAND eq 'account') {
+ 
+ if ($r->is_success()) {
+ $KID = $r->header('Location');
+-$r = acme($KID, %h);
++$r = acme($KID, \%h);
+ request_json_decode($r, 1, \*STDOUT)
+ if $r->is_success() and $r->content_type() eq 'application/json';
+ }
+@@ -264,7 +264,7 @@ elsif ($COMMAND eq 'newOrder') {
+ my $order = request_json_decode($r);
+ 
+ foreach (@{$order->{authorizations}}) {
+-my $authz = request_json_decode(request(GET => $_));
++my $authz = 

Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events

[Chris Lamb]

Chris Lamb wrote:

> I've been working on an updated patch that detects new devices and
> blocks them too. However, "grabbing" devices during the processing of
> these "device hierarchy changed" events appears to do something funny
> and actually disables all input entirely for me

Whilst I've fixed that bit at least, the new attached patch doesn't
grab devices that are renabled via "xinput enable" although we do
successfully detect that "edge" event now.

That is to say:

  $ [find id via xinput list]
  $ (xinput disable 10; sleep 10; xinput enable 10) &
  $ ./xtrlock

... does not then block multitouch events subsequent to the sleep and
"xinput enable" call.

Antoine, how did you find the right /sys/bus/usb/devices/FOO directory?
I'm only using xinput as I can't seem to locate my touchpad under
/sys/bus. (Perhaps we don't need to care about the "xinput enable" case)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-From a4bc14b34ce924a370eabcc27c495474372497d1 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Wed, 21 Aug 2019 15:26:33 -0700
Subject: [PATCH] Attempt to grab multitouch devices which are not intercepted
 via XGrabPointer. (Closes: #830726)

xtrlock did not block multitouch events so an attacker could still input
(and thus control) various programs such as Chromium, etc. via so-called
multitouch events such as pan scrolling, "pinch and zoom" or even being
able to provide regular mouse clicks by depressing the touchpad once and
then clicking with a secondary finger.

Thanks to Antoine Amarilli  for the report.

Signed-off-by: Chris Lamb 
---
 debian/control |  1 +
 debian/rules   |  4 +--
 xtrlock.c  | 69 ++
 3 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 33582b1..19f88dd 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Priority: optional
 Build-Depends:
  debhelper-compat (= 12),
  libx11-dev,
+ libxi-dev,
  x11proto-core-dev,
 Vcs-Git: https://salsa.debian.org/debian/xtrlock.git
 Vcs-Browser: https://salsa.debian.org/debian/xtrlock
diff --git a/debian/rules b/debian/rules
index 2928068..43ebe33 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 include /usr/share/dpkg/default.mk
 -include /usr/share/dpkg/buildtools.mk
 
-CFLAGS += -DSHADOW_PWD
+CFLAGS += -DSHADOW_PWD -DMULTITOUCH
 
 ifeq (,$(findstring ^$(DEB_VERSION_UPSTREAM),^$(shell cut -d'"' -f2 patchlevel.h)))
 $(error (patchlevel.h out of sync with Debian version))
@@ -15,7 +15,7 @@ endif
 	dh $@
 
 override_dh_auto_build:
-	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt -lX11
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) xtrlock.c -o xtrlock -lcrypt -lX11 -lXi
 
 override_dh_fixperms:
 	dh_fixperms -X/usr/bin/xtrlock
diff --git a/xtrlock.c b/xtrlock.c
index 6117c6f..89d3a12 100644
--- a/xtrlock.c
+++ b/xtrlock.c
@@ -41,6 +41,11 @@
 #include 
 #endif
 
+#ifdef MULTITOUCH
+#include 
+#include 
+#endif
+
 #include "lock.bitmap"
 #include "mask.bitmap"
 #include "patchlevel.h"
@@ -71,6 +76,32 @@ int passwordok(const char *s) {
 #endif
 }
 
+#if MULTITOUCH
+XIEventMask evmask;
+
+/* (Optimistically) attempt to grab multitouch devices which are not
+ * intercepted via XGrabPointer. */
+void handle_multitouch(Cursor cursor) {
+  XIDeviceInfo *info;
+  int xi_ndevices;
+
+  info = XIQueryDevice(display, XIAllDevices, _ndevices);
+
+  for (int i=0; i < xi_ndevices; i++) {
+XIDeviceInfo *dev = [i];
+
+for (int j=0; j < dev->num_classes; j++) {
+  if (dev->classes[j]->type == XITouchClass &&
+  dev->use == XISlavePointer) {
+XIGrabDevice(display, dev->deviceid, window, CurrentTime, cursor,
+ GrabModeAsync, GrabModeAsync, False, );
+  }
+}
+  }
+  XIFreeDeviceInfo(info);
+}
+#endif
+
 int main(int argc, char **argv){
   XEvent ev;
   KeySym ks;
@@ -132,7 +163,32 @@ int main(int argc, char **argv){
 	program_version);
 exit(1);
   }
+
+#ifdef MULTITOUCH
+  unsigned char mask[XIMaskLen(XI_LASTEVENT)];
+  int xi_major, xi_minor, xi_opcode, xi_error, xi_event;
+
+  if (!XQueryExtension(display, INAME, _opcode, _event, _error)) {
+fprintf(stderr, "xtrlock (version %s): No X Input extension\n",
+program_version);
+exit(1);
+  }
   
+  if (XIQueryVersion(display, _major, _minor) != Success ||
+  xi_major * 10 + xi_minor < 22) {
+fprintf(stderr,"xtrlock (version %s): Need XI 2.2\n",
+program_version);
+exit(1);
+  }
+
+  evmask.mask = mask;
+  evmask.mask_len = sizeof(mask);
+  memset(mask, 0, sizeof(mask));
+  evmask.deviceid = XIAllDevices;
+  XISetMask(mask, XI_HierarchyChanged);
+  XISelectEvents(display, DefaultRootWindow(display), , 1);
+#endif
+
   attrib.override_redirect= True;
 
   if (blank) {
@@ -216,6 +272,10 @@ int main(int argc, char **argv){
 exit(1);
   }
 

Bug#380332: Also interested in this one

[T. Joseph Carter]

Upgrading my stretch box to buster, I got a lot of these familiar prompts,
and one very strange one from samba-common that used whiptail (debconf?)
and didn't even use a unified or context diff or set DPKG_CONFFILE_OLD/NEW.
(I should probably investigate what it's doing and file a bug about
that—NOT expected behavior!)

But samba's behavior got me thinking that it ought to be possible to change
the diff options or the pager or both. Seems that the pager is
configurable, so colordiff can be inserted there. But if you have a
preference for a different kind of diff, that's still not an option. Seems
I'd kinda like the option to throw the old and new conffile at vimdiff so
that I could quickly make whatever changes I wanted to, since that's what I
usually do anyway. But it seems the diff-side of things is all hard-coded
for the time being.

Essentially, "subscribe", along with the added thought that someone might
want to be able to use a diff-merge tool there rather than just a diff tool.

Joseph

Bug#935261: buster-pu: package fuse-emulator/1.5.7+dfsg1-2~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2019-08-21 at 11:28 +0300, Alberto Garcia wrote:
> the GTK build of the Fuse ZX Spectrum Emulator has had problems
> with Wayland for a long time (bug #872994; in short: the display is
> corrupted). This is a known upstream bug in Fuse, and while some
> progress has been made it hasn't been fixed yet.
> 
> After the buster release we are getting more reports from people who
> are running Wayland and can't use the emulator properly because of
> this. We fixed this in testing but we would like to do it in buster
> as
> well.
> 

Please go ahead.

Regards,

Adam

Bug#934956: cryptsetup 2.1.0-5+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 934956 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: cryptsetup
Version: 2.1.0-5+deb10u1

Explanation: fix support for LUKS2 headers without any bound keyslot

Bug#935369: stretch-pu: package libclamunrar/0.101.2-0+deb9u1

[Sebastian Andrzej Siewior]

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

Please find attached the proposed update to libclamunrar for Stretch as
part of the clamav transition, #924278.

Sebastian
diff -Nru libclamunrar-0.101.1/clamav-config.h.in 
libclamunrar-0.101.2/clamav-config.h.in
--- libclamunrar-0.101.1/clamav-config.h.in 2019-02-09 23:29:30.0 
+0100
+++ libclamunrar-0.101.2/clamav-config.h.in 2019-03-30 14:57:29.0 
+0100
@@ -314,6 +314,9 @@
 /* Define to 1 if you have the `strnlen' function. */
 #undef HAVE_STRNLEN
 
+/* Define to 1 if you have the `strnstr' function. */
+#undef HAVE_STRNSTR
+
 /* Define to 1 if sysconf(_SC_PAGESIZE) is available */
 #undef HAVE_SYSCONF_SC_PAGESIZE
 
diff -Nru libclamunrar-0.101.1/configure libclamunrar-0.101.2/configure
--- libclamunrar-0.101.1/configure  2019-02-09 23:29:30.0 +0100
+++ libclamunrar-0.101.2/configure  2019-03-30 14:57:29.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for ClamAV 0.101.1.
+# Generated by GNU Autoconf 2.69 for ClamAV 0.101.2.
 #
 # Report bugs to .
 #
@@ -590,8 +590,8 @@
 # Identity of this package.
 PACKAGE_NAME='ClamAV'
 PACKAGE_TARNAME='clamav'
-PACKAGE_VERSION='0.101.1'
-PACKAGE_STRING='ClamAV 0.101.1'
+PACKAGE_VERSION='0.101.2'
+PACKAGE_STRING='ClamAV 0.101.2'
 PACKAGE_BUGREPORT='https://bugzilla.clamav.net/'
 PACKAGE_URL='https://www.clamav.net/'
 
@@ -753,6 +753,8 @@
 CHECK_CPPFLAGS
 CHECK_LIBS
 CHECK_CFLAGS
+ENABLE_FUZZ_FALSE
+ENABLE_FUZZ_TRUE
 BUILD_CONFIGURE_FLAGS
 VERSIONSCRIPT_FALSE
 VERSIONSCRIPT_TRUE
@@ -908,6 +910,7 @@
 enable_libtool_lock
 enable_gcc_vcheck
 enable_experimental
+enable_fuzz
 enable_mempool
 enable_check
 enable_rpath
@@ -1533,7 +1536,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures ClamAV 0.101.1 to adapt to many kinds of systems.
+\`configure' configures ClamAV 0.101.2 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1605,7 +1608,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of ClamAV 0.101.1:";;
+ short | recursive ) echo "Configuration of ClamAV 0.101.2:";;
esac
   cat <<\_ACEOF
 
@@ -1626,6 +1629,7 @@
   --disable-libtool-lock  avoid locking (might break parallel builds)
   --disable-gcc-vcheckdo not check for buggy gcc version
   --enable-experimental   enable experimental code
+  --enable-fuzz   enable building standalone fuzz targets [default=no]
   --disable-mempool   do not use memory pools
   --enable-check  enable check unit tests [default=auto]
   --disable-rpath do not hardcode runtime library paths
@@ -1819,7 +1823,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-ClamAV configure 0.101.1
+ClamAV configure 0.101.2
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2363,7 +2367,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by ClamAV $as_me 0.101.1, which was
+It was created by ClamAV $as_me 0.101.2, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4120,7 +4124,7 @@
 
 # Define the identity of the package.
  PACKAGE='clamav'
- VERSION='0.101.1'
+ VERSION='0.101.2'
 
 
 # Some tools Automake needs.
@@ -5849,10 +5853,10 @@
 
 
 
-VERSION="0.101.1"
+VERSION="0.101.2"
 
 LC_CURRENT=9
-LC_REVISION=1
+LC_REVISION=2
 LC_AGE=0
 LIBCLAMAV_VERSION="$LC_CURRENT":"$LC_REVISION":"$LC_AGE"
 
@@ -19150,6 +19154,27 @@
 BUILD_CONFIGURE_FLAGS=$build_configure_args
 
 
+# Check whether --enable-fuzz was given.
+if test "${enable_fuzz+set}" = set; then :
+  enableval=$enable_fuzz; enable_cov=$enableval
+else
+  enable_cov="no"
+fi
+
+
+if test "x$enable_fuzz" = "xyes"; then
+CXXFLAGS="-std=c++11 -stdlib=libc++ $CXXFLAGS"
+fi
+
+ if test "x$enable_fuzz" = "xyes"; then
+  ENABLE_FUZZ_TRUE=
+  ENABLE_FUZZ_FALSE='#'
+else
+  ENABLE_FUZZ_TRUE='#'
+  ENABLE_FUZZ_FALSE=
+fi
+
+
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether uname(2) is POSIX" 
>&5
 $as_echo_n "checking whether uname(2) is POSIX... " >&6; }
@@ -19357,6 +19382,17 @@
 fi
 done
 
+for ac_func in strnstr
+do :
+  ac_fn_c_check_func "$LINENO" "strnstr" "ac_cv_func_strnstr"
+if test "x$ac_cv_func_strnstr" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_STRNSTR 1
+_ACEOF
+
+fi
+done
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGEFILE_SOURCE value 
needed for large files" >&5
 $as_echo_n "checking for _LARGEFILE_SOURCE value needed for large files... " 
>&6; }
 if ${ac_cv_sys_largefile_source+:} false; then 

Bug#935368: stretch-pu: package c-icap-modules/0.4.4-1+deb9u1

[Sebastian Andrzej Siewior]

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

Please find attached the proposed update to c-icap-modules for Stretch as
part of the clamav transition, #924278.

Sebastian
diff -Nru c-icap-modules-0.4.4/debian/changelog 
c-icap-modules-0.4.4/debian/changelog
--- c-icap-modules-0.4.4/debian/changelog   2016-10-09 21:29:45.0 
+0200
+++ c-icap-modules-0.4.4/debian/changelog   2019-03-10 22:00:14.0 
+0100
@@ -1,3 +1,10 @@
+c-icap-modules (1:0.4.4-1+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for clamav 0.101.1 (Closes: #919814).
+
+ -- Sebastian Andrzej Siewior   Sun, 10 Mar 2019 
22:00:14 +0100
+
 c-icap-modules (1:0.4.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru c-icap-modules-0.4.4/debian/control 
c-icap-modules-0.4.4/debian/control
--- c-icap-modules-0.4.4/debian/control 2016-10-09 21:29:45.0 +0200
+++ c-icap-modules-0.4.4/debian/control 2019-03-10 22:00:14.0 +0100
@@ -2,7 +2,7 @@
 Section: net
 Priority: extra
 Maintainer: Mathieu Parent 
-Build-Depends: debhelper (>= 9~), autotools-dev, libicapapi-dev (>=1:0.4.1~), 
libclamav-dev, libltdl-dev | libltdl3-dev, libdb-dev, dh-autoreconf
+Build-Depends: debhelper (>= 9~), autotools-dev, libicapapi-dev (>=1:0.4.1~), 
libclamav-dev (>= 0.101.1), libltdl-dev | libltdl3-dev, libdb-dev, dh-autoreconf
 Standards-Version: 3.9.8
 Homepage: http://c-icap.sourceforge.net/
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/c-icap-modules.git
diff -Nru 
c-icap-modules-0.4.4/debian/patches/c-icap-modules-clamav-backport.patch 
c-icap-modules-0.4.4/debian/patches/c-icap-modules-clamav-backport.patch
--- c-icap-modules-0.4.4/debian/patches/c-icap-modules-clamav-backport.patch
1970-01-01 01:00:00.0 +0100
+++ c-icap-modules-0.4.4/debian/patches/c-icap-modules-clamav-backport.patch
2019-03-10 21:59:09.0 +0100
@@ -0,0 +1,131 @@
+From: Sebastian Andrzej Siewior 
+Date: Sat, 19 Jan 2019 21:12:25 +0100
+Subject: [PATCH] backport clamav changes from 0.5.3
+
+---
+ configure.ac | 12 
+ services/virus_scan/clamav_mod.c | 62 +++-
+ 2 files changed, 73 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 6d01fad8e47b..df5060941b7b 100644
+--- a/configure.ac
 b/configure.ac
+@@ -187,7 +187,19 @@ if test a"$clamav" = "ayes"; then
+ AC_DEFINE(HAVE_LIBCLAMAV_095,1,[Define HAVE_LIBCLAMAV_095 if have clamav 
0.95.x or newer])
+ AC_MSG_RESULT(yes),
+ )
++
++#
++# clamav dropped CL_SCAN_HEURISTIC_ENCRYPTED in 0.101 replacing it with
++# CL_SCAN_HEURISTIC_ENCRYPTED_ARCHIVE and CL_SCAN_HEURISTIC_ENCRYPTED_DOC
+ # restore flags  / clamav tests
++AC_MSG_CHECKING([for HAVE_CL_SCAN_OPTIONS in clamav.h])
++AC_TRY_COMPILE(
++[#include ],
++[struct cl_scan_options CLAMSCAN_OPTIONS = { 0, 0, 0, 0, 0 };],
++AC_DEFINE(HAVE_CL_SCAN_OPTIONS,1,[Define HAVE_CL_SCAN_OPTIONS if have 
clamav 0.101.x or newer])
++AC_MSG_RESULT(yes),
++AC_MSG_RESULT(no),
++)
+ CFLAGS=$OLD_CFLAGS
+ fi # if test a"$clamav" = "ayes";
+ 
+diff --git a/services/virus_scan/clamav_mod.c 
b/services/virus_scan/clamav_mod.c
+index e860a93d2e22..9a886f9e62b5 100644
+--- a/services/virus_scan/clamav_mod.c
 b/services/virus_scan/clamav_mod.c
+@@ -123,7 +123,12 @@ struct virus_db {
+ #ifndef HAVE_LIBCLAMAV_095
+ struct cl_limits limits;
+ #endif
++
++#ifdef HAVE_CL_SCAN_OPTIONS
++struct cl_scan_options CLAMSCAN_OPTIONS;
++#else
+ unsigned int CLAMSCAN_OPTIONS = CL_SCAN_STDOPT;
++#endif
+ 
+ struct virus_db *virusdb = NULL;
+ struct virus_db *old_virusdb = NULL;
+@@ -186,6 +191,55 @@ int clamav_post_init(struct ci_server_conf *server_conf)
+ #endif
+ 
+  /*Build scan options*/
++#ifdef HAVE_CL_SCAN_OPTIONS
++ memset(_OPTIONS, 1, sizeof(CLAMSCAN_OPTIONS));
++ CLAMSCAN_OPTIONS.parse = ~0;
++
++#if defined(CL_SCAN_HEURISTIC_ENCRYPTED_ARCHIVE)
++ if (CLAMAV_BLOCKENCRYPTED) {
++ CLAMSCAN_OPTIONS.general |= CL_SCAN_GENERAL_HEURISTICS;
++ CLAMSCAN_OPTIONS.heuristic |= CL_SCAN_HEURISTIC_ENCRYPTED_ARCHIVE;
++ CLAMSCAN_OPTIONS.heuristic |= CL_SCAN_HEURISTIC_ENCRYPTED_DOC;
++ }
++#endif
++
++#if defined(CL_SCAN_HEURISTIC_BROKEN)
++ if (CLAMAV_BLOCKBROKEN) {
++ CLAMSCAN_OPTIONS.general |= CL_SCAN_GENERAL_HEURISTICS;
++ CLAMSCAN_OPTIONS.heuristic |= CL_SCAN_HEURISTIC_BROKEN;
++ }
++#endif
++
++#if defined(CL_SCAN_GENERAL_HEURISTIC_PRECEDENCE)
++ if (CLAMAV_HEURISTIC_PRECEDENCE) {
++ CLAMSCAN_OPTIONS.general |= CL_SCAN_GENERAL_HEURISTICS;
++ CLAMSCAN_OPTIONS.heuristic |= CL_SCAN_GENERAL_HEURISTIC_PRECEDENCE;
++ }
++#endif
++
++#if defined(CL_SCAN_HEURISTIC_MACROS)
++ if (CLAMAV_BLOCKMACROS) {
++ CLAMSCAN_OPTIONS.general |= CL_SCAN_GENERAL_HEURISTICS;
++ CLAMSCAN_OPTIONS.heuristic |= 

Bug#935366: stretch-pu: package havp/0.92a-4+deb9u1

[Sebastian Andrzej Siewior]

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

Please find attached the proposed update to havp for Stretch as
part of the clamav transition, #924278.

Sebastian
diff -Nru havp-0.92a/debian/changelog havp-0.92a/debian/changelog
--- havp-0.92a/debian/changelog 2015-08-01 08:34:46.0 +0200
+++ havp-0.92a/debian/changelog 2019-03-10 17:30:34.0 +0100
@@ -1,3 +1,10 @@
+havp (0.92a-4+deb9u1) stretch; urgency=medium
+
+  * Add support for clamav 0.101 (Closes: #920865).
+  * Bump libclamav-dev build-depends to match
+
+ -- Sebastian Andrzej Siewior   Sun, 10 Mar 2019 
17:30:34 +0100
+
 havp (0.92a-4) unstable; urgency=medium
 
   [ Andreas Cadhalpun ]
diff -Nru havp-0.92a/debian/control havp-0.92a/debian/control
--- havp-0.92a/debian/control   2015-07-31 22:54:50.0 +0200
+++ havp-0.92a/debian/control   2019-03-10 17:30:34.0 +0100
@@ -7,7 +7,7 @@
Andreas Cadhalpun ,
Rene Mayrhofer 
 Homepage: http://www.server-side.de/
-Build-Depends: debhelper (>= 9), autotools-dev, dh-autoreconf, libssl-dev, 
libclamav-dev, docbook-to-man, po-debconf
+Build-Depends: debhelper (>= 9), autotools-dev, dh-autoreconf, libssl-dev, 
libclamav-dev (>= 0.101.1), docbook-to-man, po-debconf
 Vcs-Git: git://anonscm.debian.org/pkg-clamav/havp.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-clamav/havp.git
 Standards-Version: 3.9.6
diff -Nru havp-0.92a/debian/.git-dpm havp-0.92a/debian/.git-dpm
--- havp-0.92a/debian/.git-dpm  2015-07-31 22:54:50.0 +0200
+++ havp-0.92a/debian/.git-dpm  2019-03-10 17:30:01.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-9fb907bcffedcc78e1ac357dfaffed7211131e34
-9fb907bcffedcc78e1ac357dfaffed7211131e34
+a9be56684d967d6af910ad00d31061d363d63d2e
+a9be56684d967d6af910ad00d31061d363d63d2e
 6fdc197f9802b586cf612b30fa6eb1a89d3ff9c8
 6fdc197f9802b586cf612b30fa6eb1a89d3ff9c8
 havp_0.92a.orig.tar.gz
diff -Nru havp-0.92a/debian/patches/0009-Enable-LFS-fix-autoreconf.patch 
havp-0.92a/debian/patches/0009-Enable-LFS-fix-autoreconf.patch
--- havp-0.92a/debian/patches/0009-Enable-LFS-fix-autoreconf.patch  
2015-07-31 22:54:50.0 +0200
+++ havp-0.92a/debian/patches/0009-Enable-LFS-fix-autoreconf.patch  
2019-03-10 17:30:01.0 +0100
@@ -15,9 +15,9 @@
 
 Signed-off-by: Sebastian Andrzej Siewior 
 ---
- configure.in  |  28 ++---
- havp/default.h| 108 
- havp/default.h.in | 121 --
+ configure.in  |  28 +--
+ havp/default.h| 108 +
+ havp/default.h.in | 121 --
  3 files changed, 122 insertions(+), 135 deletions(-)
  create mode 100644 havp/default.h
  delete mode 100644 havp/default.h.in
diff -Nru havp-0.92a/debian/patches/0010-havp-Update-to-clamav-0.101.patch 
havp-0.92a/debian/patches/0010-havp-Update-to-clamav-0.101.patch
--- havp-0.92a/debian/patches/0010-havp-Update-to-clamav-0.101.patch
1970-01-01 01:00:00.0 +0100
+++ havp-0.92a/debian/patches/0010-havp-Update-to-clamav-0.101.patch
2019-03-10 17:30:01.0 +0100
@@ -0,0 +1,83 @@
+From a9be56684d967d6af910ad00d31061d363d63d2e Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior 
+Date: Tue, 29 Jan 2019 23:21:02 +0100
+Subject: havp: Update to clamav 0.101
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The API changed slightly: The cl_scanfile() expects now a struct which
+options set. CL_SCAN_GENERAL_ALLMATCHES enables all-match mode.
+The ~0 for parse enables all possible parses like PE/PDF/…
+The heuristic part (which needs to be enabled) matches to the old
+behaviour which blocked encrypted archives or doc files.
+
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ havp/scanners/clamlibscanner.cpp | 22 +-
+ havp/scanners/clamlibscanner.h   |  2 +-
+ 2 files changed, 18 insertions(+), 6 deletions(-)
+
+diff --git a/havp/scanners/clamlibscanner.cpp 
b/havp/scanners/clamlibscanner.cpp
+index f851552..0abd5b0 100644
+--- a/havp/scanners/clamlibscanner.cpp
 b/havp/scanners/clamlibscanner.cpp
+@@ -204,7 +204,7 @@ int ClamLibScanner::ReloadDatabase()
+ string ClamLibScanner::Scan( const char *FileName )
+ {
+ #ifdef CL_INIT_DEFAULT
+-int ret = cl_scanfile(FileName, , NULL, engine, scanopts);
++int ret = cl_scanfile(FileName, , NULL, engine, _options);
+ #else
+ int ret = cl_scanfile(FileName, , NULL, engine, , 
scanopts);
+ #endif
+@@ -280,20 +280,32 @@ ClamLibScanner::ClamLibScanner()
+ }
+ 
+ //Set scanning options
+-scanopts = CL_SCAN_STDOPT;
++memset(_options, 0, sizeof(struct cl_scan_options));
++
++cl_options.general = CL_SCAN_GENERAL_ALLMATCHES;
++cl_options.parse = ~0;
++
++/* scanopts = CL_SCAN_STDOPT; */
+ 
+ if ( 

Bug#935367: stretch-pu: package python-clamav/0.4.1-8+deb9u1

[Sebastian Andrzej Siewior]

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

Please find attached the proposed update to python-clamav for Stretch as
part of the clamav transition, #924278.

Sebastian
diff -Nru python-clamav-0.4.1/debian/changelog 
python-clamav-0.4.1/debian/changelog
--- python-clamav-0.4.1/debian/changelog2016-02-06 01:27:01.0 
+0100
+++ python-clamav-0.4.1/debian/changelog2019-03-10 20:49:14.0 
+0100
@@ -1,3 +1,12 @@
+python-clamav (0.4.1-8+deb9u1) stretch; urgency=medium
+
+  [ Scott Kitterman ]
+  * Add d/p/python-clamav-add-support-for-clamav-0.101.0.patch to that
+python-clamav builds/works with clamav 101.1 and newer (Closes: #920959)
+  * Bump libclamav-dev build-depends to match
+
+ -- Sebastian Andrzej Siewior   Sun, 10 Mar 2019 
20:49:14 +0100
+
 python-clamav (0.4.1-8) unstable; urgency=medium
 
   [ Jakub Wilk ]
diff -Nru python-clamav-0.4.1/debian/control python-clamav-0.4.1/debian/control
--- python-clamav-0.4.1/debian/control  2016-02-05 08:03:06.0 +0100
+++ python-clamav-0.4.1/debian/control  2019-03-10 20:49:14.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Python Modules Team 

 Uploaders: Scott Kitterman 
-Build-Depends: debhelper (>= 9), libclamav-dev (>= 0.95), python-all-dev (>= 
2.6.5-2~), dh-python
+Build-Depends: debhelper (>= 9), libclamav-dev (>= 0.101.1), python-all-dev 
(>= 2.6.5-2~), dh-python
 X-Python-Version: >= 2.3
 Standards-Version: 3.9.7
 Homepage: http://xael.org/pages/projects.html
diff -Nru 
python-clamav-0.4.1/debian/patches/python-clamav-add-support-for-clamav-0.101.0.patch
 
python-clamav-0.4.1/debian/patches/python-clamav-add-support-for-clamav-0.101.0.patch
--- 
python-clamav-0.4.1/debian/patches/python-clamav-add-support-for-clamav-0.101.0.patch
   1970-01-01 01:00:00.0 +0100
+++ 
python-clamav-0.4.1/debian/patches/python-clamav-add-support-for-clamav-0.101.0.patch
   2019-03-10 20:49:14.0 +0100
@@ -0,0 +1,40 @@
+From: Sebastian Andrzej Siewior 
+Date: Wed, 30 Jan 2019 23:22:55 +0100
+Subject: [PATCH] python-clamav: add support for clamav 0.101.0
+
+CL_SCAN_GENERAL_ALLMATCHES with all parses should do what CL_SCAN_STDOPT
+did.
+
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ pyclamav.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/pyclamav.c b/pyclamav.c
+index 7ccd57239b97..0315c62ea81a 100644
+--- a/pyclamav.c
 b/pyclamav.c
+@@ -191,6 +191,7 @@ static PyObject *pyclamav_scanfile(PyObject *self, 
PyObject *args)
+   char *file_to_scan;
+   unsigned long int size = 0;
+   const char *virname;
++  struct cl_scan_options scan_options;
+   int ret = 0;
+ 
+   /* Raise exception if database error */
+@@ -209,8 +210,11 @@ static PyObject *pyclamav_scanfile(PyObject *self, 
PyObject *args)
+ PyErr_SetString(PyExc_ValueError,  "Argument is not a filename");
+ return NULL; 
+   }
++  memset(_options, 0, sizeof(scan_options));
++  scan_options.general = CL_SCAN_GENERAL_ALLMATCHES;
++  scan_options.parse = ~0;
+ 
+-  ret = cl_scanfile(file_to_scan, , , engine, CL_SCAN_STDOPT);
++  ret = cl_scanfile(file_to_scan, , , engine, _options);
+ 
+   /* Test return code */
+   switch (ret) {
+-- 
+2.11.0
+
diff -Nru python-clamav-0.4.1/debian/patches/series 
python-clamav-0.4.1/debian/patches/series
--- python-clamav-0.4.1/debian/patches/series   2016-02-05 07:39:16.0 
+0100
+++ python-clamav-0.4.1/debian/patches/series   2019-03-10 20:49:14.0 
+0100
@@ -1 +1,2 @@
 clamav-095-compat.patch
+python-clamav-add-support-for-clamav-0.101.0.patch

Bug#932597: It's not just Konqueror

[John Scott]

cURL doesn't seem to like it either.
 $ curl "https://kb.iu.edu; -v
...
 * successfully set certificate verify locations:
 *   CAfile: none
   CApath: /etc/ssl/certs
 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
 * TLSv1.3 (IN), TLS alert, handshake failure (552):
 * error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
 * Closing connection 0
 curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake 
failure

wget is happy though, and so is Firefox, so I'm not sure how Konqueror and
cURL might be related nor how to poke at this more.

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

Bug#935365: buildd.debian.org: allowing self-service givebacks for Failed packages?

[Samuel Thibault]

Package: buildd.debian.org
Severity: normal

Hello,

The self-service giveback is currently not available for packages in the
Failed state. I wonder if such a restriction is really useful.

The thing is: apparently only I do this, but I always set hurd-i386
package build failures in the Failed state with the appropriate failure
log lines, which are very helpful for sorting out the porting work
(see https://people.debian.org/~sthibault/graph-top.txt), and packages
maintainers have already told me they appreciate this, because I know
well the hurd-i386 failures and can thus easily point out the actual
problems to maintainers.

But if people can not giveback due to this even in cases where it's a
transient failure or lagging dependency version, I'am afraid they will
now not send a mail for giving back on hurd-i386, thinking that I have
set the Failed state for a stronger reason than I actually meant.


Put another way, this restriction on the Failed state leads me to think
I should rather stop setting packages in the Failed state, but then it's
detrimental to the porting work triaging.


Actually, even when the Fail state has been set manually on archs (e.g.
a know bug affecting all archs), it would still make sense to allow
maintainers to trigger the giveback when the bug is known to be fixed by
another package upload.

Samuel

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

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

Bug#935364: debhelper: dh_clean doesn't print info about files listed in debian/clean being removed, even with DH_VERBOSE

[Clément Hermann]

Package: debhelper
Version: 12.5.3
Severity: normal

Hi,

while working on a package, I had trouble finding out why some file were
disapearing without any reason and no entry in build log, despite using
DH_VERBOSE.

Looking at the code, it's because
glob_expand_error_handler_silently_ignores is used, I guess to avoid
warning about not being able to remove non-existing files.

It would be nice if dh_clean would print something about files being
removed, at least when DH_VERBOSE=1. IMO, warnings about
non-existing files are OK if DH_VERBOSE is used.

What do you think? I didn't really look at a possible patch yet, I
wanted to discuss it first.

Cheers,

-- 
nodens

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.5.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-1
ii  file 1:5.37-5
ii  libdpkg-perl 1.19.7
ii  man-db   2.8.6.1-1
ii  perl 5.28.1-6
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201901

-- no debconf information

Bug#934928: win32-loader 0.9.4+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 934928 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: win32-loader
Version: 0.9.4+deb10u1

Explanation: rebuild against current packages, particularly 
debian-archive-keyring

Bug#931350: fence-agents 4.0.25-1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 931350 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fence-agents
Version: 4.0.25-1+deb9u1

Explanation: security fix [CVE-2019-10153]

Bug#935165: newsboat 2.13-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935165 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: newsboat
Version: 2.13-1+deb10u1

Explanation: fix use after free issue

Bug#932111: webkit2gtk 2.24.3-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 932111 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: webkit2gtk
Version: 2.24.3-1~deb10u1

Explanation: new upstream stable version; includes several security fixes 
[CVE-2019-8571 CVE-2019-8583 CVE-2019-8586 CVE-2019-8594 CVE-2019-8609 
CVE-2019-8611 CVE-2019-8622 CVE-2019-8623 CVE-2019-6237 CVE-2019-8584 
CVE-2019-8587 CVE-2019-8596 CVE-2019-8597 CVE-2019-8601 CVE-2019-8608 
CVE-2019-8610 CVE-2019-8619 CVE-2019-8595 CVE-2019-8607 CVE-2019-8615]; stop 
requiring SSE2-capable CPUs

Bug#931358: musescore 2.3.2+dfsg2-7~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 931358 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: musescore
Version: 2.3.2+dfsg2-7~deb10u1

Explanation: disable webkit functionality

Bug#933176: fig2dev 3.2.6a-2+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 933176 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fig2dev
Version: 3.2.6a-2+deb9u2

Explanation: do not segfault on circle/half circle arrowheads with a 
magnification larger than 42 [CVE-2019-14275]

Bug#931968: libtk-img 1.4.6+dfsg-1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 931968 = stretch pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libtk-img
Version: 1.4.6+dfsg-1+deb9u1

Explanation: stop using internal copies of Jpeg, Zlib and PixarLog codecs, 
fixing crashes 

Bug#931967: libtk-img 1.4.8+dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 931967 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libtk-img
Version: 1.4.8+dfsg-1+deb10u1

Explanation: stop using internal copies of Jpeg, Zlib and PixarLog codecs, 
fixing crashes

Bug#928133: reprepro: using endhook kills piping from stdout of reprepro list output

[Uwe Kleine-König]

Control: found -1 5.1.1-1
Control: tag -1 + patch

Hello,

On Sun, Apr 28, 2019 at 09:08:36PM +0200, andre wrote:
> 
> The use of an endhook kills the piping of reprepro list ouput. I tested this 
> with Ubuntu 19.04 with following test:
> 
> mkdir -p conf
> 
> cat >conf/distributions < Codename: test
> Components: main
> Architectures: amd64
> DISTRIBUTIONS
> 
> reprepro createsymlinks
> 
> apt download hello
> 
> reprepro includedeb test hello*.deb
> 
> # The following command works like expected: The hello package and its 
> version is shown on the terminal
> reprepro list test | tee /dev/null
> 
> # This works not as expected: Nothing is shown on the terminal
> reprepro --endhook /bin/true list test | tee /dev/null

I noticed the same problem. My repository is a big bigger though and I
get some output, this is incomplete though. Using strace the difference
seems to be

- without a pipe:

fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0

  and then one write to fd 1 for each package.

- with a pipe:  

fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0

  and then only writes to fd 1 of size 4096.

So it seems that if there are n chars to be printed, only n & ~4095 make
it to stdout.

The problem already exists in stretch, so adding a found for this
version.

The following patch fixes the problem for me:

diff --git a/main.c b/main.c
index ef8988829aaf..5d413d813027 100644
--- a/main.c
+++ b/main.c
@@ -5186,6 +5186,7 @@ int main(int argc, char *argv[]) {
 "There have been errors!\n",
stderr);
}
+   fflush(stdout);
if (endhook != NULL) {
assert (optind > 0);
/* only returns upon error: */


This suggests that execv() (that is called when an endhook is
configured) results in the buffered output to be discarded.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#935328: libguestfs-tools: virt-sparsify doesn't work if libelogind0 is installed on the host (workaround found)

[Daniel Reichelt]

The attached patch works around the issue for sysvinit/elogind users.

A proper solution however would auto-apply the appropriate version of
the packages file (or supermin.d directory), depending on the state of
the host system.

Cheers
Daniel
--- /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages.orig	2019-08-21 23:05:49.623663071 +0200
+++ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages	2019-08-21 23:05:56.343771343 +0200
@@ -35,7 +35,7 @@
 libhivex0
 libjansson4
 libpcre3
-libsystemd0
+libelogind0
 libxml2
 libyara3
 lsscsi


signature.asc
Description: OpenPGP digital signature

Bug#935363: readline: please make the build reproducible

[Chris Lamb]

Source: readline
Version: 8.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that readline could not be built reproducibly as 
/usr/share/doc/libreadline8/examples/Makefile.gz embeds the build
path via embedding -ffile-prefix-map in CFLAGS.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-08-21 14:28:38.958184442 -0700
--- b/debian/rules  2019-08-21 14:35:48.602731884 -0700
@@ -367,6 +367,8 @@
  -e '/^VPATH =/s,=.*,= .:/usr/share/doc/$(p_rl)/examples,' \
  -e '/^top_srcdir =/s,=.*,= /usr/include/readline,' \
  -e '/^BUILD_DIR =/s,=.*,= /usr/src/readline6/build,' \
+ -e 's/-ffile-prefix-map=[^ ]*[ ]*//g' \
+ -e 's/-fdebug-prefix-map=[^ ]*[ ]*//g' \
  $(d_doc)/usr/share/doc/$(p_rl)/examples/Makefile
dh_link -p$(p_doc) \
  /usr/share/doc/$(p_rl)/examples /usr/share/doc/$(p_doc)/examples

Bug#935362: gdbm: please make the build (slightly more..) reproducible

[Chris Lamb]

Source: gdbm
Version: 1.18.1-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that gdbm could not be built reproducibly.

Patch attached that removes an obvious build timestamp from the
generated binaries.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2019-08-21 14:29:56.638894870 
-0700
@@ -0,0 +1,16 @@
+Description: Make the build more reproducible
+Author: Chris Lamb 
+Last-Update: 2019-08-21
+
+--- gdbm-1.18.1.orig/src/version.c
 gdbm-1.18.1/src/version.c
+@@ -25,9 +25,6 @@
+making the distdir. */
+ const char * gdbm_version = "GDBM version " PACKAGE_VERSION ". "
+ "27/10/2018"
+-#if defined(__STDC__) && defined(__DATE__) && defined(__TIME__)
+-  " (built " __DATE__ " " __TIME__ ")"
+-#endif
+ ;
+ int const gdbm_version_number[3] = {
+   GDBM_VERSION_MAJOR,
--- a/debian/patches/series 2019-08-21 14:21:50.974478734 -0700
--- b/debian/patches/series 2019-08-21 14:29:49.614830587 -0700
@@ -1 +1,2 @@
 patch-fix-spelling-error-in-gdbm.3.patch
+reproducible-build.patch

Bug#935361: node-autoprefixer: please make the build reproducible

[Chris Lamb]

Source: node-autoprefixer
Version: 8.6.5-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that node-autoprefixer could not be built reproducibly as the
'data' directory that was ended up in the final package varied
on the timestamp of the build:

│ │ │ │ -drwxr-xr-x   0 root (0) root (0)0 2018-07-06 
05:25:11.00 ./usr/lib/nodejs/autoprefixer/data/
│ │ │ │ +drwxr-xr-x   0 root (0) root (0)0 2019-02-07 
12:03:19.00 ./usr/lib/nodejs/autoprefixer/data/

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-08-21 14:18:25.684639715 -0700
--- b/debian/rules  2019-08-21 14:32:41.024401555 -0700
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+include /usr/share/dpkg/default.mk
+
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 export NODE_PATH=debian/node_modules
@@ -15,6 +17,8 @@
 override_dh_install:
dh_components --no-purge
dh_components --build_stage install
+   find build -newermt @$(SOURCE_DATE_EPOCH) -print0 | \
+   xargs -0r touch --no-dereference --date=@$(SOURCE_DATE_EPOCH)
dh_install
 
 #override_dh_auto_test:

Bug#935360: ITP: sampler -- Tool for shell comamands execution, visualization and alerting

[Josue Ortega]

Package: wnpp
Severity: wishlist
Owner: Josue Ortega 

* Package name: sampler
  Version : 1.0.3
  Upstream Author : Alexander Lukyanchikov 
* URL : sq...@sqshq.com
* License : GPL-3
  Programming Lang: Go Lang
  Description : Sampler is a tool for shell commands execution, 
visualization 
  and alerting. Configured with a simple YAML file.
  One can sample any dynamic process right from the terminal - observe changes 
in the database,
  monitor MQ in-flight messages, trigger a deployment script and get 
notification when it's done.
  If there is a way to get a metric using shell command - then it can be 
visualized with Sampler momentarily.

signature.asc
Description: PGP signature

Bug#935137: acme-tiny 4.0.4-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935137 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: acme-tiny
Version: 4.0.4-1+deb10u1

Explanation: handle upcoming ACME protocol change

Bug#933952: qtbase5-examples: many qtbase5-examples fail to compile - w/solution

[Dmitry Shachnev]

Control: reopen -1

Hi Mike, and sorry for the delay.

Your mail was very long so I am replying to some points but not to
all of them (otherwise I would never finish the reply).

On Wed, Aug 07, 2019 at 01:51:01PM -0700, Mike Bird wrote:
> The Qt examples are not like glxgears.  They are fundamentally
> different.  They are not to demonstrate how pretty Qt looks or how
> fast it runs.

Well, I personally used the examples to test whether some of Qt
components work correctly.

E.g. I was working on bugs in upstream dbustray code, and I used the
systray example to check how it works on Plasma, GNOME, etc. I did not
compile it, just ran it.

But I understand your point.

> The orig.tar.xz do not include the precompiled binaries.  Of course
> debuild can build the binaries with all the necessary dependencies
> installed, but it was Debian's decision to ship precompiled binaries
> in the Debian examples packages.  That was not Qt's decision.

It is upstream build system that installs built binaries alongside their
source code. So I would say it is Qt’s decision.

> But just as an aside let's pretend for a moment that Lisandro is
> correct.  Let's try running one of the precompiled binaries.  Go
> ahead on a clean system and install qtwebview5-examples which is
> the package I just finished testing.  Then:
>
> $ /usr/lib/x86_64-linux-gnu/qt5/examples/webview/minibrowser/minibrowser
> QQmlApplicationEngine failed to load component
> qrc:/main.qml:53 module "QtWebView" is not installed

Fixed!
https://salsa.debian.org/qt-kde-team/qt/qtwebview/commit/05b80161ab70e975

While we probably won’t add the dependencies for building the examples,
if some runtime dependency is missing we will add it. Please report such
issues.

> > So we should not add these 
> > dependencies, at most we can add some of these packages to Suggests.
>
> The necessary packages are not essential so they must be dependencies.
> That is the way Debian works.  These packages are fundamentally broken
> without qt5-default and c++-compiler and make and an eclectic mix of
> auxiliary packages.

In my opinion one can do many different ways with the examples:

a) Run them to see how certain code works in practice;
b) Read their source code (maybe copy some bits to one’s own app);
c) Compile them.

a) does not need a compiler. b) does not always need a compiler
(e.g. as a PyQt developer I may copy code from Qt examples but translate it
from C++ to Python).

As these are valid use cases, the compiler should not be a required
dependency.

> Programmers should be able to install the examples packages and have
> them compile without hunting for missing dependencies.  That's the
> whole point of using a distro.  Nobody is going to install the examples
> unless they want to compile them.

As pointed above, there are valid use cases for installing the examples
but not compiling them.

> They is no joy in staring at an example widget that does nothing unless
> you actually intend to build upon it in your own programming.  Or go
> ahead and run
> /usr/lib/x86_64-linux-gnu/qt5/examples/corelib/threads/waitconditions/waitconditions
> and tell me what you learned from merely running it.

Looks like DNA :) But not all examples are like that one.

> > On Mon, Aug 05, 2019 at 06:53:52AM -0700, Mike Bird wrote:
> > > A directory of files and several dependencies are missing from
> > > qtbase5-examples.  Here is how to fix it.
> > >
> > > (1) In the source package, file "examples/vulkan/vulkan.pro", at the
> > > end add a blank line and then a line containing only
> > > "EXAMPLE_FILES = shared" (without the quotes).  The resut will
> > > end up looking like the tail of file "cat
> > > examples/network/network.pro".
> >
> > This sounds like an upstream issue. Please file a bug on bugreports.qt.io
> > or directly submit the patch to codereview.qt-project.org, explaining why
> > this change is needed
>
> With all the various "rm -rf" in debian/rules I would not feel comfortable
> filing bugs upstream against Debian Qt packages.

Outside of clean target, we remove .la files, some .cmake files for plugins
(because they cause issues) and the bootstrap library. I don’t see how this
affects examples.

> >  (you did not explain your problem here).
>
> Without the "shared" directory, a lot of the examples cannot compile.

Well, that means upstream doesn’t care about it either.

We already have many distro patches and I don’t want to carry another one,
so if you think these is a bug upstream please report it to them.

> > As Lisandro explained, nothing should really depend on qt5-default.
> >
> > In fact, Lintian even has a warning for this:
> > https://wiki.debian.org/Lintian/Tags/depends-on-metapackage
>
> The lintian warning has two aspects.  Debian internally should be exporting
> QT_SELECT=qt5 in debian/rules.  That is correct and Debian does.
>
> But the lintian warning also assumes that qt5-default is a metapackage
> which if depended upon restricts users 

Bug#935200: asterisk 16.2.1~dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 935200 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: asterisk
Version: 16.2.1~dfsg-1+deb10u1

Explanation: fix buffer overflow in res_pjsip_messaging [AST-2019-002 / 
CVE-2019-12827]; fix remote Crash Vulnerability in chan_sip [AST-2019-003 / 
CVE-2019-13161]

Bug#933769: erlang-p1-pkix 1.0.0-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 933769 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: erlang-p1-pkix
Version: 1.0.0-3+deb10u1

Explanation: fix handling of GnuTLS certificates

Bug#933369: dma 0.11-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 933369 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dma
Version: 0.11-1+deb10u1

Explanation: don't limit TLS connections to TLS1.0

Bug#933175: fig2dev 3.2.7a-5+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 933175 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fig2dev
Version: 3.2.7a-5+deb10u1

Explanation: do not segfault on circle/half circle arrowheads with a 
magnification larger than 42 [CVE-2019-14275]

Bug#933147: libsdl2-image 2.0.4+dfsg1-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 933147 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libsdl2-image
Version: 2.0.4+dfsg1-1+deb10u1

Explanation: fix buffer overflows [CVE-2019-5058 CVE-2019-5052 CVE-2019-7635]; 
fix out of bounds access in PCX handling [CVE-2019-12216 CVE-2019-12217 
CVE-2019-12218 CVE-2019-12219 CVE-2019-12220 CVE-2019-12221 CVE-2019-1 
CVE-2019-5051]

Bug#935359: znc: Missing copyright attributions

[Mattia Rizzolo]

Source: znc
Version: 1.7.4-6
Severity: serious
X-Debbugs-Cc: la...@debian.org

On Wed, 21 Aug 2019, 10:53 pm Chris Lamb, 
wrote:

> missing at least some references to Jquery etc. etc.
>
>  -- Chris Lamb   Wed, 21 Aug 2019 20:53:36 +
>

ACK. :)

>

Bug#935351: qbzr: Qt4 removal from Bullseye

[Dmitry Shachnev]

On Wed, Aug 21, 2019 at 08:28:00PM +, Jelmer Vernooij wrote:
> Thanks for the heads-up. I've filed a removal request for qbzr, since it is
> unmaintained upstream and we will soon transition from bzr to breezy anyway.

Thanks for the quick reaction!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#934591: Anki fails to start: ModuleNotFoundError: No module named 'PyQt5.sip'

[Julian Gilbey]

On Wed, Aug 21, 2019 at 04:22:23PM +0200, Arnaldo Pirrone wrote:
> Hi, i do have python3-sip.
> Now the error is this:
> $ anki
> Traceback (most recent call last):
>   File "/usr/bin/anki", line 6, in 
>     import aqt
>   File "/usr/share/anki/aqt/__init__.py", line 32, in 
>     import aqt.forms
>   File "/usr/share/anki/aqt/forms/__init__.py", line 44, in 
>     from . import about
>   File "/usr/share/anki/aqt/forms/about.py", line 42, in 
>     from aqt.webview import AnkiWebView
>   File "/usr/share/anki/aqt/webview.py", line 90, in 
>     class AnkiWebView(QWebEngineView):
> NameError: name 'QWebEngineView' is not defined

OK, something is very very wrong with your installation of something,
or some other problem, but I'm quite stumped.  Anki imports the whole
of PyQt5.Qt, and that includes QWebEngineView.

Are you getting the same error message every time you try starting
Anki, or is it different each time?

Best wishes,

   Julian

Bug#858774: modes_rx: ImportError: cannot import name QtWebKit

[Dmitry Shachnev]

Control: severity -1 serious

On Sun, Mar 26, 2017 at 04:05:54PM +0200, Sebastian Niehaus wrote:
> when I call modes_gui it fails:
>
> users@liquid:~$ modes_gui 
> Traceback (most recent call last):
>   File "/usr/bin/modes_gui", line 24, in 
> from PyQt4 import QtCore,QtGui,QtWebKit
> ImportError: cannot import name QtWebKit

I am bumping the severity to release-critical because QtWebKit is no
longer available, and moreover, we are going to remove the whole
Qt4 from Bullseye: https://wiki.debian.org/Qt4Removal.

This package should be ported to PyQt5, or otherwise it will be
removed from Debian testing.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935351: qbzr: Qt4 removal from Bullseye

[Jelmer Vernooij]

On Wed, Aug 21, 2019 at 11:05:43PM +0300, Dmitry Shachnev wrote:
> As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
> cycle, as announced in [1].
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get removed
> from the Debian repositories.
> 
> Your package still uses Qt 4, via the Python bindings (PyQt4).
> 
> Therefore, please take the time and:
> 
> - contact your upstream (if existing) and ask about the state of a Qt 5 /
>   PyQt5 port of your application;
> - if there are no activities regarding porting, investigate whether there are
>   suitable alternatives for your users;
> - if there is a Qt 5 port that is not yet packaged, consider packaging it;
> - if both the Qt 4 and the Qt 5 versions already coexist in the Debian
>   archives, consider removing the Qt 4 version.
> 
> Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
> Please see [2] for the general porting instructions, and [3] for some
> Python-specific differences.

Thanks for the heads-up. I've filed a removal request for qbzr, since it is
unmaintained upstream and we will soon transition from bzr to breezy anyway.

Bug#934928: Bug#933829: win32-loader: Checksums need to be updated for new stable release, download fails to validate Release file.

[Didier 'OdyX' Raboud]

Le mercredi, 21 août 2019, 10.44:51 h CEST Adam D. Barratt a écrit :
> Control: tags -1 -moreinfo +confirmed
> 
> On 2019-08-21 09:14, Didier 'OdyX' Raboud wrote:
> > Le mardi, 20 août 2019, 16.55:47 h CEST Adam D. Barratt a écrit :
> >> Control: tags -1 + moreinfo
> >> 
> >> [Recipients changed to use the p-u bug rather than the win32-loader
> >> one]
> 
> >> On 2019-08-16 07:55, Didier 'OdyX' Raboud wrote:
> [...]
> 
> >> > +win32-loader (0.9.3+deb10u1) buster; urgency=medium
> >> > +
> >> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> >> > +(Closes: #933829)
> >> > +
> >> > + -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200
> >> > +
> >> > 
> >> >  win32-loader (0.9.3) unstable; urgency=medium
> >> >  
> >> >[ Thomas Gaugler ]
> >> 
> >> This wants to be against 0.9.4, which is the version in buster. It
> >> will
> >> also want an unblock-udeb for the 0.9.5 upload in unstable, so that
> >> reaches testing before the point release.
> > 
> > Ah, indeed; thanks for the check.
> > 
> > +win32-loader (0.9.4+deb10u1) buster; urgency=medium
> > +
> > +  * Rebuild in stable to embed the latest debian-archive-keyring
> > +(Closes: #933829)
> > +
> > + -- Didier Raboud   Fri, 16 Aug 2019 08:53:00 +0200
> 
> Better. :-) Please go ahead.

Uploaded.

> > As for the unblock-udeb; do you need another bug, or were you asking
> > debian-
> > boot@ for approval?
> 
> My understanding was that it's blocked at your request rather than
> -boot's, to ensure that it doesn't get out of sync with the files in
> tools/ on mirrors. I can happily add the unblock-udeb, but we'll need to
> make sure that ftp-master also do the relevant magic on their side. (If
> that's still manual intervention.)

(Thanks for the unblock :-) )

As far as I'm concerned, it can stay unblocked outside of the freeze. I don't 
care _enough_ for the testing win32-loader.exe to be in sync to warrant always 
needing to unblocking this package manually.

Where would it make sense to document that the win32-loader /tools/ 
counterpart needs to be copied from unstable to testing at freeze time and for 
each subsequent upload only, but that we're fine with having it out-of-sync 
outside of the freeze?

Cheers,
OdyX

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

Bug#935357: RM: qbzr -- ROM; unmaintained, uses deprecated libraries

[Jelmer Vernooij]

Package: ftp.debian.org
Severity: normal

This package is unmaintained upstream, and it uses deprecated libraries
that will soon be removed from the archive (PyQT4, Bazaar).

Bug#935356: RM: bzr-explorer -- ROM; unmaintained upstream

[Jelmer Vernooij]

Package: ftp.debian.org
Severity: normal

Please remove the bzr-explorer package from the archive.

This package is no longer maintained upstream, and will 
soon break due to the PyQT4 removal from the archive and
bazaar => breezy transition.

Bug#935355: xdu: synthesized nodes are absurdly large

[Norman Rasmussen]

Package: xdu
Version: 3.0-19
Severity: normal
Tags: patch

Nodes that do not appear in the input file have a huge size (near
MAXINT) due to an incorrect constant type. See attached patch for a fix.

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

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

Versions of packages xdu depends on:
ii  libc6 2.28-2
ii  libx11-6  2:1.6.4-3
ii  libxaw7   2:1.0.13-1+b2
ii  libxt61:1.1.5-1

xdu recommends no packages.

xdu suggests no packages.

-- no debconf information
--- a/xdu.c
+++ b/xdu.c
@@ -430,7 +430,7 @@
}
}
/* no child matched, add a new child */
-   np = makenode(path[0],-1);
+   np = makenode(path[0],(long long)-1);
insertchild(top,np,order);
 
if (path[1] == NULL) {

Bug#924278: stretch-pu: package clamav/0.100.2+dfsg-0+deb9u1

[Adam D. Barratt]

On Wed, 2019-08-21 at 21:45 +0200, Sebastian Andrzej Siewior wrote:
> On 2019-08-20 23:45:18 [+0100], Adam D. Barratt wrote:
> > > and then open p-u bugs
> > > for the transition?
> > 
> > Is anything required beyond binNMUs of r-deps?
> 
> I tried to highight this in the first email of this bug:

Sorry, this is clearly a sign that I should have stopped processing the
SRM mail queue earlier last night.

So, yes, that sounds like a good plan. We still have a week and a half
or so before the point release freeze, which should be plenty of time
from the SRM side, moudlo badgering ftp-team for the NEW processing.

> [I would also want to update clamav to what we have in stable-pu but
>  slowly and I *think* it would be good to have this one step in
> between  unless you prefer otherwise.]

I'm quite happy to go with whatever you think is best there.

Regards,

Adam

Bug#922875: xdu: miscounts the size of root directory

[Norman Rasmussen]

Package: xdu
Version: 3.0-19
Followup-For: Bug #922875

Dear Maintainer,

Here's a patch to fix the issue.

-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)

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

Versions of packages xdu depends on:
ii  libc6 2.28-10
ii  libx11-6  2:1.6.7-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxt61:1.1.5-1

xdu recommends no packages.

xdu suggests no packages.

-- no debconf information--- a/xdu.c
+++ b/xdu.c
@@ -305,6 +305,10 @@
}
name++;
}
+   if (arg == 0 && indx == 0) {
+   top.size = size;
+   return;
+   }
buf[indx] = 0;
path[arg++] = strdup(buf);
path[arg] = NULL;

Bug#887736: stretch-pu: package openvswitch/2.6.2~pre+git20161223-3

[Adam D. Barratt]

On Wed, 2019-08-21 at 15:28 -0400, Felipe Sateler wrote:
> Both `service` and `invoke-rc.d` wrappers have a few safeguards
> against running in unwanted contexts. Have you tried using one of
> them?
> 

For avoidance of any possible doubt, "you" here is Thomas, not me.

Regards,

Adam

Bug#935354: vitables: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: vitables
Version: 2.1-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935352: trimage: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: trimage
Version: 1.0.5+git20130126.e47888e-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935353: vistrails: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: vistrails
Version: 2.2.4-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935350: python-qt4reactor: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: qt4reactor
Version: 1.0-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935351: qbzr: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: qbzr
Version: 0.23.2-6
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935348: python-nfs-ganesha: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: nfs-ganesha
Version: 2.7.6-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935340: obitools: Port to Python3 needed

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://git.metabarcoding.org/obitools/obitools/issues/45

Bug#935347: pysatellites: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: pysatellites
Version: 2.5-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935349: python-pyface: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: python-pyface
Version: 4.5.2-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935346: puddletag: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: puddletag
Version: 1.2.0-2
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935343: eficas: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: eficas
Version: 6.4.0-1-2
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935345: microbegps: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: microbegps
Version: 1.0.0-3
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935341: backintime-qt4: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: backintime
Version: 1.1.24-0.1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935344: laborejo: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: laborejo
Version: 0.8~ds0-2
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935342: code-saturne: Qt4 removal from Bullseye

[Dmitry Shachnev]

Source: code-saturne
Version: 5.3.3+repack-2
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal

Hi!

As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
cycle, as announced in [1].

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get removed
from the Debian repositories.

Your package still uses Qt 4, via the Python bindings (PyQt4).

Therefore, please take the time and:

- contact your upstream (if existing) and ask about the state of a Qt 5 /
  PyQt5 port of your application;
- if there are no activities regarding porting, investigate whether there are
  suitable alternatives for your users;
- if there is a Qt 5 port that is not yet packaged, consider packaging it;
- if both the Qt 4 and the Qt 5 versions already coexist in the Debian
  archives, consider removing the Qt 4 version.

Porting from Qt 4 to 5 is much easier than it was to port from Qt 3 to 4.
Please see [2] for the general porting instructions, and [3] for some
Python-specific differences.

The removal is being tracked in [4]. My intention is to bump the severity
of this bug to RC soon, like it is already the case with other Qt 4 removal
bugs.

[1]: https://lists.debian.org/debian-devel-announce/2017/08/msg6.html
[2]: https://doc.qt.io/qt-5/sourcebreaks.html
[3]: https://www.riverbankcomputing.com/static/Docs/PyQt5/pyqt4_differences.html
[4]: https://wiki.debian.org/Qt4Removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#935337: RM: pillow -- NVIU; duplicated source packages in unstable

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2019-08-21 at 21:02 +0200, Héctor Orón Martínez wrote:
> I noticed src:pillow 4.3.0-2 and 6.1.0-1 in unstable.
> 
> At #debian-python:
> 
> < zumbi> there is src:pillow 4.3.0-2 and 6.1.0-1 in unstable, does
> some know if
>that's intentional? (to keep python-imaging?)
> < zumbi> (/cc doko ^)
> < doko> zumbi: no, probably should be removed
> 
> 
> Please remove src:pillow 4.3.0-2 along it's binaries, including
> python-imaging.

It has a bunch of r-deps:

$ dak rm -Rn --outdated pillow
W: -o/--outdated implies -p/--partial.
Will remove the following packages from unstable:

python-imaging |4.3.0-2 | all

Maintainer: Matthias Klose 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
griffith: griffith
oboinus: oboinus
phatch: phatch-cli
photon: photon
python-sponge: python-sponge
trac-odtexport: trac-odtexport
utopia-documents: utopia-documents [amd64 arm64 i386 mips64el mipsel ppc64el 
s390x]
virtualbricks: virtualbricks

# Broken Build-Depends:
psychopy: python-imaging
python-sponge: python-imaging (>= 1.1.6)
utopia-documents: python-imaging

Dependency problem found.

Nothing in the newer source package provides python-imaging.

Regards,

Adam

Bug#935340: obitools: Port to Python3 needed

[Andreas Tille]

Package: obitools
Severity: normal

The code needs to be ported to Python3

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

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

Versions of packages obitools depends on:
ii  cython 0.29.2-2
ii  libc6  2.28-10
ii  libjs-sphinxdoc1.8.4-1
ii  python 2.7.16-1
ii  python-ipython 5.8.0-1
ii  python-sphinx  1.8.4-1
pn  python-virtualenv  
pn  python-wheel   

obitools recommends no packages.

obitools suggests no packages.

Bug#924278: stretch-pu: package clamav/0.100.2+dfsg-0+deb9u1

[Sebastian Andrzej Siewior]

On 2019-08-20 23:45:18 [+0100], Adam D. Barratt wrote:
> > and then open p-u bugs
> > for the transition?
> 
> Is anything required beyond binNMUs of r-deps?

I tried to highight this in the first email of this bug:

|It affects the following packages as part of the transistion which
|require a source-full upload:
|- dansguardian
|  Update based on a patch I provided in #923981. NMU, removed from
|  unstable.
|
|- libclamunrar7/non-free
|  Splitted from clamav, will hit stable-new.
|
|- python-pyclamav
|  backported the API change from unstable.
|
|- havp
|  backported the API change from unstable.
|
|- c-icap-modules
|  backported the API change from unstable. NMU.

so are we doing this now or later?

[I would also want to update clamav to what we have in stable-pu but
 slowly and I *think* it would be good to have this one step in between
 unless you prefer otherwise.]

> Regards,
> 
> Adam

Seastian

Bug#931659: transition: rm python2

[Matthias Klose]

On 09.07.19 17:50, Matthias Klose wrote:
> On 09.07.19 00:31, Scott Kitterman wrote:

could somebody fix the py2-removal tracker again? replacing the terminating \b
chars with \s (4 times)?  currently it matches all python-* (python-gi-dev,
python-*-doc, ...) I think we are better with a smaller set

this removes around 2000 matches, and obviously is missing some dependencies,
but the current tracker has too many false positives.  Or we create another
tracker with this change.

Interesting thing found: python-gi-dev depends on both python2 and 3 packages 
...

Bug#935047: pulseaudio: regularly stops producing sound over USB interface

[Felipe Sateler]

Control: reassign -1 linux-image-5.2.0-2-amd64

On Tue, Aug 20, 2019 at 3:51 AM Adrian Heine  wrote:

> Sigh, after doing this I downgraded to pulseaudio 10.0 in the same
> session and still have the issue; I rebooted to be sure but it's still
> there. I swear it worked reliably for days after downgrading for the
> first time. Since the pulseaudio output doesn't show anything helpful as
> far as I can see it probably makes sense to have a look at alsa?
>

The only hint I can see is that there is a buffer overrun and then
pulseaudio tries to rewind. This most likely signals a bug in the driver,
possibly pulseaudio does something the driver did not expect.

As an additional debugging step, could you try adding tsched=0 to your
config?
https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Glitches.2C_skips_or_crackling

Sometimes driver bugs area avoided by using that option

-- 

Saludos,
Felipe Sateler

Bug#875138: Can we remove qsapecng?

[Simone Rossetto]

RM bug filed: #935338

Bye
Simone

Bug#887736: stretch-pu: package openvswitch/2.6.2~pre+git20161223-3

[Felipe Sateler]

On Tue, Aug 20, 2019 at 6:23 PM Adam D. Barratt 
wrote:

> Control: tags -1 + moreinfo
>
> On Fri, 2018-01-19 at 15:21 +0100, Thomas Goirand wrote:
> > I started maintaining OpenVSwitch long after the Stretch release, and
> > discovered #858418, which is very annoying for OpenVSwitch users.
> >
> > tl;dr: #858418 prevent anyone that has a valid
> > /etc/network/interfaces
> > with OpenVSwitch directive from having a working network at boot. The
> > init script uses a non-documented, not-to-be-used systemd internal,
> > which is miserably failing.
> >
> > After a long discussion with the bug reporter (which can be read on
> > the BTS), I came to the conclusion that he's right, and that the most
> > reasonable and safe way to fix the current situation is to apply the
> > patch he suggested (and which resulting debdiff I attached to this
> > bug).
>
> As I understand things, that fix swaps use of one systemd internal for
> another, which doesn't seem like a great plan.
>
> When this was discussed (some time ago) on IRC, one of the systemd
> maintainers essentially said "don't do that". With apologies for the
> delay in doing so, I've CCed the maintainer list to see if we can find
> a mutually acceptable solution.
>

Both `service` and `invoke-rc.d` wrappers have a few safeguards against
running in unwanted contexts. Have you tried using one of them?

-- 

Saludos,
Felipe Sateler

Bug#934965:

[thomasw]

Just wonder if anyone was able to reproduce this. This patch is adding good 
functionality (locking the screen before suspend) so reverting is not the 
correct solution. Before I start investigating this, I would like to know if it 
works correctly for some people. I have a few friends that run Debian with Mate 
and everyone that I talked to says it regressed for them. Can anyone verify 
that this patch is working correctly for them and not triggering an inhibitor 
timeout? If the new version of this package works correctly for you, I would 
like to try to reason what is different about our environments. I guess the 
easiest way to know is to click suspend from the shutdown dialog and see if 
your machine takes a bit of time to suspend. You will also be able to use the 
machine during the 5 second delay before suspend.

Bug#935339: ruby-svg-graph: depends on ancient 'parsedate' Ruby core library

[duck]

package: ruby-svg-graph
version: 1.0.5-3
severity: serious


Quack,

Sorry for the bad news but this library is not fit for release in this 
state. It depends on parsedate which was last seen in Ruby core in 
1.8.7:


/usr/lib/ruby/vendor_ruby/SVG/Graph/TimeSeries.rb
4:  require 'parsedate'
197:arr = ParseDate.parsedate(time)

/usr/lib/ruby/vendor_ruby/SVG/Graph/Schedule.rb
4:  require 'parsedate'
169:  arr = ParseDate.parsedate( data[:data][i] )
187:  arr = ParseDate.parsedate( value )

There is a patch, and a fix for the original path, here: 
http://www.redmine.org/issues/11290


I did not have time to test it yet, but if we want to keep this library 
around I think this is worth a try.


Also Buster is affected so we should plan a backport when we have a 
working solution.


I'm part of the Ruby team but in case I don't have time to look at it 
later here are the details I could collect.


Regards.
\_o<

--
Marc Dequènes

Bug#935338: RM: qsapecng -- ROM; dead upstream and depends on qt4

[Simone Rossetto]

Package: ftp.debian.org
Severity: normal

QSapecNG is dead upstream and it depends on Qt4 which is going to be removed
from Debian. There is no porting to Qt5 at the moment.

Bug#932684: buster-pu: package gnupg2/2.2.12-1+deb10u1

[Daniel Kahn Gillmor]

On Wed 2019-08-21 18:19:06 +0100, Adam D. Barratt wrote:
>>  * We adopt GnuPG's upstream approach of making keyserver access
>>default to self-sigs-only.  This means that the keyserver cannot
>>flood the user's keyring by default. (we do *not* adopt upstream's
>>choice of import-clean for keyserver default, see
>>https://dev.gnupg.org/T4628 for more explanation)
>
> The introduction of this change in unstable (and since in testing)
> apparently led to some confusion amongst, and queries from, members of
> the project, so is likely to have a similar (but quite possibly larger)
> effect on the wider stable user base.
>
> If we are to include it, I think it would therefore be wise to ensure
> that it is accompanied by a NEWS entry which briefly explains the
> change and its implications. (Relatedly, the further through the stable
> cycle we get, the more awkward this would be to introduce.)

Thanks, that's entirely reasonable.  I've put this NEWS item into the
debian/buster branch on salsa.  Otherwise, the debdiff is the same.  


diff --git a/debian/NEWS b/debian/NEWS
index 0a6a7440d..3005e935c 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,25 @@
+gnupg2 (2.2.12-1+deb10u1) buster; urgency=medium
+
+  In this version we adopt GnuPG's upstream approach of making keyserver
+  access default to self-sigs-only.  This defends against receiving
+  flooded OpenPGP certificates.  To revert to the previous behavior (not
+  recommended!), add the following directive to ~/.gnupg/gpg.conf:
+
+keyserver-options no-self-sigs-only
+
+  We also adopt keys.openpgp.org as the default keyserver, since it avoids
+  the associated bandwidth waste of fetching third-party certifications
+  that will not be used.  To revert to the older SKS keyserver network (not
+  recommended!), add the following directive to ~/.gnupg/dirmngr.conf:
+
+keyserver hkps://hkps.pool.sks-keyservers.net
+
+  Note: we do *not* adopt upstream's choice of import-clean for the
+  keyserver default, since it can lead to data loss, see
+  https://dev.gnupg.org/T4628 for more details.
+
+ -- Daniel Kahn Gillmor   Wed, 21 Aug 2019 14:53:47 
-0400
+


Let me know if you want me to re-generate a full debdiff, or if you're
ok with this plus the previous debdiff (with an updated date on
debian/changelog to match debian/NEWS), let me know whether i should go
ahead and upload.

Thanks for your thoughtfulness and review.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#935337: RM: pillow -- NVIU; duplicated source packages in unstable

[Héctor Orón Martínez]

Package: ftp.debian.org
Severity: normal

Hello,

I noticed src:pillow 4.3.0-2 and 6.1.0-1 in unstable.

At #debian-python:

< zumbi> there is src:pillow 4.3.0-2 and 6.1.0-1 in unstable, does some know if
   that's intentional? (to keep python-imaging?)
< zumbi> (/cc doko ^)
< doko> zumbi: no, probably should be removed


Please remove src:pillow 4.3.0-2 along it's binaries, including python-imaging.

@doko, could you please confirm?

Regards

Bug#935336: jsvc on buster doesn't support the installable openjdk version

[Nick Minkler]

Package: jsvc
Version: 1.0.15-8

When attempting to run a jsvc daemon on buster using the available openjdk
installation jsvc complains that JAVA_HOME is not set to a valid VM:

"Cannot find any VM in Java Home /usr/lib/jvm/default-java"

Listing the contents of /usr/lib/jvm/ shows that default-java is correctly
linked to java-11-openjdk-amd64 that is installed from the openjdk-11-jre
package.

jsvc didn't appear to add support for java 9+ until 1.1.x line and the most
recent version available in debian is 1.0.x. If debian is shipping
openjdk-11 in buster. one would think we would also ship a jsvc that works
with it.

ii  openjdk-11-jre:amd64  11.0.4+11-1~deb10u1
amd64OpenJDK Java runtime, using Hotspot JIT
ii  openjdk-11-jre-headless:amd64 11.0.4+11-1~deb10u1
amd64OpenJDK Java runtime, using Hotspot JIT (headless)
ii  jsvc  1.0.15-8
 amd64Wrapper to launch Java applications as daemons

-- 
Nick Minkler
Software Development
Integrated Services, Inc.
nick.mink...@ints.com
www.ints.com
P:800.252.3099 x286
F:503.968.9100

Bug#935243: Does not work with Thunderbird

[Mechtilde Stehmann]

Hello MArtin,

you installed thunderbird from experimental.

In sid I found thunderbird version 1:60.8.0-1.

So webext-tbsync is very usefull in unstable.

Kind regards


-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#935335: Depends on removed python-zbar

[Andrey Rahmatullin]

Package: src:monkeysign
Version: 2.2.4
Severity: serious

As Python 2 versions of zbar and zbarpygtk were removed, this package should be
updated to use Python 3 or removed.



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

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

Bug#934872: RM: ocaml-usb/1.3.0-4 ocaml-sqlexpr/0.5.5-3 zeroinstall-injector/2.12.3-2 obus/1.1.5-6

[Stéphane Glondu]

Le 21/08/2019 à 20:07, Thomas Leonard a écrit :
>> Again, this removal from testing is not a definitive removal from Debian
>> and may be just temporary. I didn't mean to be hostile.
> 
> Do you have an idea of when this will be? I should be able to look at
> a workaround this weekend if it's not back by then.

I expect it will take a few months before obus is in testing again. Note
that I've also dropped liblwt-glib-ocaml-dev (as it is separate in newer
upstream version of lwt which also needs to be updated), so you'll have
to workaround that as well.


Cheers,

-- 
Stéphane

Bug#934996: transition: xfce4-panel

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-08-21 at 09:55 +, Niels Thykier wrote:
> Could you check if
> https://release.debian.org/transitions/html/xfce4-panel.html matches
> your expectation for the packages affected by this transition?

I'm a bit surprised we have so few libxfce4panel-1.0 dependencies left, but
that's nice.

place and weather plugins will have a sourceful upload bumping them to
libxfce4panel-2.0 so they'll disappear from the list.

I'm still a bit unsure about the behavior of libxfce4panel-2.0 4.14 plugins
when they're loaded in a 4.12 panel, but they shouldn't require a binNMU
anyway.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1dj/IACgkQ3rYcyPpX
RFu4XQf/fTyCSAmIx46kl2mZJ2DewBdpZIPr2IhL+0SbUfF9xhNkxd+1UvCUIHcC
MeC/8v66KKz3BDdyTzmxT86spiHxeVsrs5HoCVn8DqLAyFp4kcl2ITwO9b0gNWVz
RDbKk4wK+d3vNnxhbGtT4MwY8231EN4NAWo9Vc1BjguuFe6Sklv20GntYyxNDvbR
bNxAG17sKSTOP0nmI6ZqkHaDi8GjrlmmSIhg79Z27505rZIZGxjsMdar4WG/EkpU
ozVPB/yCaGHFIP7rfazZejQZAXdYS4G/zrx4ypECIFo5PjB38F9+esF84XHaLIIJ
X1LbjyrNtb29w9xrbm1UyQkolAAwKg==
=BuLD
-END PGP SIGNATURE-

Bug#935082: (no subject)

[Russell Jackson]

Hi,

Any update on when we can expect an updated package in the security repo?

Thanks.

-- 
Russell A Jackson
Information Security and Emerging Technologies
California State University, San Bernardino