New upstream version for Mako
Dear Piotr, dear all, mako v1.0.7 (the one currently in sid [1]) is incompatible with Python 3.8 [2]. I prepared an updated version of the package including an update to the latest upstream version and also fixes for the RC bug #944705 [1], and also bugs #936985 (Drop Python 2 support) [4], #917043, 877280, #917044 and #722265. As far as I can understand bug #917045 has been already fixed in the past, so probably it can be closed. The update version can be found on my personal fork on salsa [3]. I know that you are very busy in this period but I hope that Piotr or someone in the DPMT can find the time to review the package and sponsor an upload (I'm not a DD/DM I'm not currently a member of the DPMT). Please let me know If I can do something else to help with mako. [1] https://tracker.debian.org/pkg/mako [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944705 [3] https://salsa.debian.org/a_valentino-guest/mako [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936985 kind regards -- Antonio Valentino
Re: [Python-apps-team] Bug#938682: Future of Trac in Debian
> > if i dont hear anything back withing a week, i'll most likely opening > > those RM bugs, so that we can work on their transitive dependencies. > > Just go ahead. I hope, we can reintroduce Trac in one or two > years, maybe in time for Debian 12 (bookworm), but probably not > for Debian 11 (bullseye). thanks, just filed all those RM bugs. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Future of Trac in Debian
Quoting Sandro Tosi : So Jan 1 arrived, what do you think we should do? i didnt see any progress on the port to python3 upstream; should we start filing RM for trac extensions/plugins and once they are gone, RM src:trac? I don't expect a Python 3 version of Trac before a year from now. Debian, the high speed train, overtakes Trac, the steam train! an initial list of packages for the first pass of RM could be: $ apt-cache search trac- libnet-trac-perl - Perl client library for Trac libtext-trac-perl - module for formatting text with Trac Wiki Style AFAIK, those two are not Python and can use a remote Trac server, so they can stay. All others need to be removed. if i dont hear anything back withing a week, i'll most likely opening those RM bugs, so that we can work on their transitive dependencies. Just go ahead. I hope, we can reintroduce Trac in one or two years, maybe in time for Debian 12 (bookworm), but probably not for Debian 11 (bullseye).
Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00
Control: severity 942941 normal Control: user debian-python@lists.debian.org Control: usertags 942941 + py2keep On Sun, 22 Dec 2019 at 12:36:38 -0500, Sandro Tosi wrote: > # python-dbus-tests is a module and has 0 external rdeps or not in testing > severity 942941 serious I do not consider this to justify a release-critical bug at this stage. src:dbus-python cannot drop its Python 2 support until all of the reverse dependencies of python-dbus have done so (or been removed from testing, but that's unlikely to happen while they include key packages like avahi, jackd2 and pyqt5). As long as python-dbus exists, there is little or no cost to having python-dbus-tests continue to be built by the same source package, and I would be reluctant to have python-dbus exist in the archive without its automated tests also being present. I also don't think it's appropriate to escalate the severity of the Python 2 removal bug for an entire source package just because *one* of its binary packages is a leaf: the criterion should probably be *all* of its Python 2 binary packages being leaf packages. (See also libpython2.7-testsuite in #937569, which seems to have a similar issue.) Thanks, smcv
