Bug#940579: found 940579 in 4.08.1-1

[Stéphane Glondu]

On Tue, 12 Nov 2019 01:15:53 +0100 Andreas Beckmann  wrote:
> found 940579 4.08.1-1

Why?


Cheers,

-- 
Stéphane

Bug#944641: linux-perf-4.19: Many "perf script" scripts do not work because they lack python3 support

[Benjamin Poirier]

Package: linux-perf-4.19
Version: 4.19.67-2+deb10u2
Severity: normal
Tags: upstream

perf embeds a python interpreter and the debian linux source package has
debian/rules.d/tools/perf/Makefile:MAKE_PERF += PYTHON=/usr/bin/python3

However, many of the scripts in tools/perf/scripts/python, executed via `perf
script [...]`, did not support python3 in the 4.19 release.

For example:
root@vdebian:~# perf script net_dropmonitor
  File "/usr/lib/perf_4.19-core/scripts/python/net_dropmonitor.py", line 53
print "%25s %25s %25s" % ("LOCATION", "OFFSET", "COUNT")
 ^
SyntaxError: invalid syntax
Error running python script 
/usr/lib/perf_4.19-core/scripts/python/net_dropmonitor.py
---

This issue was fixed upstream in the following series:
02b03ec383e0 perf script python: Add Python3 support to netdev-times.py
9b2700efc57f perf script python: Add Python3 support to 
failed-syscalls-by-pid.py
e4d053ddb4c4 perf script python: Add Python3 support to mem-phys-addr.py
8c42b9600e56 perf script python: Add Python3 support to net_dropmonitor.py
118af5bf799b perf script python: Add Python3 support to powerpc-hcalls.py
ee75a896ae53 perf script python: Add Python3 support to sctop.py
6d22d9991cf3 perf script python: Add Python3 support to stackcollapse.py
e985bf761db7 perf script python: Add Python3 support to stat-cpi.py
1d1b0dbb859d perf script python: Add Python3 support to syscall-counts.py
de667cce7f4f perf script python: Add Python3 support to syscall-counts-by-pid.py

Bug#930526: incron creates zombie processes

[Michael Prokop]

Hi,

(Cc-ing original bug reporter as well who triggered this, thanks!)

* Alexander Brüning [Sun Oct 27, 2019 at 08:41:29PM +]:

> This is still an issue on 0.5.12-1

> These commits apparently fix it
> https://github.com/ar-/incron/commit/f45c2f5ac4baea99b48e99a713d1f4ec1854aa76

ACK, though only
https://github.com/ar-/incron/pull/42/commits/196975d26fd04176a1c877fa3c404efd8103c9c2
is relevant in the version present in Debian (the other commit is
already present).

A customer of mine was affected as well by this and I created a
custom local package for buster which includes the fix, works fine
and as expected there. Though it definitely makes sense to a) upload
this to unstable and also b) provide a package upload to stable (to
be part of the upcoming point release of buster) to fix this.

I created a merge request for Emmanuel:

  https://salsa.debian.org/kolter/incron/merge_requests/1

Emmanuel, please consider merging this and upload the package
towards unstable and stable ASAP (incron is really unuseable as-is).
Let me know if you need anything else or if anything should prevent
you from taking care.

regards
-mika-


signature.asc
Description: Digital signature

Bug#944640: gtk-d: FTBFS on armel/armhf with many "multiple definition" messages

[Raphaël Hertzog]

Source: gtk-d
Version: 3.9.0-2
Severity: important
Tags: ftbfs

Hi,

can you make a new source upload to let the package migrate to testing
please ?

I also noticed that the package still fails to build on armel/armhf with
hundreds of message like these:

/usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
`_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
`_DT24_D3gtk6Widget6Widget10__mixin37720setBuildablePropertyMFC3gtk7Builder7BuilderAyaC7gobject5Value5ValueZv';
 ./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
/usr/bin/ld: ./libgtkd-3.a(ColorSelection.o): in function 
`_D3std4conv110__T8textImplTAyaTAyaTPvTAyaTiTAyaTiTAyaTaTAyaThTAyaThTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTbTAyaTAxaTAyaTAxaTAyaZ8textImplFNaNfAyaPvAyaiAyaiAyaaAyahAyahAyabAyabAyabAyabAyabAyabAyaAxaAyaAxaAyaZAya':
./generated/gtkd/gtk/ColorSelection.d:401: multiple definition of 
`_DT24_D3gtk6Widget6Widget10__mixin37716buildableSetNameMFAyaZv'; 
./libgtkd-3.a(Button.o):./generated/gtkd/gtk/Button.d:565: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [GNUmakefile:252: TestWindow] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: make -j8 "INSTALL=install --strip-program=true" test shared 
prefix=/usr returned exit code 2
make[1]: *** [debian/rules:19: override_dh_auto_build] Error 255


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

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

Bug#944639: ITP: ddogleg -- library for non-linear optimization, clustering, robust model fitting and more

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : ddogleg
  Version : 0.17+ds
  Upstream Author : Peter Abeles
* URL : http://ddogleg.org
* License : Apache-2.0
  Programming Lang: Java
  Description : library for non-linear optimization, clustering,
robust model fitting and more
 DDogleg Numerics is a high performance Java library for non-linear
 optimization, clustering, robust model fitting, polynomial root finding,
 sorting, and more. The API is designed to be user to use, without excessive
 abstraction often found in other libraries. The user is provided with the
 capability to have tight control over memory and CPU usage.

libddogleg-java is a dependency of deepboof, which I eventually intend
to package.

Remark: This package is to be maintained with Debian Java Maintainers at
   https://salsa.debian.org/java-team/ddogleg

Bug#944191: mutt: Mutt Fails GNU TLS Handshake

[Antonio Radici]

On Tue, Nov 12, 2019 at 12:18:14PM -0600, David Engel wrote:
> On Sat, Nov 09, 2019 at 05:52:59PM +, Antonio Radici wrote:
> > On Tue, Nov 05, 2019 at 10:23:25AM -0600, David Engel wrote:
> > > Package: mutt
> > > Version: 1.12.2-1
> > > Severity: normal
> > > 
> > > Beginning with version 1.12.2-1, Mutt fails GNU TLS handshake with the
> > > following error when connecting to an MS Exchange server:
> > > 
> > > gnutls_handshake: A packet with illegal or unsupported version was 
> > > received.
> > > 
> > > The problem does not exist with Mutt version 1.10.1-2.1.
> > > 
> > 
> > Is this pop3 or imap or smtp?
> 
> Imap.
> 
> > Could you include the muttdebug file which is obtained by using the debug 
> > option
> > with mutt? be aware that your personal information (including password) 
> > might be
> > there, so please remove that before attaching it to the bug.
> 
> .muttdebug0 from running with -d2 is attached.  It doesn't appear to
> be of much help.

Do you know which version of TLS your imap server is using?
be aware that version < 1.2 are not supported and you will have to enable them
on .muttrc explicitely if you need them (see man muttrc, look for 
'ssl_use_tlsv1'
and 'ssl_use_tlsv1_1'

Bug#944426: lazarus-src-2.0 fails to upgrade from 2.0.2+dfsg-7 to 2.0.6+dfsg-1: trying to overwrite filefindlaz.lpk

[François Revol]

Same issue here, except on this file:

/usr/lib/lazarus/2.0.6/components/IdeInspector/ideinspector.lpk


I guess it's the same problem as in #942768 .

Bug#944638: querybts: filter by release

[Moshe Piekarski]

Package: reportbug
Version: 7.5.3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please consider adding the ability to only show bugs from specific releases to 
reportbug.
Thank you for your time,
Moshe Piekarski


-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAl3LoSwZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igaCGD/9XzYjq3DTJIKQ0WWhhvdFM
uDbEJ4P0Fv+LFWASKnuej9Tb6ACaje28+Gu4efohJpkodeTZ/4dUyVQ2We2PdFOt
X0bWLQkC2ofBeQOSAXHmcCHzyni9mN8CJQBP+bUm67UYUmeILyDURvMfGiCyjCln
shxJC+gLnye4oGydiUrX0adsyRTAYEfgpcosnyhZ95Qdm59vf/IblTRqDf8EG/K6
l0dvzXJCEDN8V26omL99Dk4BL9c+aL13Sh3o+OMfZUcqCeMQ13X2VscoRa2qNtVc
VcZpsdLdQgOcWdmAocciH83VL13yXDzGuXv6eAbBPqHQudQ80TsN+koybHNESN2H
UXyVyHRUcfRoh7YFOf6spLpoyLnt9sz8AMpwLWY23l+/UZV0At7TcKohvNsKwmXW
hx/q/3NUcMHC6k4FyiP2QAwbwQY8QqHTMnpJZ4PiEwz5UCZXDQlDUfsu2chkhWz4
EwmyzZH3cZmsGCKKUoa5gwpiJe7r+DiaHtm3e+gtacBE6jQK2Rrh3LG1MwUb7d10
BDHdgxEFPKqGao5eCZDA81AvIVzhnErR7yPVTQKmJw3b8BEbXcFhuEoBRR0U5pRz
Byz3c7ZosUivvAjSQYqCr3q5xIYFppVstrFazQP5sJ6QVXHWPOo4nYOVHSznMhfI
EgWakSBialfTntXHRpM4Zg==
=uHXU
-END PGP SIGNATURE-

Bug#944637: RM: firefox-esr/stable [armel] -- RoQA; no longer supportable

[Adam D. Barratt]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Tags: buster
X-Debbugs-CC: j...@debian.org, jcris...@debian.org

Building firefox-esr in buster now requires nodejs, which isn't
available on armel.

The reverse dependencies of the firefox-esr binary package on armel
appear to be firefox-esr-l10n-*, design-desktop and parl-desktop, all
of which are arch:all and have no reverse dependencies on armel.

Once I know the bug number, I'll clone a copy to ftp.d.o for the
removal from the security archive.

Regards,

Adam

Bug#944636: insighttoolkit4: CMake missing files for imported targets

[Bas Couwenberg]

Source: insighttoolkit4
Version: 4.13.2-dfsg1-1
Severity: important
Control: affects -1 src:otb

Dear Maintainer,

When building otb with only insighttoolkit4 and without opencv (#944341 causes 
B-D uninstallable), the configure target fails due to missing files for 
imported targets and missing FindLIBMINC.cmake:

 -- The imported target "vtkgdcm" references the file
"/usr/lib/x86_64-linux-gnu/libvtkgdcm.so.3.0.4"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "vtkgdcmsharpglue" references the file
"/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "vtkgdcmJava" references the file
"/usr/lib/x86_64-linux-gnu/jni/libvtkgdcmJava.so"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "vtkgdcmPython" references the file
"/usr/lib/python/dist-packages/vtkgdcmPython.so"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "vtkgdcmPythonD" references the file
"/usr/lib/x86_64-linux-gnu/libvtkgdcmPythonD.so.3.0.4"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "gdcmdump" references the file
"/usr/bin/gdcmdump"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "gdcmdiff" references the file
"/usr/bin/gdcmdiff"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "gdcmraw" references the file
"/usr/bin/gdcmraw"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "gdcmscanner" references the file
"/usr/bin/gdcmscanner"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "gdcmanon" references the file
"/usr/bin/gdcmanon"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation package was faulty and contained
"/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
 but not all the files it references.
 
 -- The imported target "gdcmgendir" references the file
"/usr/bin/gdcmgendir"
 but this file does not exist.  Possible reasons include:
 * The file was deleted, renamed, or moved to another location.
 * An install or uninstall procedure did not complete successfully.
 * The installation 

Bug#944635: jack-tools FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: jack-tools
Version: 20131226-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

jack-tools fails to cross build from source, because the upstream
Makefile hard codes the build architecture compiler. The attached patch
makes it substitutable and additionally makes debian/rules export cross
tools using dpkg's buildtools.mk to make jack-tools cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru jack-tools-20131226/debian/changelog 
jack-tools-20131226/debian/changelog
--- jack-tools-20131226/debian/changelog2014-10-15 15:54:35.0 
+0200
+++ jack-tools-20131226/debian/changelog2019-11-13 06:02:12.0 
+0100
@@ -1,3 +1,12 @@
+jack-tools (20131226-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make the compiler substitutable.
++ Let dpkg's buildtools.mk supply cross tools.
+
+ -- Helmut Grohne   Wed, 13 Nov 2019 06:02:12 +0100
+
 jack-tools (20131226-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru jack-tools-20131226/debian/patches/cross.patch 
jack-tools-20131226/debian/patches/cross.patch
--- jack-tools-20131226/debian/patches/cross.patch  1970-01-01 
01:00:00.0 +0100
+++ jack-tools-20131226/debian/patches/cross.patch  2019-11-13 
06:02:09.0 +0100
@@ -0,0 +1,38 @@
+--- jack-tools-20131226.orig/Makefile
 jack-tools-20131226/Makefile
+@@ -8,19 +8,19 @@
+ all: $(bin)
+ 
+ jack-transport: jack-transport.c
+-  gcc $(CFLAGS) $(LDFLAGS) -o jack-transport jack-transport.c $(LDLIBS) 
-lcurses
++  $(CC) $(CFLAGS) $(LDFLAGS) -o jack-transport jack-transport.c $(LDLIBS) 
-lcurses
+ 
+ jack-dl: jack-dl.c
+-  gcc $(CFLAGS) $(LDFLAGS) -o jack-dl jack-dl.c $(LDLIBS) -ldl -llo
++  $(CC) $(CFLAGS) $(LDFLAGS) -o jack-dl jack-dl.c $(LDLIBS) -ldl -llo
+ 
+ jack-play: jack-play.c
+-  gcc $(CFLAGS) $(LDFLAGS) -o jack-play jack-play.c $(LDLIBS) -lsndfile 
-lsamplerate
++  $(CC) $(CFLAGS) $(LDFLAGS) -o jack-play jack-play.c $(LDLIBS) -lsndfile 
-lsamplerate
+ 
+ jack-record: jack-record.c
+-  gcc $(CFLAGS) $(LDFLAGS) -o jack-record jack-record.c $(LDLIBS) 
-lsndfile
++  $(CC) $(CFLAGS) $(LDFLAGS) -o jack-record jack-record.c $(LDLIBS) 
-lsndfile
+ 
+ jack-scope: jack-scope.c
+-  gcc $(CFLAGS) $(LDFLAGS) -o jack-scope jack-scope.c $(LDLIBS) -lX11 
-lXext
++  $(CC) $(CFLAGS) $(LDFLAGS) -o jack-scope jack-scope.c $(LDLIBS) -lX11 
-lXext
+ 
+ clean:
+   (cd c-common ; make clean)
+--- jack-tools-20131226.orig/c-common/Makefile
 jack-tools-20131226/c-common/Makefile
+@@ -47,7 +47,7 @@
+   xregcomp.o
+ 
+ %.o : %.c %.h
+-  gcc -Wall -O2 -c $*.c
++  $(CC) -Wall -O2 -c $*.c
+ 
+ all: $(obj)
+   ar -rcs lib-c-common.a $(obj)
diff --minimal -Nru jack-tools-20131226/debian/patches/series 
jack-tools-20131226/debian/patches/series
--- jack-tools-20131226/debian/patches/series   2014-10-15 14:58:14.0 
+0200
+++ jack-tools-20131226/debian/patches/series   2019-11-13 06:01:36.0 
+0100
@@ -2,3 +2,4 @@
 make-installation-directories.patch
 use_ldflags.patch
 jackplay_flags.patch
+cross.patch
diff --minimal -Nru jack-tools-20131226/debian/rules 
jack-tools-20131226/debian/rules
--- jack-tools-20131226/debian/rules2014-10-15 14:58:14.0 +0200
+++ jack-tools-20131226/debian/rules2019-11-13 06:02:12.0 +0100
@@ -17,6 +17,8 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
+DPKG_EXPORT_BUILDTOOLS = 1
+include /usr/share/dpkg/buildtools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/class/makefile.mk

Bug#944223: Acknowledgement (lz4 SIGSEGV in LZ4_decompress_generic)

[Nobuhiro Iwamatsu]

Control: severity -1 important

Hi,

Thanks for your work and patch is looking good to me.
I will apply this  to buster.

Best regards,
  Nobuhiro

2019年11月8日(金) 17:48 Mihail Safronov :
>
> Patch for Debain Buster
>
> пт, 8 нояб. 2019 г. в 11:56, Mihail Safronov :
>>
>> Patches for Debian Stretch
>>
>> чт, 7 нояб. 2019 г. в 19:15, Mihail Safronov :
>>>
>>> Problem is more complex. When receive incomplete stream, decompression 
>>> context need to be reset with LZ4F_resetDecompressionContext (added in lz4 
>>> 1.8.0).
>>>
>>> I add simple port (this is for lz4 1.7 in CentOS 7)
>>>
>>> void LZ4F_resetDecompressionContext(LZ4F_dctx* dctx)
>>> {
>>> dctx->dStage = dstage_getHeader;
>>> dctx->dict = NULL;
>>> dctx->dictSize = 0;
>>> }
>>>
>>> And with first patch problem was solved.



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#850644: #850644: RFP: Guix in Debian

[Vagrant Cascadian]

On 2019-05-28, Vagrant Cascadian wrote:
> On 2019-05-16, Vagrant Cascadian wrote:
>> So in a bit of a focused run of packaging, I've been chasing the
>> dependency chain necessary to get guix building on Debian:

Summary: all the dependencies are in Debian!


>> * guile-gnutls needs to be (re)enabled in libgnutls*:
>>
>>   https://salsa.debian.org/vagrant/gnutls
>
> Proposed a patch to re-enable:
>
>   https://bugs.debian.org/905272#29

Which has since been fixed and guile-gnutls is again available in
Debian!


>> * guile-json needs to be updated to version 1.2.0 (3.x is incompatible),
>>   and I've pushed wip branches updating packaging for new upstream
>>   versions:
>>
>>   https://salsa.debian.org/debian/guile-json
>
> Updated to 1.2.0 in Debian experimental. A little awkward not updating
> to the newest upstream version, but hopefully that won't last forever...

Guix has since switched to guile-json 3.x, which is now in Debian.


>> * I've gotten some packaging for guile-git, guile-gcrypt, guile-ssh and
>>   guile-sqlite3 which need some more polish and then uploading to
>>   Debian:
>>
>>   https://salsa.debian.org/vagrant/guile-gcrypt
>>   https://salsa.debian.org/vagrant/guile-sqlite3
...
>>   https://salsa.debian.org/vagrant/guile-ssh

All Debian for a few months now!


>> * guile-git required scheme-bytestructures, which I've packaged, and
>>   needs to be uploaded before guile-git can be:
>>
>>   https://salsa.debian.org/vagrant/scheme-bytestructures
>
> Uploaded and waiting in NEW for review:
>
>   https://ftp-master.debian.org/new/scheme-bytestructures_1.0.5-1.html

scheme-bytestructures went through NEW a while back and...

The guile-git package just landed in Debian a few days ago, which was
the last missing build-dependency!


> It still needs a way to get the bootstrap binaries (bash, mkdir, tar and
> xz) from Guix; right now they're binaries shipped in the source!
> Ludovic Courtès worked on a patch that would in theory download those at
> run-time, but that is not yet working...

Since been solved in guix master branch, yay!


> Bootstrapping the system with MES is also WIP in Guix, and it might be
> possible to build identical bootstrap binaries using MES in Debian at
> some point:
>
>   https://bugs.debian.org/902174

I've made some progress on packaging MES as well, but I'm not sure we
want to wait till that's done to upload to Debian...


> The guix packaging for Debian also has a small number of test failures,
> at least one of which simply needs to be disabled because it accesses
> the network (which violates Debian policy).

The test failures seem a bit larger on this most recent pass.


> Also needs some updates to the packaging to get the guix-daemon running
> out of the box, for which there's a provided systemd service, and adding
> some guixbuild users, which shouldn't be too hard.

Working on that now...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#902174: #902174: RFP: mes

[Vagrant Cascadian]

On 2019-06-10, Vagrant Cascadian wrote:
> On 2019-06-10, Vagrant Cascadian wrote:
> I updated to b3fa6273210200cf2694491b07ed5a328e9a4e62 from upstream,
> added a few packaging updates, and... The current branch builds a
> package!
>
>   https://salsa.debian.org/vagrant/mes

Updated to 0.20 a while back and have iterated through a few test builds
on i386, and it appears to be working:

  https://salsa.debian.org/vagrant/mes


> A few test failures on amd64, but i386 tests run fine.

Still one test suite failure on amd64, i386 works fine. The failing test
on amd64 is:

  lib/tests/dirent/90-readdir.c

Is there any way to mark the failing test as XFAIL conditionally by
architecture?


A bigger blocker at this point is that mes installs numerous files in
/usr/include/, such as /usr/include/alloca.h, that conflict with other
packages such as libc6-dev. In a Debian environment, we typically can't
have multiple packages shipping the same files in the same PATHS. Other
libc implementations seem to put them in /usr/include/IMPLEMENTATION/
subdirs, e.g. /usr/include/mes/.

With the /usr/include issue solved and ideally the test suite failure
too, it would in my opinion be feasible to upload to Debian!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#303228: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#828761: hours_since should not update flag file after an error

[Paul Wise]

On Tue, 2019-11-12 at 09:54 +0100, Marc Haber wrote:

> Check hours_since
> Do command, bail out if unsuccessful
> update flag file

Hmm, I suppose that could work, but right now there is no way for
hours_since to communicate to the parent mr process that the flag file
should be updated and which flag file to update.

The stdout channel is already used so that would mean opening a pipe
from the child to the parent and telling hours_since which file
descriptor to write to using an environment variable.

I'm not proficient enough with file descriptors and Perl to be able to
implement this but I could add it to the myrepos codebase if I were to
get an example of how to do this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#719266: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#936745: [Python-modules-team] Bug#936745: reducing matplotlib2 build-depends.

[Sandro Tosi]

> I'd like to encourage you to drop python-qt4 and the Qt4 backend regardless 
> of the rest.  Qt4 is definitely getting removed this cycle, so this has got 
> to go, sooner or later (I'd prefer sooner).  The Qt5 backend should be enough.

yup that's done already
https://salsa.debian.org/python-team/modules/matplotlib2/commit/b09cf818d903839240a3390baf0dd80e1b3fee62
(not uploaded yet)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#936745: [Python-modules-team] Bug#936745: reducing matplotlib2 build-depends.

[Scott Kitterman]

On November 13, 2019 2:10:49 AM UTC, Sandro Tosi  wrote:
>On Tue, Nov 12, 2019 at 9:24 AM peter green 
>wrote:
>> I am guessing that many of these are to get testsuite coverage for
>optional features and are not strictly needed for the build, while
>testing stuff is nice I don't think it's vital for software that is on
>it's way out. I tried removing all of the aforementioned packages
>except python-setuptools and python-kiwisolver from the build-depends
>(and I uninstalled all python 2 packages from the chroot where I was
>doing my test builds before I installed the remaining build-depends).
>
>well, i dont think it's a good reason to just stop testing complex
>software tho. some of those dependencies are required so that mpl can
>build extensions (in particular for the GUI backends) so if you remove
>them, the mpl build system is smart enough to disable those
>extensions, resulting in a graphic library without any GUI bindings to
>work with. that doesnt sound ideal.
>
>I'm gonna go thru some of the dependencies and will see if i can
>remove some, in particular now that i've remored the -doc package from
>the git repo, but i'm not gonna get rid the whole unittest suite.
>
>thanks for your work on this, and to nudge me into looking deeper at
>mpl2 deps

I'd like to encourage you to drop python-qt4 and the Qt4 backend regardless of 
the rest.  Qt4 is definitely getting removed this cycle, so this has got to go, 
sooner or later (I'd prefer sooner).  The Qt5 backend should be enough.

Scott K

Bug#835565: mr list does not work

[Paul Wise]

On Tue, 2019-11-12 at 11:47 +0100, Marc Haber wrote:

> [2/8512]mh@drop:~ $ mr list
> 
> 
> 
> 
> 
> 
> mr list: /home/mh/.config/vcsh/repo.d/vim.git
> list
> 
> mr list: finished (7 ok)
> [3/8513]mh@drop:~ $ 
> 
> There is indeed a repo.d/vim.git, but that's only one of the eight
> that are there.

Hmm, that seems to be some sort of race condition but you aren't
running in parallel mode.

I'm at a loss to explain what is going on.

Could you try both 'list = true' and 'list = echo list' with verbose
mode turned on?

   mr --verbose ls

Could you try myrepos git master and report the results with both
'list = true' and 'list = echo list' with verbose mode turned on/off?

In addition, lets eliminate some possibilities:

 * That something in your user account is causing this; please create a
   new user account, login to that from getty or your display manager,
   check out eight git repos, register each of them with myrepos and
   list the repositories.
 * That something in your installation is causing this; please do the
   same test but do it after booting a Debian live image.
 * That something in your hardware is causing this; please do the
   Debian live image test but do it on different hardware.

If none of the above prove fruitful, I'll have to ask you to try and
debug this yourself by modifying the myrepos code.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#944634: nmu: sundials_4.1.0+dfsg-1

[James Tocknell]

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

nmu sundials_4.1.0+dfsg-1 . ANY . experimental . -m "Rebuild against libhypre 
(=2.18.2) - see libhypre README.Debian for more details about the new ABI plan."

Hi Release Team

libsundials in experimental is currently uninstallable due to the packaging
change that the libhypre maintainers made in reaction to the less-than-ideal ABI
stability of upstream libhypre. Can libsundials be rebuilt against the new
libhypre (I think I did this correctly, but this is my first binNMU, so let me
know if I did anything wrong).

Thanks
James

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FORCED_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#936745: reducing matplotlib2 build-depends.

[Sandro Tosi]

On Tue, Nov 12, 2019 at 9:24 AM peter green  wrote:
> I am guessing that many of these are to get testsuite coverage for optional 
> features and are not strictly needed for the build, while testing stuff is 
> nice I don't think it's vital for software that is on it's way out. I tried 
> removing all of the aforementioned packages except python-setuptools and 
> python-kiwisolver from the build-depends (and I uninstalled all python 2 
> packages from the chroot where I was doing my test builds before I installed 
> the remaining build-depends).

well, i dont think it's a good reason to just stop testing complex
software tho. some of those dependencies are required so that mpl can
build extensions (in particular for the GUI backends) so if you remove
them, the mpl build system is smart enough to disable those
extensions, resulting in a graphic library without any GUI bindings to
work with. that doesnt sound ideal.

I'm gonna go thru some of the dependencies and will see if i can
remove some, in particular now that i've remored the -doc package from
the git repo, but i'm not gonna get rid the whole unittest suite.

thanks for your work on this, and to nudge me into looking deeper at mpl2 deps

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#944575: calibre cannot find libGLX_mesa.so.0 and fails to launch

[Norbert Preining]

Hi

> $ calibre the_book_of_wisdom_of_solomon.mobi

(btw, ebook-viewer ...mobi is probably better, it starts the viewer)

> libGL error: No matching fbConfigs or visuals found
> libGL error: failed to load driver: swrast
> Unable to read MTPZ public exponent from ~/.mtpz-data, MTPZ disabled.
> qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1271,
> resource id: 15145284, major code: 40 (TranslateCoords), minor code: 0

That is something that is definitely out of the Calibre realm. Something
in your GL setup is wrong. You maybe have installed some external
drivers at some point in the past (nvidia binary drivers?) or changed
something else. I don't really know how to fix these kinds of things
remotely.

> (ebook-convert works, though.)

Yes, it doesn't need Qt library for displaying stuff.

Best

Norbert

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

Bug#944633: Moreutils parallel does not always flush output on single CPU machine

[Mark Blakeney]

Package: moreutils
Version 0.63-1

Running parallel (moreutils) on my normal multi-cpu machines always
(appears) to work fine. However it does not work on any single cpu VPS, e.g
here is a simple example:

bullet:~ cat ./parallel-moreutils-bug
#/bin/bash
parallel-moreutils -j$1 -i sh -c "echo started {}; sleep 1; echo finished
{}" -- $(seq -s' ' $1)
bullet:~ ./parallel-moreutils-bug 2
started 1
started 2
finished 2
bullet:~ ./parallel-moreutils-bug 2
started 2
started 1
finished 2
bullet:~ ./parallel-moreutils-bug 2
started 2
started 1
finished 2
finished 1
bullet:~ nproc
1

Happens on my Arch Linux VPS and also my ubuntu and debian single-cpu VPS
machines with versions 0.60 to 0.63 at least. Works about 40% of the time,
fails about 60%. Doesn't matter what shell I specify in that script.
Specifying an N value higher than the number of cpu's in my multi-cpu
machines does not cause a problem, only on single-cpu as above.

--
Mark Blakeney.

Bug#928287: qutip_4.4.1-1_amd64.changes REJECTED

[Drew Parsons]

On 2019-11-13 03:21, Thorsten Alteholz wrote:


Part of that file is an embedded tex file:
 _qcircuit_latex_min = r"""
 % Q-circuit version 2
 % Copyright (C) 2004 Steve Flammia & Bryan Eastin
 % Last modified on: 9/16/2011
 % License: http://www.gnu.org/licenses/gpl-2.0.html
 % Original file: http://physics.unm.edu/CQuIC/Qcircuit/Qcircuit.tex
 % Modified for QuTiP on: 5/22/2014
 (...)

with a different license.



Ah, I see it.  A second licence for embedded text later in the file.  
Thanks Thorsten, I'll add it.


Drew

Bug#944632: override: color-theme-modern:editors/optional

[Nicholas D Steeves]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

I was not aware that the Emacsen Team had standardised on Section:
editors, moving away from Section: lisp.  This particularly makes
sense for things that affect UI like themes and new modes.

David Bremner notified me after I had uploaded.

A section change would be very much appreciated :-) Also, please let
me know if the use of reportbug's "override" submenu for
ftp.debian.org bugs was appropriate when filing this bug.

Thanks!
Nicholas

Bug#944614: fixed in ibus 1.5.21-2

[Boyuan Yang]

Hi Changwoo,

在 2019-11-13三的 09:13 +0900，Changwoo Ryu写道：
> On Tue, 12 Nov 2019 21:03:50 + Boyuan Yang  wrote:
> 
> >  + Downgrade dependency of ibus-tests -> gnome-shell to
> >recommendation on s390x since gnome-shell currently FTBFS on
> >s390x architecture.
> >This makes ibus able to migrate to testing. (Closes: #944614)
> 
> Does it make a difference? ibus-tests still depends on gnome-session
> which depends on gnome-shell.
> 
> ibus-tests needs GNOME session to work. If it's difficult to fix
> gnome-shell s390x FTBFS, then ibus-tests should be disabled for s390x.

I'd assume it's not a real fix, just a workaround to allow ibus to be able to
migrate to Testing.

It's also reasonable to not to build ibus-tests package on s390x at all, but
that might make debian/rules file more complicated so I didn't do that in this
upload. Let's see if this workaround works first.


-- 
Thanks,
Boyuan Yang


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

Bug#944575: calibre cannot find libGLX_mesa.so.0 and fails to launch

[James Van Zandt]

I haven't knowingly tinkered with OpenGL.  The plugin dependencies look the
same here:

home:/usr/lib/calibre/calibre/plugins $ ldd *|grep GL
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f561f412000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x7f561ec18000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
(0x7f561eb5b000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f1643d5f000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x7f1643548000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
(0x7f164348b000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f9aec677000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x7f9aebe7d000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
(0x7f9aebdc)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f974c9c)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x7f974c1c6000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
(0x7f974c109000)

calibre doesn't launch here unless it can find that library.
On the other hand, even with that library, it prints warnings:

$ calibre the_book_of_wisdom_of_solomon.mobi
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Unable to read MTPZ public exponent from ~/.mtpz-data, MTPZ disabled.
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1271,
resource id: 15145284, major code: 40 (TranslateCoords), minor code: 0

And have not gotten it to actually open an ebook.  So there may be other
things wrong with my setup.

(ebook-convert works, though.)

Bug#935546: debian-cd: advanced and dark-theme boot have unreadable fonts on hidpi displays

[Samuel Thibault]

Samuel Thibault, le ven. 23 août 2019 22:03:23 +0200, a ecrit:
> Steve McIntyre, le ven. 23 août 2019 21:00:19 +0100, a ecrit:
> > Once you've done that, I'll backport it for buster builds too.
> 
> Thanks, I have pushed the fix.

FI, I tested the fix in the stretch branch of debian-installer, it works
fine, so debian-installer can be uploaded for the next point release of
stretch.

Samuel

Bug#944364: dpkg: ldconfig is not invoked for Depends or even Pre-Depends

[Guillem Jover]

Control: reassign -1 python3-augeas
Control: severity -1 serious

Hi!

On Sat, 2019-11-09 at 11:06:15 +0100, Jakub Wilk wrote:
> * Alexander Thomas , 2019-11-08, 15:50:
> > Traceback (most recent call last):
> >  File "/usr/lib/the-package/setup-package.py", line 3, in 
> >from augeas import Augeas
> >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 78, in 
> >class Augeas(object):
> >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 82, in Augeas
> >_libaugeas = _dlopen("augeas")
> >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 75, in _dlopen
> >raise ImportError("Unable to import lib%s!" % args[0])
> > ImportError: Unable to import libaugeas!
> 
> The _dlopen() function uses ctypes.util.find_library(), which is a
> fundamentally broken API. This is the culprit, not dpkg.

Ah, thanks for tracking this down! I was not sure whether the ld caching
logic in glibc might have regressed perhaps.

> > ldconfig is one of the triggers of libc-bin. It seems that its
> > invocation is now postponed too late.
> 
> ldconfig is declared as a noawait trigger, so dpkg is allowed to configure
> the triggering package immediately, without waiting for the trigger to be
> run.
>
> This declaration is correct, because running ldconfig shouldn't have any
> effect on software functionality, unless there's a bug somewhere else.

Exactly. So I guess this needs to be reassigned first to augeas, which
I'm doing now. And perhaps cloned or a new bug filed to python too for
the brokeness in the ctypes.util.find_library() API, but I'd leave that
to you Jakub, as I've not checked any of that.

Thanks,
Guillem

Bug#944631: python3-mpi4py: import sends messages to stderr

[Jameson Graef Rollins]

Package: python3-mpi4py
Version: 3.0.2-13
Severity: normal

A simple import of the MPI subpackage causes a warning message to be
sent to stderr:

servo:~ 0$ python3 -c 'from mpi4py import MPI'
--
[[11193,1],0]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:

Module: OpenFabrics (openib)
  Host: servo

Another transport will be used instead, although this may result in
lower performance.

NOTE: You can disable this warning by setting the MCA parameter
btl_base_warn_component_unused to 0.
--
servo:~ 0$

This is bad form and is causing problems to applications build against
packages using this library (such as h5py).

I'm guessing this is a problem with the underlying libhdf5? but I'm
not sure, and now sure how to track down where the issue is really
coming from.

Thanks.

jamie.


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

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

Versions of packages python3-mpi4py depends on:
ii  libc62.29-3
ii  libopenmpi3  3.1.3-11
ii  mpi-default-bin  1.13
ii  python3  3.7.5-1

python3-mpi4py recommends no packages.

Versions of packages python3-mpi4py suggests:
ii  python3-numpy  1:1.16.5-1

-- no debconf information

Bug#944614: fixed in ibus 1.5.21-2

[Changwoo Ryu]

On Tue, 12 Nov 2019 21:03:50 + Boyuan Yang  wrote:

>  + Downgrade dependency of ibus-tests -> gnome-shell to
>recommendation on s390x since gnome-shell currently FTBFS on
>s390x architecture.
>This makes ibus able to migrate to testing. (Closes: #944614)

Does it make a difference? ibus-tests still depends on gnome-session
which depends on gnome-shell.

ibus-tests needs GNOME session to work. If it's difficult to fix
gnome-shell s390x FTBFS, then ibus-tests should be disabled for s390x.

Bug#939903: possible solution

[Niklas Miller]

Hi,

enabling the lxc nesting feature for the container solved the issue for 
me...

Bug#944630: jumpnbump-levels: suggestions for an update of the packaging

[Nicolas Boulenguez]

Package: jumpnbump-levels
Severity: wishlist
Tags: patch

Hello.

The attached diff contains a trivial update of the packaging for
jumpnbump-levels, based on salsa.debian.org.

The obsolete address in Maintainer field should probably be updated to
something like alioth-lists or lists.debian.org.

I can submit a merge request instead of a patch if you prefer.
From: Nicolas Boulenguez 
Subject: packaging updates for jumpnbump-levels

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+jumpnbump-levels (2019) unstable; urgency=medium
+
+  [ Nicolas Boulenguez  ]
+  * Merge Build-Depends and B-D-Indep, there is only one package.
+  * Debhelper 12. Split decompression and installation.
+  * Update VCS-* to salsa.debian.org.
+  * Drop references to dead original upstream URL.
+  * Standards-Version: 4.4.1.
+  * Rules-Requires-Root: no.
+
+ -- Fabian Greffrath   Tue, 12 Nov 2019 09:16:15 
+0100
+
 jumpnbump-levels (20140925) unstable; urgency=low
 
   [ Evgeni Golov ]
@@ -93,5 +105,3 @@
   * Initial Release.
 
  -- Ivo Timmermans   Wed, 21 Mar 2001 11:37:29 +0100
-
-
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-9
--- a/debian/control
+++ b/debian/control
@@ -4,14 +4,14 @@ Priority: optional
 Maintainer: Debian Games Team 
 Uploaders:
  Fabian Greffrath 
-Build-Depends-Indep:
- bzip2
 Build-Depends:
- debhelper (>= 9)
-Standards-Version: 3.9.5
+ bzip2,
+ debhelper-compat (= 12),
+Standards-Version: 4.4.1
+Rules-Requires-Root: no
 Homepage: https://wiki.debian.org/Games/Jumpnbump
-Vcs-Git: git://anonscm.debian.org/pkg-games/jumpnbump-levels.git
-Vcs-Browser: http://anonscm.debian.org/cgit/pkg-games/jumpnbump-levels.git
+Vcs-Browser: https://salsa.debian.org/games-team/jumpnbump-levels
+Vcs-Git: https://salsa.debian.org/games-team/jumpnbump-levels.git
 
 Package: jumpnbump-levels
 Architecture: all
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,17 +1,19 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Source: http://jumpbump.mine.nu/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 
 Files: *
 Copyright: 1998, Various Authors
 License: GPL-2+
 Comment: These levels were downloaded from http://jumpbump.mine.nu/,
   after a recommendation by Gürkan Sengün .
+  This URL is now down, and the Debian maintainers have taken over
+  maintenance.
 
 Files: debian/*
 Copyright: 2001-2002, Ivo Timmermans 
   2005-2009, Francois Marier 
   2013, Evgeni Golov 
   2014, Fabian Greffrath 
+  2019 Nicolas Boulenguez 
 License: GPL-2+
 
 License: GPL-2+
--- a/debian/dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/share/games/jumpnbump
--- /dev/null
+++ b/debian/jumpnbump-levels.install
@@ -0,0 +1 @@
+*.dat usr/share/games/jumpnbump
--- a/debian/rules
+++ b/debian/rules
@@ -3,8 +3,8 @@
 %:
dh $@
 
-override_dh_auto_install:
-   dh_installdirs --all usr/share/games/jumpnbump
-   for i in *.dat.bz2 ; do \
-   bzip2 -cd $$i > 
debian/jumpnbump-levels/usr/share/games/jumpnbump/$${i%.bz2} ; \
-   done
+override_dh_auto_build:
+   bzip2 -dk *.dat.bz2
+
+override_dh_auto_clean:
+   rm -f *.dat

Bug#914577: fixed in dropwatch 1.5.1-1

[Dmitry Smirnov]

On Wednesday, 13 November 2019 9:09:30 AM AEDT Moritz Mühlenhoff wrote:
> Why did you take over that ITP without even syncing up with the person
> (CCed) who indicated to be working on it in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914577#10 ?

Excuse me, I was taking over "RFP" and there was nothing to sync about as 
there were no publicly visible progress whatsoever.


> https://salsa.debian.org/akosiaris-guest/dropwatch had a package
> waiting for sponsorship/upload.

How am I suppose to know about that? There were no updates to RFP, no 
sponsorship-requests, no uploads to mentors.debian.net (that I'm aware of), 
nothing.

As far as I knew there was nothing to indicate work in progress or even 
proper ownership of an RFP.
Sometimes people comment to RFPs without contributing any work...

Alexandros, you are most welcome to co-maintain this package.
Next time please ensure to re-title the bug properly and keep it updated on 
your progress.

-- 
Cheers,
 Dmitry Smirnov.

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche


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

Bug#943623: Latest llvm10 snapshot still fails with Mesa master

[Shmerl]

On Tue, 12 Nov 2019 18:11:10 +0100 Sylvestre Ledru  wrote:
> > https://github.com/llvm/llvm-project/commit/343597789eba1e6482e130b0c1b0818b1432d311
> This is unrelated.

Thanks for the clarification, I followed one of the links you posted
above, and thought it was related.

> I am aware of the issue. No resend the same content as the bug.
> It was a long week end here and I have a $$$ job.
>
> Don't hesitate to step in to help, this is opensource ;)

Thanks! Do you have any hints about what to experiment with to address
it? I'm quite a loss at what could be the source of this.

Best regards,
Shmerl.

Bug#944571: mmdebstrap: the license is not the actual Expat license

[Francesco Poli]

On Tue, 12 Nov 2019 04:59:52 +0100 Johannes Schauer wrote:

[...]
> Quoting Francesco Poli (wintermute) (2019-11-12 00:03:52)
[...]
> > The disclaimer of warranty and limitation of liability are important
> > (above all, they protect the authors and copyright holders): I would
> > strongly recommend adding them as soon as possible, thus effectively
> > changing the license of mmdebstrap (this can be easily done, as long
> > as there's only one copyright holder).
> 
> the warranty part does not change any of the terms under which the software 
> can
> be used or distributed. Thus I don't think it would need coordination with any
> copyright holder.

But it may change the implied warranty or liability that the copyright
holders are providing.

I think there are (or can be) jurisdictions where some form of "basic"
warranty is implicitly granted, unless explicitly disclaimed.
And perhaps some form of liability is implicitly accepted, unless
explicitly limited.
As far as I can say, that's the reason why most (if not nearly all!)
free software licenses include a disclaimer of warranty and limitation
of liability, in order to protect the authors / copyright holders.

> 
> Furthermore, the Expat License clearly states:
> 
> > The above copyright notice and this permission notice shall be included in
> > all copies or substantial portions of the Software.
> 
> Indeed the *above* notice was kept intact. The expat license says nothing 
> about
> keeping the text intact that follows, namely the warranty part.

I think "this permission notice" could be interpreted as including
the disclaimer of warranty and limitation of liability, hence I still
believe that calling that text "Expat license" may be considered as
incorrect license naming...

> 
> Lastly, the warranty part is not required at all in my jurisdiction.

I assume you mean the German jurisdiction.

I am not familiar enough with German law to know, hence I am asking you:
do you have information that, with no disclaimer of warranty or
limitation of liability, you are *not* implicitly granting some form
of warranty (e.g. that the software is reasonably free of defects)
or implicitly accepting some form of liability (e.g. for damages
arising from the use of the software)?

And anyway, not everybody lives in the same jurisdiction.
Potential contributors could be scared away from contributing patches
under the same license as the one you adopted, because of the lack of
disclaimer of warranty and limitation of liability that may be useful
in their own jurisdictions!

I still recommend that you add that disclaimer of warranty and
limitation of liability to the upstream license, so that it matches
the canonical Expat license text and makes many people more comfortable
with it...

> Are there
> important jurisdictions where the Debian project as a whole cares that it is
> needed?

Most free software licenses include such a disclaimer.
Most free software licenses originated from the USA.
I guess... probably the U.S. jurisdiction?!?;-)
And possibly other jurisdictions, as well...

Please note that I am not especially enthusiast about OSI, but they
have lawyers look into licenses. While talking about
[public domain], they state:

[...]
| open source licenses usually have a strong disclaimer of liability
| for the copyright holder — but we don't know how or whether the author
| would be protected from liability for software released into the
| public domain in various jurisdictions
[...]

[public domain]: 

mmdebstrap is not in the public domain, but lacks any disclaimer of
warranty or limitation of liability, just like public domain software...

> 
> If the Debian project cares about the disclaimer of warranty, then it can just
> easily be added into debian/copyright so that all recipients of the software
> via Debian receive it together with the disclaimer. As I explained above, I
> don't think that this requires a change of the upstream license.

I don't think that would work... Debian Policy (section 2.3) insists
that the debian/copyright file include a verbatim copy of the upstream
license: adding a disclaimer not present in the upstream license
would be really confusing (if not a plain Debian Policy violation).
Do you agree?




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


pgpN3Ii3VjYq7.pgp
Description: PGP signature

Bug#879130: choose-mirror: empty mirror list on non released architectures

[Samuel Thibault]

Hello,

I have significantly reworked and simplified the patch:

- avoid creating several files at the same time
- always create usr/lib/choose-mirror/port_architecture to make rules
  much simpler.
- use a single variable $archive that normally contains 'archive' but
  can be set to 'ports'.

so that we end up only doing this in mirrorlist:

- set $archive to 'archive' by default
- loop for the architecture in a Ports-architecture field, if so set
  $archive to 'ports'.
- replace 'archive' with $archive in the strings.
- create the port_architecture containing either 0 or 1 when requested to

I tried to build with on amd64 and on hurd-i386, I am getting the expected 
results:
- /usr/lib/choose-mirror/port_architecture contains 0 on amd64 and 1 on
hurd-i386.
- The choose-mirror binary contains the full mirror list on amd64, it
contains only deb.debian.org on hurd-i386.

Does anybody think of anything else I should check before I commit this?

Samuel
diff --git a/Makefile b/Makefile
index b4a7ecc..e10c167 100644
--- a/Makefile
+++ b/Makefile
@@ -86,7 +86,10 @@ debian/httpslist-countries: $(MASTERLIST) debian/iso_3166.tab
 debian/ftplist-countries: $(MASTERLIST) debian/iso_3166.tab
./mirrorlist ftplist $^
 
-debian/choose-mirror-bin.templates: $(MASTERLIST) $(templates) 
debian/httplist-countries debian/httpslist-countries debian/ftplist-countries 
debian/iso_3166.tab
+debian/port_architecture: $(MASTERLIST) debian/iso_3166.tab
+   ./mirrorlist port_architecture $^
+
+debian/choose-mirror-bin.templates: $(MASTERLIST) $(templates) 
debian/httplist-countries debian/httpslist-countries debian/ftplist-countries 
debian/iso_3166.tab debian/port_architecture
# Grab ISO codes from iso-codes package
./get-iso-codes
# Build the templates
@@ -132,6 +135,7 @@ clean:
rm -f demo demo.templates
rm -rf debian/iso-codes/ debian/pobuild*/
rm -f debian/iso_3166.tab
+   rm -f debian/port_architecture
 
 reallyclean: clean
rm -f debian/choose-mirror-bin.templates
diff --git a/debian/choose-mirror-bin.install b/debian/choose-mirror-bin.install
index 7a92821..568306a 100644
--- a/debian/choose-mirror-bin.install
+++ b/debian/choose-mirror-bin.install
@@ -1 +1,2 @@
 choose-mirror bin
+debian/port_architecture usr/lib/choose-mirror
diff --git a/mirrorlist b/mirrorlist
index 0a811b2..f55e315 100755
--- a/mirrorlist
+++ b/mirrorlist
@@ -104,12 +104,28 @@ foreach my $id (0..$#data) {
$data[$id]->{rating}=$rating;
 }
 
+# Defaults for released architectures
+my $archive = 'archive';
+
+# Is $hostarch a port architecture ?
+# Such architectures appear in a Ports-architecture: field
+foreach my $id (0..$#data) {
+   if (exists $data[$id]->{'ports-architecture'}) {
+   my @arches = split ' ', $data[$id]->{'ports-architecture'};
+   my %arches = map { $_ => 1 } @arches;
+   if (exists $arches{$hostarch} or exists $arches{'!'.$hostarch}) 
{
+   $archive = 'ports';
+   last;
+   }
+   }
+}
+
 # Filter out mirrors that don't carry the target architecture.
 my @newdata;
 foreach my $id (0..$#data) {
-   if (exists $data[$id]->{'archive-architecture'} &&
-   $data[$id]->{'archive-architecture'} ne "any") {
-   my @arches = split ' ', $data[$id]->{'archive-architecture'};
+   if (exists $data[$id]->{"$archive-architecture"} &&
+   $data[$id]->{"$archive-architecture"} ne "any") {
+   my @arches = split ' ', $data[$id]->{"$archive-architecture"};
if (grep /^!/, @arches) {
my %notarches = map { substr($_, 1) => 1 } grep /^!/, 
@arches;
next if exists $notarches{$hostarch};
@@ -126,7 +142,7 @@ if ($type =~ /(.*)list/) {
my $type=$1;
open (LIST, ">debian/${type}list-countries") or die 
"debian/${type}list-countries: $!";
foreach my $id (0..$#data) {
-   next unless exists $data[$id]->{"archive-$type"} and
+   next unless exists $data[$id]->{"$archive-$type"} and
exists $data[$id]->{country};
my $cc = $data[$id]->{country};
die "Error: country code '$cc' does not occur in iso-3166 table"
@@ -138,6 +154,15 @@ if ($type =~ /(.*)list/) {
}
close LIST;
 }
+elsif ($type eq "port_architecture") {
+   open(OUT,"> debian/port_architecture") || die "Unable to write 
debian/port_architecture\n";
+   if ($archive eq 'ports') {
+   print OUT "1\n";
+   } else {
+   print OUT "0\n";
+   }
+   close OUT;
+}
 else {
open (OUT, ">mirrors_$type.h") or die "mirrors_$type.h: $!";
print OUT "/* Automatically generated; do not edit. */\n";
@@ -154,13 +179,13 @@ else {
else {
$cc=$q.$data[$id]->{country}.$q;
}
-   next unless exists 

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[gregor herrmann]

On Tue, 12 Nov 2019 23:55:09 +0100, Michael Biebl wrote:

> I'll prepare an upload soonish given your feedback.

Thank you - much appreciated.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Element of Crime: Black and White


signature.asc
Description: Digital Signature

Bug#944612: Additional Log Files

[Alexander Dahl]

Here the promised console logs. Hope that helps.

Greets
Alex

P.S.: sorry I messed up my initial From: address, please use this one.
[251782.115527] [ cut here ]
[251782.115569] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[251782.115622] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x20d/0x220
[251782.115647] Modules linked in: devlink nf_tables nfnetlink xen_netback xen_blkback xen_gntdev xc
[251782.115751]  hid_generic usbhid hid crc32c_intel ahci libahci i2c_i801 lpc_ich firewire_ohci fi]
[251782.115785] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0-5-amd64 #1 Debian 4.19.37-5
[251782.115794] Hardware name: Gigabyte Technology Co., Ltd. H55M-UD2H/H55M-UD2H, BIOS F11 08/20/200
[251782.115807] RIP: e030:dev_watchdog+0x20d/0x220
[251782.115814] Code: 00 49 63 4e e0 eb 92 4c 89 e7 c6 05 31 62 ae 00 01 e8 97 c0 fc ff 89 d9 4c 896
[251782.115833] RSP: e02b:888031e03e98 EFLAGS: 00010282
[251782.115840] RAX:  RBX:  RCX: 0006
[251782.115849] RDX: 0007 RSI: 0001 RDI: 888031e166b0
[251782.115858] RBP: 88800557045c R08: 053e R09: 0720072007200774
[251782.115867] R10: 0775076f07200764 R11: 0765076d07690774 R12: 88800557
[251782.115876] R13:  R14: 888005570480 R15: 0001
[251782.115895] FS:  7f75789c2800() GS:888031e0() knlGS:
[251782.115904] CS:  e033 DS:  ES:  CR0: 80050033
[251782.115912] CR2: 7fff023e4128 CR3: 291a CR4: 0660
[251782.115926] Call Trace:
[251782.115933]  
[251782.115941]  ? pfifo_fast_enqueue+0x110/0x110
[251782.115952]  call_timer_fn+0x2b/0x130
[251782.115959]  run_timer_softirq+0x3d1/0x410
[251782.115967]  ? handle_irq_event_percpu+0x6d/0x80
[251782.115976]  ? handle_percpu_irq+0x40/0x60
[251782.115984]  __do_softirq+0xde/0x2d8
[251782.115993]  irq_exit+0xba/0xc0
[251782.116002]  xen_evtchn_do_upcall+0x2c/0x40
[251782.116012]  xen_do_hypervisor_callback+0x29/0x40
[251782.116019]  
[251782.116026] RIP: e030:xen_hypercall_sched_op+0xa/0x20
[251782.116033] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc ccc
[251782.116051] RSP: e02b:82003e70 EFLAGS: 0246
[251782.116058] RAX:  RBX:  RCX: 810013aa
[251782.116067] RDX: 32d7ebca RSI:  RDI: 0001
[251782.116076] RBP:  R08: 2318fb4b R09: 
[251782.116085] R10: 7ff0 R11: 0246 R12: 
[251782.116094] R13:  R14:  R15: 
[251782.116104]  ? xen_hypercall_sched_op+0xa/0x20
[251782.116113]  ? xen_safe_halt+0xc/0x20
[251782.116120]  ? default_idle+0x1c/0x140
[251782.116127]  ? do_idle+0x1f1/0x280
[251782.116133]  ? cpu_startup_entry+0x6f/0x80
[251782.116141]  ? start_kernel+0x50c/0x52c
[251782.116149]  ? default_get_nmi_reason+0x10/0x10
[251782.116158]  ? xen_start_kernel+0x587/0x592
[251782.116165] ---[ end trace 911e57ed83519137 ]---
[251804.672131] ata10.00: exception Emask 0x0 SAct 0x1f80 SErr 0x0 action 0x6 frozen
[251804.672182] ata10.00: failed command: WRITE FPDMA QUEUED
[251804.672192] ata10.00: cmd 61/10:38:68:99:58/00:00:4e:00:00/40 tag 7 ncq dma 8192 out
[251804.672192]  res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[251804.672209] ata10.00: status: { DRDY }
[251804.672215] ata10.00: failed command: WRITE FPDMA QUEUED
[251804.672223] ata10.00: cmd 61/08:40:90:99:58/00:00:4e:00:00/40 tag 8 ncq dma 4096 out
[251804.672223]  res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[251804.672274] ata10.00: status: { DRDY }
[251804.672280] ata10.00: failed command: WRITE FPDMA QUEUED
[251804.672289] ata10.00: cmd 61/10:48:b0:99:58/00:00:4e:00:00/40 tag 9 ncq dma 8192 out
[251804.672289]  res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[251804.672305] ata10.00: status: { DRDY }
[251804.672311] ata10.00: failed command: WRITE FPDMA QUEUED
[251804.672319] ata10.00: cmd 61/08:50:e8:99:58/00:00:4e:00:00/40 tag 10 ncq dma 4096 out
[251804.672319]  res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[251804.672336] ata10.00: status: { DRDY }
[251804.672342] ata10.00: failed command: WRITE FPDMA QUEUED
[251804.672351] ata10.00: cmd 61/08:58:08:33:5a/00:00:4e:00:00/40 tag 11 ncq dma 4096 out
[251804.672351]  res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[251804.672367] ata10.00: status: { DRDY }
[251804.672373] ata10.00: failed command: WRITE FPDMA QUEUED
[251804.672382] ata10.00: cmd 61/08:60:b8:a7:5c/00:00:4e:00:00/40 tag 12 ncq dma 4096 out
[251804.672382]  res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[251804.672398] ata10.00: status: { DRDY }
[251804.672407] ata10: hard resetting link
[…
[313562.171136] xen-blkback: Scheduled work from 

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[Michael Biebl]

Am 12.11.19 um 19:04 schrieb gregor herrmann:
> On Tue, 12 Nov 2019 18:55:46 +0100, Michael Biebl wrote:
> 
>>> I have now run autopkgtest(-pkg-perl) on 5 packages, that means 15
>>> creations and removals of LVM snapshots, and I haven't encountered
>>> any issues. So yes, this patch looks good.
>> Thanks for testing, gregor and confirming the fix.
> 
> You're welcome.
>  
>> Is this issue causing real problems or mostly a cosmetic/minor problem?
>> I'm asking because I haven't decided yet whether this issue should be RC
>> and prevent testing migration and/or needs a quick follow-up upload to
>> unstable.
> 
> For me it was "real" enough that I downgraded to the version in
> testing yesterday (before seeing Antonio's bug report today which
> saved me the debugging time I had planned to do) because the hanging
> lvremove broke autopkgtests which would have kept me from uploading
> packages. I guess there are other use cases (like Antonio's backup)
> where not being able to remove an LVM snapshot is also more than
> cosmetic. - Just my quick thoughts and no direct answer to your
> RC-ness question :)

thanks again for your feedback, gregor.
I'll prepare an upload soonish given your feedback.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#944629: RFP: libcatalyst-plugin-session-store-redis-perl -- Redis Session store for Catalyst

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libcatalyst-plugin-session-store-redis-perl
  Version : 0.09
  Upstream Author : Thomas Klausner 
* URL : 
https://metacpan.org/release/Catalyst-Plugin-Session-Store-Redis
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Redis Session store for Catalyst

 Catalyst::Plugin::Session::Store::Redis is a session storage plugin
 for Catalyst that uses the Redis (https://redis.io/) key-value database.


This package is useful when wanting to interact via Perl using the
Catalyst framework with a Redis instance.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, Maintainer changed, and
Vcs fields added if appropriate.

Thanks,
Guillem


libcatalyst-plugin-session-store-redis-perl_0.09-1.debian.tar.xz
Description: application/xz

Bug#939571:

[Ant]

What is the timescale for this to go into testing?

cheers

ant



-- 
Sent from my linux system running Debian 11, desktop Trinity R14
This email is plain text, not HTML. Any attachments are either .jpg or .pdf

Bug#944618: duplicate

[Alexander Dahl]

Sorry, I messed up. This is a duplicate of #944612. Please close this one.

Greets
Alex



signature.asc
Description: OpenPGP digital signature

Bug#942106: Adding Python 3.8 as a supported Python3 version

[Matthias Klose]

On 07.11.19 15:08, Matthias Klose wrote:
> This weekend, I am planning to upload python3-defaults, adding python3.8 as a
> supported Python3 version.  This may introduce some churn in unstable until 
> the
> basic binNMUs are available as well.
> 
> Details for the addition can be found at [1], known issues and patches are 
> filed
> [2].  There was no test rebuild in Debian itself, but the addition was made in
> the current Ubuntu development series.  Things look good, and from my point of
> view don't block any unrelated transition work.  python3-defaults will get a 
> RC
> issue to stay in unstable until the packages build-depending on 
> python3-all-dev
> are built, and after doing a test rebuild with the two supported Python3
> versions.  Earlier test rebuilds don't make sense.
> 
> There are a few packages, where the upstream versions used in Ubuntu diverge
> from the ones currently in unstable (not naming those already updated in
> unstable by the DPMT):
> 
>  - hypothesis #942693, not sure if this is really needed,
>    the testsuite stack might be fixed by the new pluggy
>    version as well.
> 
>  - python-xarray #944044. 1.4 is already broken with Python 3.7. For
>    Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing
>    one or two test failures.
> 
>  - Using numpy from experimental, and only building the Python2 numpy
>    packages from the python-numpy source.
> 
>  - Using python-scipy from experimental, building the Python3 packages,
>    and renaming the python-scipy package to python2-scipy, only building
>    the Python2 packages.
> 
>  - matplotlib and pandas don't have Python2 packages in Ubuntu
>    anymore, so I can't tell much what is needed here. Pandas needs
>    a new upstream for 3.8.
> 
> Packages building on top of numpy/scipy/pandas, like the PyAstro stack, 
> continue
> to work with these updates, despite some new test failures.

So this upload didn't happen, but thanks to Rebecca we now have an almost
Python2 free pandas in unstable. And apologies to the science team for the 1-day
delayed NMUs for patsy and scikit-learn.

Now planning the python3-defaults upload for Thursday or Friday.

Matthias

Bug#944275: further information

[RattusSolarus]

Just to clarify the report:

The copyright violation is just with the music contained in the video, 
not the video itself. It is available with an incorrect claim of CC 
licence at https://archive.org/details/MissionImpossibleTheme when it is 
actually copyright by Famous Music LLC, a division of Sony/ATV Music 
Publishing.


At least one case of copyright infringement has been brought - 
https://variety.com/2017/film/news/mission-impossible-theme-shaving-commercial-ideavillage-copyright-1202519677/

Bug#943924: reducing matplotlib2 build-depends.

[Rebecca N. Palmer]

By itself, removing those dependencies reduces the big tangle [0] from 
148 packages to 141, the freed ones being: ipywidgets pyqt5 pep8 
autopep8 xcffib xlwt cairocffi.  (Note that "not in a tangle" means "no 
*circular* dependencies", *not* "leaf / can be removed immediately".)


There may also be more packages that have more than one link into the 
tangle but could have all of those links cut.


This was calculated from the Blocks of py2removal bugs, so only 
considers packages that still have an open py2removal bug, not 
already-removed packages e.g. pandas.


[0] Largest strongly connected component: can't remove any subset 
(except all or none) without breaking at least some of the remaining 
ones.  Previously discussed in 
https://lists.debian.org/debian-python/2019/10/threads.html#00092


The full 148 are: alabaster apipkg automat autopep8 
backports.functools-lru-cache beautifulsoup4 cairocffi chardet 
colorspacious configobj contextlib2 cython dbus-python dot2tex 
entrypoints enum34 execnet fdb freezegun html5lib incremental ipykernel 
ipython ipython-genutils ipywidgets jupyter-client jupyter-core 
keyrings.alt lxml mako matplotlib matplotlib2 mayavi2 mercurial 
more-itertools mpmath nose numexpr numpydoc pep8 pexpect pickleshare 
pillow pycairo pyflakes pyglet pygments pygobject pygobject-2 pygtk 
pyhamcrest pymacs pyopenssl pyqt5 pyrex pytables pytest pytest-expect 
pytest-forked pytest-runner pytest-xdist python-apptools python-apt 
python-atomicwrites python-attrs python-babel python-cffi python-chaco 
python-changelog python-characteristic python-click python-cryptography 
python-cycler python-dateutil python-debian python-docutils 
python-enable python-envisage python-flake8 python-flaky python-funcsigs 
python-future python-genty python-gevent python-greenlet 
python-hypothesis python-importlib-metadata python-iso8601 
python-keyring python-linecache2 python-mccabe python-mock python-mode 
python-numpy python-packaging python-pathlib2 python-pbr python-pip 
python-pluggy python-psutil python-py python-pyface python-pysqlite2 
python-qt4 python-scipy python-secretstorage python-service-identity 
python-setupdocs python-traceback2 python-traits python-traitsui 
python-typing python-tz python-urllib3 python-virtualenv 
python-webencodings python-whoosh python-zipp pyxdg pyyaml pyzmq 
requests rope ropemacs ropemode setuptools-scm sip4 six soupsieve sphinx 
sphinx-gallery sphinx-paramlinks sphinx-rtd-theme 
sphinxcontrib-websupport sqlalchemy sympy tap.py testresources 
texlive-base texlive-extra traitlets twisted unittest2 wcwidth wheel 
xapian-bindings xcffib xlwt

Bug#944512: duplicity: shouldn't be able to create a backup chain with two different passwords

[Michael Terry]

On Tue, Nov 12, 2019, at 17:04, Alexander Zangerl wrote:
> On Tue, 12 Nov 2019 07:46:37 -0500, "Michael Terry" writes:
> >Wait, you mean that you want to back up without even needing the
> >passphrase for the secret gpg key?
> 
> that's precisely it.
> 
> the secret key isn't even present on the machines that the backup runs on,
> just the public key. gpg (on duplicity's behalf) encrypts the data
> to and for the public key in question and thus performs a non-reversible 
> one-way
> transformation as far as that backup machine is concerned.

OK got it. Duplicity might try to decrypt metadata still, if its cache gets 
blown away. But I get the use case.

I don’t suppose you’d object to an update to the patch that at least makes it 
conditional to gpg key scenarios? Disabling the verification check is dangerous 
for other use cases.

I could throw you a patch tomorrow. And it could have the benefit of being 
upstreamable too.

Thanks!

Bug#914577: fixed in dropwatch 1.5.1-1

[Moritz Mühlenhoff]

On Tue, Nov 12, 2019 at 11:02:13AM +, Dmitry Smirnov wrote:
> Maintainer: Dmitry Smirnov 
> Changed-By: Dmitry Smirnov 
> Description:
>  dropwatch  - tool for detecting and diagnosing dropped network packets
> Closes: 914577
> Changes:
>  dropwatch (1.5.1-1) unstable; urgency=medium
>  .
>* Initial release (Closes: #914577).

Why did you take over that ITP without even syncing up with the person (CCed)
who indicated to be working on it in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914577#10 ?

https://salsa.debian.org/akosiaris-guest/dropwatch had a package
waiting for sponsorship/upload.

Cheers,
Moritz

Bug#944512: duplicity: shouldn't be able to create a backup chain with two different passwords

[Alexander Zangerl]

On Tue, 12 Nov 2019 07:46:37 -0500, "Michael Terry" writes:
>Wait, you mean that you want to back up without even needing the
>passphrase for the secret gpg key?

that's precisely it.

the secret key isn't even present on the machines that the backup runs on,
just the public key. gpg (on duplicity's behalf) encrypts the data
to and for the public key in question and thus performs a non-reversible one-way
transformation as far as that backup machine is concerned.

that way you get zero leakage potential on the backup machines (no secret
data whatsoever is present), at the cost of not having cryptographic integrity
assurance (as no signature can be generated w/o some secret key).

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed.
-- Chris "Saundo" Saunderson


signature.asc
Description: Digital Signature

Bug#944628: Drop build dep on monotone

[Moritz Muehlenhoff]

Package: bugs-everywhere
Severity: serious

Hi Antoine,
monotone is getting removed from Debian, can you please drop the build dep
on monotone in bugs-everywhere?

(It seems unused anyway, as test_usage.sh doesn't cover it).

Cheers,
Moritz

Bug#944627: Removal of chromium from testing

[Ivo De Decker]

Hi,

On Tue, Nov 12, 2019 at 09:04:52PM +, Ivo De Decker wrote:
> package: src:chromium
> version: 78.0.3904.97-1
> severity: serious
> tags: ftbfs
> 
> Hi,
> 
> The latest upload of chromium to unstable fails on armhf:
> 
> https://buildd.debian.org/status/package.php?p=chromium

Please note that if the current situation doesn't change, we will be forced to
remove chromium from testing this Friday:

The FTBFS on armhf prevents the migration of chromium to testing. There is a
newer version currently in stable-proposed-updates which will be accepted into
stable during the next point release on saturday. At that point, the version
from stable would be pushed into testing to make sure the version contraints
are ok. That version is built against libvpx5, which isn't available in
testing, so it would be uninstallable. As there would be no point in shipping
a broken version of chromium in testing, it leaves us with no other option
than to remove it from testing before the point release.

Cheers,

Ivo

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

On Sun, 3 Nov 2019 08:19:20 +0900 "ISHIKAWA,chiaki" 
 wrote:

> Hi,
>
> If I am not mistaken, Ubuntu version used on Mozilla's build server
> farms uses rather very old version of sqlite3.
>
>
> > [task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
> > [task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
> > [task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu
>
>
> Maybe I should downgrade to this and then upgrade a bit until local 
test breaks.

>
> From: https://launchpad.net/ubuntu/xenial/+source/sqlite3
>
> Updates
>
> Package versions including new features after the distribution
> release has been made. Updates are usually turned on by default
> after a fresh install.
>
> * sqlite3 3.11.0-1ubuntu1.2
> 
> (main)
>

I downgraded the sqlite to 3.11.0 used in the first release of ubutno 
Xenial Xerus as noted above.


Unfortunately, the indexedDB errors I saw with mozilla Thunderbird test 
suite did not disappear.


This means that something else that changed between late August and 
middle October (quite likely some other packages) may be to blame.


I will continue investigating, but I *think* sqlite3 was not to blame 
for Thunderbird test failures.


Sorry for the noise.

TIA

Chiaki

Bug#944627: chromium: FTBFS on armhf

[Ivo De Decker]

package: src:chromium
version: 78.0.3904.97-1
severity: serious
tags: ftbfs

Hi,

The latest upload of chromium to unstable fails on armhf:

https://buildd.debian.org/status/package.php?p=chromium

Cheers,

Ivo

Bug#944414: SHIFT+ESC conflict's with chromium's task manager binding

[積丹尼 Dan Jacobson]

EB> So. And? Icewm was there first, please carry your complaint to chromium
EB> guys.

Problem is: there are perhaps 100,000 or a million times more chrom(ium)
users. So it would be best to steer clear of their bindings, lest you
keep getting the same bug report from other users.

EB> Or change icewm config (keys file) to avoid this conflict:

EB> KeySysWinMenu="Shift+Esc"

Do you mean in ~/.icewm/preferences if I do just
KeySysWinMenu=
it will now let Shift+Esc pass through to chromium unharmed?
If so, then please mention it as an example of how to unbind a key,
on icewm-preferences man page below the example
   KeySysWinListMenu="Shift+Ctrl+Esc"
Thanks.

Bug#911558: balsa: Balsa can’t read some HTML mails

[G. Milde]

Package: balsa
Version: 2.5.6-2
Followup-For: Bug #911558

Additional info:

After updating to Buster, Balsa does no longer show HTML parts of mails.

If the mail is mulitpart, text+mail, the text is visible.
If the mail is just HTML, there is no text in the main window.

Workaround: The text is visible in the editor window, when clicking "reply".

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

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

Versions of packages balsa depends on:
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libcanberra-gtk3-0  0.30-7
ii  libcanberra00.30-7
ii  libcompfaceg1   1:1.5.2-5+b2
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u1
ii  libgmime-2.6-0  2.6.23+dfsg1-4
ii  libgnutls30 3.6.7-4
ii  libgpgme11  1.12.0-6
ii  libgspell-1-1   1.6.1-2
ii  libgssapi-krb5-21.17-3
ii  libgtk-3-0  3.24.5-1
ii  libgtksourceview-3.0-1  3.24.9-2
ii  libldap-2.4-2   2.4.47+dfsg-3+deb10u1
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libpangocairo-1.0-0 1.42.4-7~deb10u1
ii  libsecret-1-0   0.18.7-1
ii  libsqlite3-03.27.2-3
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libwebkit2gtk-4.0-372.24.3-1~deb10u1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages balsa recommends:
ii  ca-certificates20190110
ii  gpgsm  2.2.12-1+deb10u1
ii  python3-html2text  2018.1.9-1
ii  yelp   3.31.90-1

Bug#944626: diet-ng FTBFS on armhf: gdc: error: unrecognized command line option ‘-main’; did you mean ‘-Wmain’?

[Paul Gevers]

Source: diet-ng
Version: 1.5.0-1
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainer,

You package was rebuild due the libphobos2-ldc-shared87 transition, but it
failed (some time ago) on armhf.

https://buildd.debian.org/status/package.php?p=diet-ng

Tail of log for diet-ng on armhf:

d21: warning: command line option ‘-Wformat=1’ is valid for C/C++/ObjC/ObjC++ 
but not for D
d21: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for D
[16/18] gdc -Itest_diet@exe -I. -I.. -I../source/ -fdiagnostics-color=always -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -funittest -MD -MQ 
'test_diet@exe/source_diet_parser.d.o' -MF 
'test_diet@exe/source_diet_parser.d.o.deps' -o 
'test_diet@exe/source_diet_parser.d.o' -c ../source/diet/parser.d
d21: warning: command line option ‘-Wformat=1’ is valid for C/C++/ObjC/ObjC++ 
but not for D
d21: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for D
[17/18] gdc -Itest_diet@exe -I. -I.. -I../source/ -fdiagnostics-color=always -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -funittest -MD -MQ 'test_diet@exe/source_diet_html.d.o' 
-MF 'test_diet@exe/source_diet_html.d.o.deps' -o 
'test_diet@exe/source_diet_html.d.o' -c ../source/diet/html.d
d21: warning: command line option ‘-Wformat=1’ is valid for C/C++/ObjC/ObjC++ 
but not for D
d21: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for D
[18/18] gdc  -o test_diet 'test_diet@exe/source_diet_defs.d.o' 
'test_diet@exe/source_diet_dom.d.o' 'test_diet@exe/source_diet_html.d.o' 
'test_diet@exe/source_diet_input.d.o' 
'test_diet@exe/source_diet_internal_html.d.o' 
'test_diet@exe/source_diet_internal_string.d.o' 
'test_diet@exe/source_diet_parser.d.o' 'test_diet@exe/source_diet_traits.d.o' 
-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro -main
FAILED: test_diet 
gdc  -o test_diet 'test_diet@exe/source_diet_defs.d.o' 
'test_diet@exe/source_diet_dom.d.o' 'test_diet@exe/source_diet_html.d.o' 
'test_diet@exe/source_diet_input.d.o' 
'test_diet@exe/source_diet_internal_html.d.o' 
'test_diet@exe/source_diet_internal_string.d.o' 
'test_diet@exe/source_diet_parser.d.o' 'test_diet@exe/source_diet_traits.d.o' 
-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro -main
gdc: error: unrecognized command line option ‘-main’; did you mean ‘-Wmain’?
ninja: build stopped: subcommand failed.
dh_auto_build: cd obj-arm-linux-gnueabihf && LC_ALL=C.UTF-8 ninja -j8 -v 
returned exit code 1
make: *** [debian/rules:8: build-arch] Error 255


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

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl3LGAEACgkQnFyZ6wW9
dQqvZAf/eINqgAMxixHxbvRUgtnBK5HjnSlmZYPzoRFLEoguPYT+qcgB79SvYSZ+
ppTiLPCnvc4t9ypBaR0jIuGGHFoFYBwPgLDKyCllLYOLxBzGXLb+/m9oWaD4Dgjk
SsK+LO1DOAkEjUdbmdT5eR3H8XQFCQ4Bc7XR47E27jpHwYKp/Ag3TUrVh//H1h8z
y3IaNa3gbIr1andMRHgChe42xHFHRTpEi4yNDkbMqc7SV/vLJWRSZCbSC58WCQJK
KRsT9feH3SqlhgwFtFcTM3N6I3p6Tvqmb0nGRWHzigiWV9mgOn62NueydkxurzaD
3GNNSC9u64EHKSg/Qwbc3jqXbU1OJA==
=1qQc
-END PGP SIGNATURE-

Bug#944625: Please package next PyMuPDF compatible version

[Bastian Germann]

Package: mupdf
Version: 1.15.0+ds1-1
Severity: normal

The new pymupdf package depends on the .a in libmupdf-dev. It does not
build currently because 1.14.16-1 needs a mupdf 1.14.x. Unfortunately,
upstream PyMuPDF did not publish any version compatible with 1.15.x
but there are 1.16.x versions available.

Please update mupdf to the current 1.16.1 version, which would enable
the pymupdf package to actually build in sid. Your patches 8-10 are
upstream now, some other patches will need a refresh.

Bug#944624: RFS: sysbench/1.0.18+ds-1 -- multi-threaded benchmark tool for database systems

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for "sysbench":

  Package name: sysbench
  Version : 1.0.18+ds-1
  Upstream Author : Alexey Kopytov
  URL : https://github.com/akopytov/sysbench
  License : GPL-2
  Section : misc

It builds a single binary package:
  sysbench - multi-threaded benchmark tool for database systems

Mentors URL:
  https://mentors.debian.net/package/sysbench

Download with dget:
   dget -x 
https://mentors.debian.net/debian/pool/main/s/sysbench/sysbench_1.0.18+ds-1.dsc

Changes since last upload:
  * New upstream release.
  * Control:
+ switch Vcs fields to salsa.d.o.
+ replace build-dep on python-cram with python3-cram.
  (Closes: #943283)
  * Manpage: update to match current options. (Closes: #942369)
  * Copyright:
+ add upstream debian dir to Files-Excluded.
+ bump years for upstream and packaging.
  * Bump Standards-Version to 4.4.1 (from 4.4.0; no further changes).
  * Tests: switch upstream-test to python3-cram.
  * Patches: add 05_use_python3_version_of_cram.


Thank you!


pgp9cCdWqjftm.pgp
Description: OpenPGP digital signature

Bug#944623: qemu: Add support for PSCHANGE_MC_NO feature

[Salvatore Bonaccorso]

Source: qemu
Version: 1:4.1-1
Severity: important
Tags: security upstream
Control: found -1 1:3.1+dfsg-8+deb10u2
Control: found -1 1:3.1+dfsg-8
Control: fixed -1 1:3.1+dfsg-8+deb10u3

Hi Michael

Could you please add on next upload the patch to qemu to support the
PSCHANGE_MC_NO feature? This allows to disable iTLB Multihit
mitigations in nested hypervisors. 

The qemu update was prepared along with the linux update for DSA
4564-1 (DSA 4566-1) but was not yet released.

Regards,
Salvatore
From: Paolo Bonzini 
Subject: target/i386: add PSCHANGE_MC_NO feature

This is required to disable ITLB multihit mitigations in nested
hypervisors.

Signed-off-by: Paolo Bonzini 
---
 target/i386/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index cd71a09b33..1bbba68b5e 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1188,7 +1188,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 .type = MSR_FEATURE_WORD,
 .feat_names = {
 "rdctl-no", "ibrs-all", "rsba", "skip-l1dfl-vmentry",
-"ssb-no", "mds-no", NULL, NULL,
+"ssb-no", "mds-no", "pschange-mc-no", NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
--
2.21.0

Bug#934958: osmalchemy is no longer in testing

[Paul Gevers]

Control: reopen -1

Hi Piotr,

On 07-11-2019 21:39, Piotr Ożarowski wrote:
> osmalchemy is no longer in testing so this bug is not longer valid
> AFAICT

And by closing the bug, osmalchemy was allowed to migrat back into
testing and where it blocks the migration of sqlalchemy once again
(still with the same error).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944622: sloccount: Fails in a non-ASCII directory

[Philipp Marek]

Package: sloccount
Version: 2.26-5.2
Severity: normal

When $CWD contains a non-ASCII character (I had an o", ie. ö),
sloccount fails silently by giving a total of 0 lines.

Files are found initially, but then can't be accumulated correctly or so.


Have a non-directory at the top, so creating directory top_dir
Adding /home/...ö.../ to top_dir
Creating filelist for förderungen
Adding /home/...ö.../ to top_dir
Have a non-directory at the top, so creating directory src_top_dir
Adding /home/...ö.../ to src_top_dir
Adding /home/...ö.../ to src_top_dir
Adding /home/...ö.../ to src_top_dir
Adding /home/...ö.../ to src_top_dir
Adding /home/...ö.../ to src_top_dir
Categorizing files.
Finding a working MD5 command
Found a working MD5 command.
Computing results.

SLOCDirectory   SLOC-by-Language (Sorted)
0   ö.. (none)
0   src_top_dir (none)
0   top_dir (none)
SLOC total is zero, no further analysis performed.



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Versions of packages sloccount depends on:
ii  libc6  2.29-3
ii  perl   5.28.1-6

sloccount recommends no packages.

Versions of packages sloccount suggests:
pn  doc-base  

-- no debconf information

-- 

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

[Graham Inggs]

See also #814451.

Bug#944621: RFS: logrotate/3.15.1-2 -- Log rotation utility

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: logrotate
   Version : 3.15.1-2
   Upstream Author : https://github.com/logrotate/logrotate/issues
 * URL : https://github.com/logrotate/logrotate
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/logrotate
   Section : admin

It builds those binary packages:

  logrotate - Log rotation utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.15.1-2.dsc

The packaging can also be retrieved from:

  https://salsa.debian.org/debian/logrotate/-/tags/debian%2F3.15.1-2

Changes since the last upload:

   * d/control: drop postgresql-common break
   * d/copyright: update for 2019
   * d/salsa-ci.yml: add standard salsa-ci configuration
   * d/tests: add additional small test script
   * d/patches: add testsuite patches to pass reprotest on salsa-ci
   * d/patches: tighten systemd service hardening
   * d/control: bump to std version 4.4.1 (no further changes)
   * d/source/lintian-overrides: ignore package-does-not-install-examples

Regards,
 Christian Göttsche

Bug#784596: HELP DESK ALERT

[IT]

 Your email has not passed the verification / update process. You are expected 
to update their accounts within 5 business days of receiving this notice. 
Failure to comply with this notice within the deadline will risk losing your 
account. CLICK HERE to verify your account

Bug#943312: [Pkg-cmake-team] Bug#943312: cmake: FindMPI.cmake does not work during cross compilation

[Helmut Grohne]

Hi Felix,

On Tue, Nov 12, 2019 at 07:54:41PM +0100, Felix Geyer wrote:
> Thanks for providing a patch. Have you submitted this upstream?

No. I've briefly talked to upstream on irc and figured that they're very
concernced about breaking backwards compatibility. Thus the patch tries
hard not to do that.

> I imagine there isn't anything Debian-specific there?

Correct, but it might make sense to put it to wider testing in Debian
first.

Helmut

Bug#941907: transition: ocaml

[Paul Gevers]

Hi Stéphane,

On 12-11-2019 14:05, Stéphane Glondu wrote:
> Le 04/11/2019 à 13:50, Stéphane Glondu a écrit :
>>> Please go ahead.
>>
>> Started.
> 
> Here is a status update after 8 days.
> 
> Most of the packages have been updated or rebuilt. For the few
> exceptions, bugs have been filed and all of the concerned packages
> (except llvm-toolchain-8) can be removed from testing.

I am not too familiar with the ocaml way of working, but does everything
needs to be rebuild before it can migrate? If so we can remove those
packages once the llvm-toolchain-8 issue is fixed.

> So the main blocker now is llvm-toolchain-8 with #943920.

Thanks for the update. Are you aware of the other migration blockers?
See https://qa.debian.org/excuses.php?package=ocaml

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943312: [Pkg-cmake-team] Bug#943312: cmake: FindMPI.cmake does not work during cross compilation

[Felix Geyer]

Hi Helmut,

On 23.10.19 09:47, Helmut Grohne wrote:

Package: cmake
Version: 3.13.4-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:flann src:hyphy src:liggghts src:sopt

FindMPI.cmake uses compiler wrappers such as mpicc to discover the
relevant compiler and linker flags. During cross compilation, these
compiler wrappers do not work and they will not be supported on Debian.
Beyond breaking cross compilation, you cannot easily combine multiple
compiler wrappers (e.g. ccache/distcc/mpicc). It is best to avoid
compiler wrappers entirely and for MPI, this is well supported as all
major implementations ship pkg-config files since ages. I am asking to
stop using mpicc and switch over to pkg-config.

Unfortunately, FindMPI.cmake exposes MPI_*_COMPILER and a number of
downstreams use these wrappers that cannot be used during cross
compilation. Every downstream that wants to be cross buildable must stop
using them and I've filed a relevant patch for liggghts. Avoiding
MPI_*_COMPILER is easy enough in the majority of cases, because
FindMPI.cmake also provides the relevant flags in via other variables.
Still, we must maintain backwards compatibility and thus continue
supplying MPI_*_COMPILER when it is available (i.e. during native
compilation).

The attached patch thus tries the wrappers first before falling back to
pkg-config. I've tested it with flann, hyphy, liggghts and sopt. Of
these, flann and sopt are fixed by this patch. hyphy and liggghts need
further patches, which are submitted separately. Please consider
applying the attached patch.

Helmut


Thanks for providing a patch. Have you submitted this upstream?
I imagine there isn't anything Debian-specific there?

Cheers,
Felix

Bug#767155: gdm3: Part of the WM selection list goes off-screen and cannot be scrolled in any way

[Fred Dinkler IV]

Hi,

Same problem, still a problem, anyone have a work around or patch?
--

===Sig===
I can be reached on these IM networks:
AOL Instant Messenger: sidusnare
Yahoo Instant Messenger: sidusnare
MSN Messenger: sidusn...@hotmail.com
Internet relay chat: sidusn...@freenode.net
Gadu-Gadu 2597810
Jabber (jabber.org): sidusn...@jabber.org
Google: sidusn...@gmail.com
ICQ: 472188758

<>

Bug#944620: qa.debian.org: build log scanner reports stale data

[Sven Joachim]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: bls

The build log scanner reports stale data for ncurses from the 20190803-1
version[1].  The problems reported there have been fixed[2] in the
20191019-1 upload, yet the tracker keeps complaining.

Either the new ncurses version has not been scanned at all, despite
having been uploaded 19 days ago, or the information has been discarded,
perhaps because blhc produced no output at all for the new packages (as
desired).


1. https://qa.debian.org/bls/packages/n/ncurses.html
2. 
https://salsa.debian.org/debian/ncurses/commit/b63259877ad51c393461e45597335f5c978ed9f4

Bug#938521: Issues to build latest spades

[Andreas Tille]

Hi,

I've updated unicycler in Git.  When running the autopkgtest I get
an issue with spades.  So I went on to spades trying hard to build
its latest version but I was running into:

...
== Running assembler: K21

'dict' object has no attribute 'iteritems'
Traceback (most recent call last):
  File "/build/spades-3.13.1/install_spades/bin/spades.py", line 901, in main
used_K = spades_logic.run_spades(tmp_configs_dir, bin_home, spades_cfg, 
dataset_data, ext_python_modules_home, log)
  File 
"/build/spades-3.13.1/install_spades/../../share/spades/spades_pipeline/spades_logic.py",
 line 334, in run_spades
run_iteration(configs_dir, execution_home, cfg, log, K, None, False)
  File 
"/build/spades-3.13.1/install_spades/../../share/spades/spades_pipeline/spades_logic.py",
 line 217, in run_iteration
for src, target in list(replacements.iteritems()):
AttributeError: 'dict' object has no attribute 'iteritems'


== Error ==  exception caught: 

In case you have troubles running SPAdes, you can write to 
spades.supp...@cab.spbu.ru
or report an issue on our GitHub repository github.com/ablab/spades
Please provide us with params.txt and spades.log files from the output 
directory.
/build/spades-3.13.1/install_spades/bin/spades.py:872: YAMLLoadWarning: calling 
yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. 
Please read https://msg.pyyaml.org/load for full details.
  dataset_data = pyyaml.load(open(corrected_dataset_yaml_filename, 'r'))
make[1]: *** [debian/rules:61: override_dh_auto_test] Error 1



Please note: In commit 54bc9d00e8638f0ab350c620e9b5446f776340e7
I tried to address exactly this issue but failed obviously.

Any help would be really appreciated.

Kind regards

  Andreas.


-- 
http://fam-tille.de

Bug#944619: bitwise: bogus hardcoded dependencies on libncurses5 and libreadline5

[Sven Joachim]

Package: bitwise
Version: 0.40-1
User: ncur...@packages.debian.org
Usertags: hardcoded-dependency

Your package has hardcoded dependencies on libncurses5 and libreadline5
which is Wrong™.  The correct dependencies on libncurses6 and
libreadline8 are obtained via ${shlibs:Depends}, which is right.

Bug#928287: qutip_4.4.1-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Drew,

On Tue, 12 Nov 2019, Drew Parsons wrote:

On 2019-11-12 07:00, Thorsten Alteholz wrote:

please also mention
 qutip-4.4.1/qutip/qip/circuit_latex.py
in your debian/copyright.



Confused. qutip/qip/circuit_latex.py is already mentioned:


yes, sorry, I was a bit terse.

Part of that file is an embedded tex file:
 _qcircuit_latex_min = r"""
 % Q-circuit version 2
 % Copyright (C) 2004 Steve Flammia & Bryan Eastin
 % Last modified on: 9/16/2011
 % License: http://www.gnu.org/licenses/gpl-2.0.html
 % Original file: http://physics.unm.edu/CQuIC/Qcircuit/Qcircuit.tex
 % Modified for QuTiP on: 5/22/2014
 (...)

with a different license.

  Thorsten

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

[Jameson Graef Rollins]

Upstream suggests that debian should *not* compile python3-h5py against
OpenMPI by default, and based on the current performance of the package
in 2.10.0-2 I agree with them:

https://github.com/h5py/h5py/issues/1433#issuecomment-552640391

It's really quite annoying to have this package printing messages to
stderr (not to mention the performance issues mentioned above and in
#944617).

This is a pretty critical package for a lot of scientific applications,
and these new performance and messy output issues are proving to be
quite problematic.

Thanks for the attention.

jamie.

Bug#944617: python3-h5py import performance severely degraded in 2.10.0 release (due to OpenMPI?)

[Jameson Graef Rollins]

Package: python3-h5py
Version: 2.10.0-2
Severity: normal

This was mentioned in a different report (#944192) but I want to give
it it's own report because I think it's serious enough.

I'm finding multiple problems with the latest 2.10.0 release in
unstable, which I think can all be traced to this new release being
compiled against the OpenMPI library.  I'm no longer sure it's good to
compile against this library by default, since it's degrading the
basic performance too much.

Other than the stderr output on import described in #944192 (and seen
below), the import performance is now x7 slower.  This is a pretty big
drag for any application using this library:

servo:~ 0$ python3 -c 'import h5py; print(h5py.__version__)'
--
[[4525,1],0]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:

Module: OpenFabrics (openib)
  Host: servo

Another transport will be used instead, although this may result in
lower performance.

NOTE: You can disable this warning by setting the MCA parameter
btl_base_warn_component_unused to 0.
--
2.10.0
servo:~ 0$ multitime -qq -n 10 python3 -c 'import h5py'
===> multitime results
1: -qq python3 -c "import h5py"
MeanStd.Dev.Min Median  Max
real0.973   0.027   0.932   0.967   1.022
user0.200   0.017   0.159   0.201   0.221
sys 0.068   0.014   0.034   0.069   0.093
servo:~ 0$


servo:~ 0$ python3 -c 'import h5py; print(h5py.__version__)'
2.8.0
servo:~ 0$ multitime -qq -n 10 python3 -c 'import h5py'
===> multitime results
1: -qq python3 -c "import h5py"
MeanStd.Dev.Min Median  Max
real0.146   0.012   0.118   0.151   0.156
user0.119   0.010   0.103   0.121   0.134
sys 0.027   0.008   0.016   0.027   0.044
servo:~ 0$ 

Most users of h5py are not using the OpenMPI functionality, so I don't
see how it's a win to degrade performance for most users in order to
increase performance for the few.

When I mentioned this issue upstream, their recommendation is that
debian should *not* be building against OpenMPI by default:

https://github.com/h5py/h5py/issues/1433#issuecomment-552640391

I agree with this recommendation.  I think there should be separate
packages providing OpenMPI support (e.g. python3-h5py-openmpi).

Thanks.

jamie.


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

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

Versions of packages python3-h5py depends on:
ii  libc6   2.29-3
ii  libhdf5-openmpi-103 1.10.4+repack-10
ii  python3 3.7.5-1
ii  python3-mpi4py  3.0.2-13
ii  python3-numpy [python3-numpy-abi9]  1:1.16.5-1
ii  python3-six 1.12.0-2

python3-h5py recommends no packages.

Versions of packages python3-h5py suggests:
pn  python-h5py-doc  

-- no debconf information

Bug#886758: fixed in libjsoncpp 1.8.4-1

[Felix Geyer]

Hi Peter,

On Mon, 01 Oct 2018 14:10:30 + Peter Spiess-Knafl  
wrote:

Source: libjsoncpp
Source-Version: 1.8.4-1

We believe that the bug you reported is fixed in the latest version of
libjsoncpp, which is due to be installed in the Debian FTP archive.


A unit test of cmake 3.15 fails because the libjsoncpp version in unstable is 
too old.
It would be great if you could push 1.8.4 to unstable.

Cheers,
Felix

Bug#944191: mutt: Mutt Fails GNU TLS Handshake

[David Engel]

On Sat, Nov 09, 2019 at 05:52:59PM +, Antonio Radici wrote:
> On Tue, Nov 05, 2019 at 10:23:25AM -0600, David Engel wrote:
> > Package: mutt
> > Version: 1.12.2-1
> > Severity: normal
> > 
> > Beginning with version 1.12.2-1, Mutt fails GNU TLS handshake with the
> > following error when connecting to an MS Exchange server:
> > 
> > gnutls_handshake: A packet with illegal or unsupported version was received.
> > 
> > The problem does not exist with Mutt version 1.10.1-2.1.
> > 
> 
> Is this pop3 or imap or smtp?

Imap.

> Could you include the muttdebug file which is obtained by using the debug 
> option
> with mutt? be aware that your personal information (including password) might 
> be
> there, so please remove that before attaching it to the bug.

.muttdebug0 from running with -d2 is attached.  It doesn't appear to
be of much help.

David
-- 
David Engel
Intrusion, Inc.
den...@intrusion.com
[2019-11-12 12:09:15] Mutt/1.12.2 (2019-09-21) debugging at level 2
[2019-11-12 12:09:15] In mutt_reflow_windows
[2019-11-12 12:09:15] In mutt_reflow_windows
[2019-11-12 12:09:15] In mutt_reflow_windows
[2019-11-12 12:09:15] In mutt_reflow_windows
[2019-11-12 12:09:15] Reading configuration file '/etc/Muttrc'.
[2019-11-12 12:09:15] Reading configuration file 
'/usr/lib/mutt/source-muttrc.d|'.
[2019-11-12 12:09:15] Reading configuration file '/etc/Muttrc.d/charset.rc'.
[2019-11-12 12:09:15] Reading configuration file '/etc/Muttrc.d/colors.rc'.
[2019-11-12 12:09:15] Reading configuration file 
'/etc/Muttrc.d/compressed-folders.rc'.
[2019-11-12 12:09:15] Reading configuration file '/etc/Muttrc.d/gpg.rc'.
[2019-11-12 12:09:15] Reading configuration file '/etc/Muttrc.d/htmail-view.rc'.
[2019-11-12 12:09:15] Reading configuration file '/etc/Muttrc.d/smime.rc'.
[2019-11-12 12:09:15] Reading configuration file '/home/david/.mutt/muttrc'.
[2019-11-12 12:09:15] In mutt_reflow_windows
[2019-11-12 12:09:15] Reading configuration file '/home/david/.aliases'.
[2019-11-12 12:09:15] Reading imaps://den...@supernova.intrusion.com/...
[2019-11-12 12:09:15] Looking up supernova.intrusion.com...
[2019-11-12 12:09:15] Connecting to supernova.intrusion.com...
[2019-11-12 12:09:15] gnutls_handshake: A packet with illegal or unsupported 
version was received.
[2019-11-12 12:09:17] Connected to supernova.intrusion.com:993 on fd=4
[2019-11-12 12:09:19] Closing connection to supernova.intrusion.com...
[2019-11-12 12:09:19] 4> a LOGOUT
[2019-11-12 12:09:19] Error: no TLS socket open
[2019-11-12 12:09:21] mutt_socket_write: error writing (No such file or 
directory), closing socket
[2019-11-12 12:09:21] mutt_socket_readchar: attempt to read from closed 
connection.
[2019-11-12 12:09:21] imap_cmd_step: Error reading server response.
[2019-11-12 12:09:21] mutt_socket_close: Attempt to close closed connection.
[2019-11-12 12:09:21] mutt_buffer_pool_free: 5 of 5 returned to pool

Bug#943327: mmdebstrap: Please support using pixz

[Benjamin Drung]

tags 943327 patch
thanks

On Wed, 23 Oct 2019 15:52:26 +0200 Benjamin Drung <
benjamin.dr...@cloud.ionos.com> wrote:
> Am Mittwoch, den 23.10.2019, 14:56 +0200 schrieb Johannes Schauer:
> > Hi,
> > 
> > Quoting Benjamin Drung (2019-10-23 14:14:15)
> > > one of mmdebstrap benefits over deboostrap is that it is
> > > faster.  Creating a
> > > xz tarball as output will take a lot of time, since xz consumes a
> > > lot of
> > > compute power and tar uses only one core.
> > > 
> > > pixz is a pallalel version of xz that can speedup the compression a
> > > lot.
> > > It can be simply used by tar by specifying -Ipixz.
> > > 
> > > So please support using pixz when creating xz tarballs, maybe even
> > > as default
> > > if pixz can be found.
> > 
> > I never heard of pixz. Is it still actively developed? I see that the
> > last
> > release is already four years old and in Debian we have the same
> > version since
> > oldstable. I just don't want to add code to support unmaintained or
> > rarely used
> > software.
> 
> I wasn't aware that pixz hasn't have a lot of development recently, but
> I do not see any signs that it is dead. It look like it is being
> feature complete and under maintenance now.
> 
> > Currently, mmdebstrap supports all compression file endings supported
> > by tar
> > and tar currently does not know about pixz. Is there a reason why tar
> > maintainers thought they don't add that compressor to their list?
> 
> This question triggered me to search the web and I found out, that xz
> gained support for parallel compression files (only compressing, but
> not decompressing):
> 
> $ time tar -J -cf root1.tar.xz -C root .
> real5m19,349s
> user5m19,775s
> sys 0m4,185s
> 
> $ time tar -Ipixz -cf root2.tar.xz -C root .
> real0m59,250s
> user10m23,438s
> sys 0m3,734s
> 
> $ time tar -I"xz -T 0" -cf root3.tar.xz -C root .
> real1m0,764s
> user10m43,783s
> sys 0m3,892s
> 
> So it would be nice if mmdebstrap would use -I"xz -T 0" for compressing
> xz in parallel. This does not require addition dependencies!

Attached a simple patch that adds the -I"xz -T 0" option when using xz
as compression.

-- 
Benjamin Drung

Debian & Ubuntu Developer
Platform Engineering Compute (Enterprise Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler,
Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
From 07e3917529792be9f89083752c5ee887d96d2278 Mon Sep 17 00:00:00 2001
From: Benjamin Drung 
Date: Tue, 12 Nov 2019 19:17:30 +0100
Subject: [PATCH] Use parallel xz compression

One of mmdebstrap benefits over deboostrap is that it is faster.
Creating a xz tarball as output will take a lot of time, since xz
consumes a lot of compute power and tar uses only one core.

Therefore use parallel xz compression since xz supports it using the -T
parameter.

Closes: #943327
Signed-off-by: Benjamin Drung 
---
 mmdebstrap | 5 +
 1 file changed, 5 insertions(+)

diff --git a/mmdebstrap b/mmdebstrap
index c8dbbe5..ae8b397 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -2395,6 +2395,11 @@ sub main() {
 my $exitstatus = 0;
 my @taropts = ('--sort=name', "--mtime=\@$mtime", '--clamp-mtime', '--numeric-owner', '--one-file-system', '-c', '--exclude=./dev');
 
+# Use parallel xz compression
+if (get_tar_compressor($options->{target}) eq 'xz') {
+	push @taropts, "-Ixz -T 0"
+}
+
 # disable signals so that we can fork and change behaviour of the signal
 # handler in the parent and child without getting interrupted
 my $sigset = POSIX::SigSet->new(SIGINT, SIGHUP, SIGPIPE, SIGTERM);
-- 
2.20.1

Bug#944616: emacs: FTBFS on mips64el, mipsel

[Ivo De Decker]

package: src:emacs
version: 1:26.3+1-1
severity: serious
tags: ftbfs

Hi,

The latest upload of emacs to unstable fails on mips64el, mipsel:

https://buildd.debian.org/status/package.php?p=emacs

Cheers,

Ivo

Bug#883804: vmdk-stream-converter: Python2 removal in sid/bullseye

[Balint Reczey]

Control: tags -1 pending

Hi,

I've uploaded a fixed package to DELAYED/10.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[gregor herrmann]

On Tue, 12 Nov 2019 18:55:46 +0100, Michael Biebl wrote:

> > I have now run autopkgtest(-pkg-perl) on 5 packages, that means 15
> > creations and removals of LVM snapshots, and I haven't encountered
> > any issues. So yes, this patch looks good.
> Thanks for testing, gregor and confirming the fix.

You're welcome.
 
> Is this issue causing real problems or mostly a cosmetic/minor problem?
> I'm asking because I haven't decided yet whether this issue should be RC
> and prevent testing migration and/or needs a quick follow-up upload to
> unstable.

For me it was "real" enough that I downgraded to the version in
testing yesterday (before seeing Antonio's bug report today which
saved me the debugging time I had planned to do) because the hanging
lvremove broke autopkgtests which would have kept me from uploading
packages. I guess there are other use cases (like Antonio's backup)
where not being able to remove an LVM snapshot is also more than
cosmetic. - Just my quick thoughts and no direct answer to your
RC-ness question :)


Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Janis Joplin: Kozmic Blues


signature.asc
Description: Digital Signature

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[Michael Biebl]

Am 12.11.19 um 18:07 schrieb gregor herrmann:

> Anyway, back to the lvremove issue; I have a few packages to upload
> anyway, so I can test autopkgtest with schroot and LVM snapshots in
> production :)
> 
> I have now run autopkgtest(-pkg-perl) on 5 packages, that means 15
> creations and removals of LVM snapshots, and I haven't encountered
> any issues. So yes, this patch looks good.

Thanks for testing, gregor and confirming the fix.

Is this issue causing real problems or mostly a cosmetic/minor problem?
I'm asking because I haven't decided yet whether this issue should be RC
and prevent testing migration and/or needs a quick follow-up upload to
unstable.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#944615: pam-python: please do a source-only upload

[Ivo De Decker]

package: pam-python
version: 1.0.7-1
severity: important

Hi,

The latest upload of pam-python contains maintainer binaries, which blocks the
transition to testing. Please do a source-only upload to allow the migration.

Thanks!

Ivo

Bug#944614: ibus-tests depends on gnome-shell, which is unavailable on s390x

[Ivo De Decker]

package: ibus-tests
version: 1.5.21-1
severity: serious

Hi,

The latest version of ibus doesn't migrate to testing, because ibus-tests
depends on gnome-shell, which isn't available on s390x. Either the dependency
should be removed (if it can be), or the package shouldn't be built on s390x.

Thanks,

Ivo

Bug#943623: Latest llvm10 snapshot still fails with Mesa master

[Sylvestre Ledru]

Hello,

Le 12/11/2019 à 17:44, Shmerl a écrit :

To follow up.

According to https://bugs.llvm.org/show_bug.cgi?id=43722#c5, the issue
was fixed 5 days ago in
https://github.com/llvm/llvm-project/commit/343597789eba1e6482e130b0c1b0818b1432d311

This is unrelated.



But latest snapshot from
http://apt.llvm.org/unstable/pool/main/l/llvm-toolchain-snapshot/
(from 2019-11-11), still fails to work with Mesa master / gcc 9 like
this:

/usr/bin/ld: /usr/lib/llvm-10/lib/libLLVMAMDGPUDisassembler.a: error
adding symbols: archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status

Is there something still missing?

I am aware of the issue. No resend the same content as the bug.
It was a long week end here and I have a $$$ job.

Don't hesitate to step in to help, this is opensource ;)

Sylvestre

Bug#944613: golang-testify: New upstream release (1.4.0)

[Andreas Henriksson]

Package: golang-github-stretchr-testify-dev
Version: 1.3.0+ds-1
Severity: wishlist

Dear Maintainer,

Please consider updating this package to the latest upstream release
(1.4.0).

I'm currently looking into possibly packaging something which uses the
`require.Greater` function that was introduced between 1.3.0 and 1.4.0
in https://github.com/stretchr/testify/commit/34c6fa2dc70986bccbbffcc613

Regards,
Andreas Henriksson

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[gregor herrmann]

On Tue, 12 Nov 2019 14:50:51 +0100, Michael Biebl wrote:

> > and a associated PR
> > https://github.com/systemd/systemd/pull/13984
> > Could you test if that patch helps?
> We already have one confirmation (upstream) that this PR helps, but it's
> always better to have explicit confirmation

Thanks for looking into this issue so quickly and for finding this
pull request!

I've now rebuilt systemd with the pull request as an additional
quilt patch, and installed udev and libudev1.


/*
One interesting phenomenon which I also saw yesterday with 243-5 is
that "udevadm trigger" has less output (sdc is an external USB
harddrive with luks+lvm on it).

With 242-8:

# udevadm trigger --settle --verbose --action=add /dev/sdc
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc/sdc1
settle /sys/devices/virtual/block/dm-5
settle /sys/devices/virtual/block/dm-6
settle /sys/devices/virtual/block/dm-7
settle /sys/devices/virtual/block/dm-2
settle /sys/devices/virtual/block/dm-1
settle /sys/devices/virtual/block/dm-3
settle 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc
settle /sys/devices/virtual/block/dm-5
settle /sys/devices/virtual/block/dm-6
settle /sys/devices/virtual/block/dm-7
settle /sys/devices/virtual/block/dm-1
settle /sys/devices/virtual/block/dm-2
settle /sys/devices/virtual/block/dm-3
settle 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc/sdc1

With 243-5 with or without the patch:

# udevadm trigger --settle --verbose --action=add /dev/sdc
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc/sdc1
settle 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc
settle 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/host5/target5:0:0/5:0:0:0/block/sdc/sdc1

(No idea if the missing block/dm-X lines are relevant …)
*/


Anyway, back to the lvremove issue; I have a few packages to upload
anyway, so I can test autopkgtest with schroot and LVM snapshots in
production :)

I have now run autopkgtest(-pkg-perl) on 5 packages, that means 15
creations and removals of LVM snapshots, and I haven't encountered
any issues. So yes, this patch looks good.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Janis Joplin: Kozmic Blues


signature.asc
Description: Digital Signature

Bug#944612: linux-image-5.2.0-3-amd64: netdev watchdog triggers on xen with different nics leading to different failures

[Alexander Dahl]

Package: src:linux
Version: 5.2.17-1
Severity: important

Dear Maintainer,

my computer crashes after random times of running (few hours to
several days) with kernels from Debian 8, 9, or 10 (but not 7) when
running as xen dom0, always with netdev watchdog timeout on transmit
queue.

It is a home server running debian since 2009, rock solid until Debian
7 with kernel 3.16.x, random crashes with kernels 4.9, 4.19, and 5.2,
always with xen. Different network adapters, different actual failures
afterwards. Sometimes only the network adapter resets, sometimes sata
devices fail, but operate normal again after reboot. memtest does not
show any errors.

Usually I have to reboot this host and restart the virtual machines
running on it. I dist-upgraded from Debian 7 to 8, and collected
console output over the last year for Debian 9 and (not yet released)
with different kernel versions. The first line of the log after "cut
here" is always the same (although with different network adapters):

  NETDEV WATCHDOG: *** (***): transmit queue 0 timed out

The call trace always shows things like xen and irq, e.g.:

[19565.293440] [ cut here ]
[19565.293599] NETDEV WATCHDOG: enp1s0 (e1000e): transmit queue 0 timed out
[19565.293627] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:448 
dev_watchdog+0x253/0x260
[19565.293637] Modules linked in: nf_tables nfnetlink xen_netback xen_blkback 
xen_gntdev xen_evtchn xenfs xen_privcmd crypto_simd cryptd glue_helper 
aes_x86_64 e
[19565.293675]  usb_common
[19565.293755] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-3-amd64 #1 
Debian 5.2.17-1
[19565.293764] Hardware name: Gigabyte Technology Co., Ltd. 
H55M-UD2H/H55M-UD2H, BIOS F11 08/20/2010
[19565.293775] RIP: e030:dev_watchdog+0x253/0x260
[19565.293782] Code: 48 85 c0 75 e4 eb 9d 4c 89 ef c6 05 07 a6 aa 00 01 e8 11 
3f fb ff 89 d9 4c 89 ee 48 c7 c7 70 31 f0 81 48 89 c2 e8 57 da a2 ff <0f> 0b e9 
7c6
[19565.293800] RSP: e02b:c90040003e90 EFLAGS: 00010286
[19565.293807] RAX:  RBX:  RCX: 0006
[19565.293815] RDX: 0007 RSI: 0001 RDI: 888031e17680
[19565.293823] RBP: 88800550445c R08: 04d1 R09: 072007740775076f
[19565.293831] R10: 072007640765076d R11: 0769077407200730 R12: 88800546f680
[19565.293840] R13: 888005504000 R14: 888005504480 R15: 0001
[19565.293858] FS:  7f0c08afb740() GS:888031e0() 
knlGS:
[19565.293867] CS:  e030 DS:  ES:  CR0: 80050033
[19565.293874] CR2: 7fbdde9ec3e8 CR3: 049f CR4: 0660
[19565.293886] Call Trace:
[19565.293893]  
[19565.293900]  ? pfifo_fast_enqueue+0x140/0x140
[19565.293908]  call_timer_fn+0x2d/0x130
[19565.293914]  run_timer_softirq+0x401/0x440
[19565.293923]  ? handle_irq_event_percpu+0x6d/0x80
[19565.293931]  ? handle_percpu_irq+0x40/0x60
[19565.293939]  __do_softirq+0xde/0x2f7
[19565.293947]  irq_exit+0xab/0xb0
[19565.293956]  xen_evtchn_do_upcall+0x2c/0x40
[19565.293963]  xen_do_hypervisor_callback+0x29/0x40
[19565.293970]  
[19565.293976] RIP: e030:xen_hypercall_sched_op+0xa/0x20
[19565.293983] Code: 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 
c3c
[19565.294000] RSP: e02b:82003e90 EFLAGS: 0246
[19565.294007] RAX:  RBX:  RCX: 810013aa
[19565.294015] RDX: 029058ea RSI:  RDI: 0001
[19565.294023] RBP:  R08: 13f85928 R09: 
[19565.294031] R10: 7ff0 R11: 0246 R12: 
[19565.294039] R13:  R14:  R15: 
[19565.294049]  ? xen_hypercall_sched_op+0xa/0x20
[19565.294058]  ? xen_safe_halt+0xc/0x20
[19565.294065]  ? default_idle+0x1c/0x140
[19565.294073]  ? do_idle+0x1f1/0x280
[19565.294079]  ? cpu_startup_entry+0x19/0x20
[19565.294086]  ? start_kernel+0x4ed/0x50b
[19565.294093]  ? default_get_nmi_reason+0x10/0x10
[19565.294100]  ? xen_start_kernel+0x585/0x58f
[19565.294107] ---[ end trace e694416b458ba149 ]---

Although this is annoying and I considered buying new hardware, I'm
confident this could be solved, if someone assists me. I offer to
test new kernels and could also compile those by myself. I will attach
my logfiles in further responses to this report.

Kind regards
Alex

-- Package-specific info:
** Version:
Linux version 5.2.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-22)) #1 SMP Debian 5.2.17-1 (2019-09-26)

** Command line:
placeholder root=/dev/mapper/heaven-heaven_root64 ro console=tty0 console=hvc0 
memtest 
ip=192.168.243.70::192.168.243.1:255.255.255.0:heaven.internal.home.lespocky.de:enp3s0

** Not tainted

** Kernel log:
[  868.524964] xenbr3: port 2(vif1.0) entered blocking state
[  868.524989] xenbr3: port 2(vif1.0) entered disabled 

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[Antonio]

I tried to compile the package from source but I get some linking errors:

./build-deb/../src/journal/compress.c:101: undefined reference to
`LZ4_compress_default'
/usr/bin/ld: /tmp/user/2000/libsystemd-shared-243.so.7huXnG.ltrans2.ltrans.o:
in function `decompress_stream_lz4':
./build-deb/../src/journal/compress.c:621: undefined reference to
`LZ4F_createDecompressionContext'
...
/usr/bin/ld: /tmp/user/2000/libsystemd-shared-243.so.7huXnG.ltrans2.ltrans.o:
in function `decompress_startswith_lz4':
./build-deb/../src/journal/compress.c:320: undefined reference to
`LZ4_versionNumber'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

However, if you give me the updated packages, I can test if the
problem is solved (before sending it in the repository).

Bug#943623: Latest llvm10 snapshot still fails with Mesa master

[Shmerl]

To follow up.

According to https://bugs.llvm.org/show_bug.cgi?id=43722#c5, the issue
was fixed 5 days ago in
https://github.com/llvm/llvm-project/commit/343597789eba1e6482e130b0c1b0818b1432d311

But latest snapshot from
http://apt.llvm.org/unstable/pool/main/l/llvm-toolchain-snapshot/
(from 2019-11-11), still fails to work with Mesa master / gcc 9 like
this:

/usr/bin/ld: /usr/lib/llvm-10/lib/libLLVMAMDGPUDisassembler.a: error
adding symbols: archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status

Is there something still missing?

Bug#944610: breaking and inconsistent package configuration

[PICCORO McKAY Lenz]

Package: prosody
Version: 0.11.3-1
Severity: important


The configuration file /etc/prosody/prosody.cfg.lua should contain
only global settings.

Per-host configuration files should be placed in /etc/prosody/conf.avail/,
and the active ones should be linked in /etc/prosody/conf.d/

but does not provide right instructions.. neither upstream has
related! wiki Debian does not provide neither!

stupid problems? i thinks so! are important problems

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#944611: backuppc: cannot reload a running daemon

[Jonathan Wiltshire]

Source: backuppc
Version: 3.2.2-2
Severity: important
Tags: patch

The reload block of the init script does not specify a user to
start-stop-daemon. Since the PID file is not owned by root this results
in an error.

Worse, under systemd the unit is then marked failed and cannot be
recovered without restarting the daemon. If a backup or restore is in
progress that can be very disruptive.

Patch attached, making the reload block match the others.


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Index: backuppc-3.3.2/init.d/src/debian-backuppc
===
--- backuppc-3.3.2.orig/init.d/src/debian-backuppc
+++ backuppc-3.3.2/init.d/src/debian-backuppc
@@ -54,7 +54,7 @@ case "$1" in
 ;;
   reload|force-reload)
 echo "Reloading $NAME configuration files"
-start-stop-daemon --stop --pidfile $LOGDIR/BackupPC.pid \
+start-stop-daemon --stop --pidfile $LOGDIR/BackupPC.pid -u $USER \
--signal 1 -x /usr/bin/perl
 ;;
   *)

Bug#944609: tv-fonts should support the new Unicode 13.0 standard Teletext code points

[Alistair Buxton]

Package: tv-fonts
Version: 1.1-9
Severity: wishlist

The tv-fonts package provides fonts for displaying ETS Teletext, which uses
block characters to form graphics. These characters have been accepted for
Unicode 13.0 (not yet released):

https://www.unicode.org/L2/L2019/19025-terminals-prop.pdf

Previously there was a de-facto standard for these characters to be mapped in
to the Unicode private-use region, and this is what tv-fonts does. In order for
the fonts to be compatible with applications using the newer Unicode standard,
the glyphs inside the font need to be re-assigned to different code points.

There are a few considerations for this:

1. The new Unicode standard uses unification so the mapping from old to new
code points is not linear.

2. The new standard does not specify separate code points for separated
mosaics. Instead this is a visual property like "bold" or "underline" to be
indicated by a control code or escape sequence - which is application specific.
This means that the new Unicode standard may not be compatible with all
software using the glyphs.

3. Unicode 13.0 is not released yet. It is possible that the code points may
still change. However we can still look at doing the work.

It is not at all clear to me where the upstream for this package is, or if
there even is one. That is why I am reporting this bug against Debian.

I am willing to do the work on patching the font but I don't know how to get
the result in to Debian.




-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tv-fonts depends on:
ii  xfonts-utils  1:7.7+6

tv-fonts recommends no packages.

tv-fonts suggests no packages.

-- no debconf information

Bug#936745: reducing matplotlib2 build-depends.

[Dmitry Shachnev]

Hi all,

On Tue, Nov 12, 2019 at 02:13:51PM +, peter green wrote:
> matplotlib2 seems to be an important node in the python2 removal/reduction
> problem (and the qt4 removal problem). I have noticed there are a
> substantial number of python module packages that it build-depends on but
> does not depend on.
>
> [...]
>
> What do others with more experience think? Should these build-dependencies
> be removed?

+1 for this idea!

matplotlib2 is currently one of only 4 blockers for python-qt4 removal (and
one of two blockers for removing its Python 2 part).

I wonder if we can also remove python-matplotlib2-doc and related sphinx
build-dependencies. For developers working on software using matplotlib, the
documentation for its latest version (python-matplotlib-doc) should be enough.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#944608: ITP: octave-database -- interface to SQL databases in Octave

[Rafael Laboissière]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissière 

* Package name: octave-database 
 Version : 2.4.4 
 Upstream Author : Olaf Till  
* URL : https://octave.sourceforge.io/database/ 
* License : GPL-3+ 
 Programming Lang: C++, Octave 
 Description : interface to SQL databases in Octave


The database package enables accessing SQL databases from Octave, a 
scientific computation software. Currently, however, this package only 
supports the PostgreSQL database.


This Octave add-on package is part of the Octave-Forge project.

This package will be maintained in the realm of the DOG (Debian Octave 
Group) and is available in the Git repository at Salsa : 
https://salsa.debian.org/pkg-octave-team/octave-database


--
Rafael Laboissière, on behalf of the DOG

Bug#898960: [libpangoft2-1.0-0] Crashes some Java applications in pango_fc_font_key_get_variations

[gisl]

Is it still an option to backport the patch? Applications are still 
crashing...

Thanks
-g

Bug#944607: RFS: extsmail/2.3-1 -- enables the robust sending of e-mail to external commands

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: extsmail
   Version : 2.3-1
   Upstream Author : Laurence Tratt 
 * URL : https://tratt.net/laurie/src/extsmail/
 * License : BSD/MIT
   Section : mail

  It builds this binary package:

extsmail   - enables the robust sending of e-mail to external commands

  The package appears to be lintian-clean

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.3-1.dsc

  Changes since the last upload:

  * New upstream release 2.3.
  * debian/control: Standards-Version: 4.4.1.
  * debian/control: Build-Depends: Update debhelper-compat (= 12).
  * debian/control: Add Rules-Requires-Root: no.
  * debian/patches: Remove.
  * debian/compat: Remove.

  Regards,

--
Olivier



signature.asc
Description: OpenPGP digital signature

Bug#936604: getmail: Python2 removal in sid/bullseye

[Mattia Rizzolo]

On Wed, Nov 13, 2019 at 12:37:27AM +0900, Osamu Aoki wrote:
> Upstream is active and prides to keep python 2.5 compatibility code in
> it ... (Not just 2.7).  I (Osamu Aoki ) and dkg even
> made some effort to support both 2 and 3 but the idea was rejected by
> upstream in 2018.  (Then we both lost motivation since upstream will not
> include such code in near future)
>   https://marc.info/?l=getmail=151542515929707=2
> 
> The upstream is somehow convinced that python2 will be there for some
> time (Year ~2020 and later).
>   https://marc.info/?l=getmail=151542154628352=2

uh. meh.

I haven't looked at the code, but if you made the effort, how improbable
would it be for you to just keep the patches for py3 support yourself in
the packaging for the time being?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#943555: wireguard-dkms: Kernel modules don't build with kernel 5.3.0-1-arm64 on Raspberry Pi3

[Daniel Kahn Gillmor]

On Tue 2019-11-12 09:16:37 +0100, Christian Haul wrote:
> On 11.11.19 15:33, Daniel Kahn Gillmor wrote:
>> control: affects 943555 + dkms
>>
>> On Sun 2019-11-10 18:09:33 +0100, Christian Haul wrote:
>>> On 10.11.19 14:51, Daniel Kahn Gillmor wrote:
 On Sat 2019-10-26 12:51:47 +, Chris. wrote:
>
>> However, that package looks like it's about to be superceded by
>> linux-headers-5.3.0-2-arm64 because of a recent ABI bump to the kernel
>> in unstable.
>>
>> I know this is a lot to ask, but can you take the following steps?
>>
>>  * upgrade your system to linux-image-5.3.0-2-arm64 and reboot into the
>>new kernel
>>  * make sure you have linux-headers-5.3.0-2-arm64 installed
>>  * retry building the various kernel modules that were failing?
>
> Kernel package just arrived. Builds fine. All good - bug can be closed.
>
> Thanks for your patience.

Great!  thanks for your followup here.  This e-mail should close the bug
report.

--dkg


signature.asc
Description: PGP signature

Bug#936604: getmail: Python2 removal in sid/bullseye

[Osamu Aoki]

Hi,

It seems I need to discuss here before adding followings.

| Package: src:getmail
| Version: 5.13-1
| Severity: normal
| Tags: sid bullseye
| User: debian-pyt...@lists.debian.org
| Usertags: py2keep

Upstream is active and prides to keep python 2.5 compatibility code in
it ... (Not just 2.7).  I (Osamu Aoki ) and dkg even
made some effort to support both 2 and 3 but the idea was rejected by
upstream in 2018.  (Then we both lost motivation since upstream will not
include such code in near future)
  https://marc.info/?l=getmail=151542515929707=2

The upstream is somehow convinced that python2 will be there for some
time (Year ~2020 and later).
  https://marc.info/?l=getmail=151542154628352=2
| > Python2 will be EOL after 2020.
| [...]
| > But, if getmail stays as python2 code, many distros have no choice but
| > to drop getmail sometime after 2020.
| 
| Uh, no, they won't.  Python 2 may stop *development*, but it doesn't magically
| stop working in 2020.  I fully expect distros will keep shipping Python 2 for
| years after that, and undoubtedly there will still be lots of Python 2 code
| in the world running in 2030 and later.

The related binary packages are available in 2 binary names (depending on 
release)
 getmail4 (version=4,5) popcon installed ~2000
 getmail  (version=3,5) popcon installed ~1000

https://qa.debian.org/popcon-graph.php?packages=getmail%20getmail4_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1

I think this qualifies for "py2keep".

The next upload of new upstream 5.14 should update dependency etc to
python2 instead of bare python.

If Debian and Fedora demonstrate its python3 removal, I am sure the
upstream may change his thought.  If you have some progress indicator,
that can be used to convince getmail upstream.  I or dkg need a solid
fact to restart conversation with the upstream.

Regards,

Osamu