Bug#967170: markupsafe: Unversioned Python removal in sid/bullseye

2021-01-24 Thread Jann Haber
fixed -1 1.1.1-1 close -1 thanks Looking at the package, it seems like this bug has been fixed in version 1.1.1-1 - I can find no more references to unversioned python in that version. I marked the bug as fixed. Please re-open if I am mistaken. Best, Jann On Tue, 04 Aug 2020 09:28:33 +

Bug#936268: caldav-tester: Python2 removal in sid/bullseye

2020-10-10 Thread Jann Haber
Control: notfixed -1 caldav-tester/7.0-4 Control: reopen -1 This bug does not seem to be fixed. There is still a dependency on python2. Reopening. On Fri, 30 Aug 2019 07:12:44 + Matthias Klose wrote: > Package: src:caldav-tester > Version: 7.0-3 > Severity: normal > Tags: sid bullseye >

Bug#937085: [Pkg-mozext-maintainers] Bug#937085: mozilla-devscripts: Python2 removal in sid/bullseye

2020-08-31 Thread Jann Haber
steps for mozilla-devscripts? Best Regards, Jann On Sun, 30 Aug 2020 10:45:15 +0200 Jann Haber wrote: > I created an MR on Salsa to drive this a little bit forward. I found in the > output of configure, that it reported python -> no. This is likely the cause > of the python bind

Bug#938345: redland-bindings: Python2 removal in sid/bullseye

2020-08-31 Thread Jann Haber
Control: tags -1 patch I created an MR in Salsa fixing this bug. It replaces the python-librdf package with a python3-librdf package. The package seems to build correctly, however I'm unsure how to test it properly. Maybe first upload to experimental?

Bug#888656: flowcanvas: should this package be removed? (superseded by ganv)

2020-08-30 Thread Jann Haber
Hi all, recently, src:ladish has been removed from testing for other reasons. If there are no other rdeps by now, how about we continue here and remove flowcanvas (at least from testing)? Cheers, Jann On Tue, 11 Sep 2018 03:29:08 +0100 Alessio Treglia wrote: > Hi all, > > On Mon, Sep 10,

Bug#937085: [Pkg-mozext-maintainers] Bug#937085: mozilla-devscripts: Python2 removal in sid/bullseye

2020-08-30 Thread Jann Haber
I created an MR on Salsa to drive this a little bit forward. I found in the output of configure, that it reported python -> no. This is likely the cause of the python bindings missing later. The MR contains a patch to make configure use python3. Then the compilation does not fail anymore. I

Bug#936880: Patch prepared

2020-08-21 Thread Jann Haber
:18:23.0 +0200 +++ libiptcdata-1.0.5/debian/changelog 2020-08-20 16:36:58.0 +0200 @@ -1,3 +1,10 @@ +libiptcdata (1.0.5-2.3) unstable; urgency=medium + + * Non-maintainer upload. + * Drop binary package python-iptcdata. Closes: #936880. + + -- Jann Haber Thu, 20 Aug 2020 16:36:58

Bug#936880: Bug#966753: fixed in libiptcdata 1.0.5-2.2

2020-08-17 Thread Jann Haber
The package still depends on python2, so this bug is not yet fixed.

Bug#968079: [Python-modules-team] Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

2020-08-17 Thread Jann Haber
Wouldn't the easiest fix for this bug and also #937062, #966763 and #967043 be to just drop the binary package libapache2-mod-wsgi and only keeping the py3 version around? There seem to be no more rdeps in testing, so no other packages are blocking the removal (right?). This would help the

Bug#937665: Waiting for Python 2-depending reverse dependencies

2020-08-17 Thread Jann Haber
On 8/17/20 12:50 AM, Ben Finney wrote: > Control: forcemerge -1 967200 > Control: block -1 by 933750 > Control: outlook -1 0 > > The updated package is ready, and waiting for reverse-dependencies (as > described in bug reports blocking this one) to drop Python 2 support. > &

Bug#937665: fixed in python-coverage 4.5.2+dfsg.1-2

2020-08-16 Thread Jann Haber
It seems like, there are no more rdeps of python-coverage now. Not sure about pypy-coverage. Dropping python-coverage would also fix #967200, which currently blocks migration to testing. :) On Mon, 11 Nov 2019 05:48:22 +1100 Ben Finney wrote: > Control: reopen -1 > Control: tags -1 + pending >

Bug#937314: Removed python2 from b-ds

2020-05-17 Thread Jann Haber
I think I fixed this bug, by simply removing the python-all and python-setuptools from the b-ds. These seem to be unused anyway. Created an MR in Salsa: https://salsa.debian.org/lavamind/powerline-gitstatus/-/merge_requests/4

Bug#936562: fritzing-parts: Python2 removal in sid/bullseye

2020-05-08 Thread Jann Haber
It seems like, the build process is currently using python2 and the test is using python3. In the dependencies of the binary package fritzing-parts, it states ${python:Depends}, but after building there is no dependency on python2 - seems like, this is not needed. Exchanging python2 with

Bug#938248: python-versuchung: Python2 removal in sid/bullseye

2020-05-03 Thread Jann Haber
suchung-1.3.3/debian/changelog --- python-versuchung-1.1/debian/changelog 2014-11-02 23:29:07.0 +0100 +++ python-versuchung-1.3.3/debian/changelog 2020-05-03 10:27:25.00000 +0200 @@ -1,3 +1,11 @@ +python-versuchung (1.3.3-1) UNRELEASED; urgency=medium + + * Non-Maintainer Upload + * Up

Bug#839667: Addition to the bug report

2016-10-07 Thread Jann Haber
It sounds exactly like the bug described here for Kernel 4.1.28: http://lkml.iu.edu/hypermail/linux/kernel/1607.1/05446.html Is it possible, that this bug has been backported to the current Debian stable kernel?

Bug#839667: linux-image-3.16.0-4-amd64: Soft Lockup CPU stuck for xxs on iptables-restore

2016-10-03 Thread Jann Haber
Package: src:linux Version: 3.16.36-1+deb8u1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? - Kernel Update from 3.16.7-ckt25-2+deb8u3 to 3.16.36-1+deb8u1 ... downgrade makes the bug