Processing of python-softlayer_5.9.8-1_source.changes
python-softlayer_5.9.8-1_source.changes uploaded successfully to localhost along with the files: python-softlayer_5.9.8-1.dsc python-softlayer_5.9.8.orig.tar.gz python-softlayer_5.9.8-1.debian.tar.xz python-softlayer_5.9.8-1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
python-softlayer_5.9.8-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 04 Feb 2022 10:24:57 + Source: python-softlayer Architecture: source Version: 5.9.8-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Team Changed-By: Ana Custura Changes: python-softlayer (5.9.8-1) unstable; urgency=medium . [ Ondřej Nový ] * Bump Standards-Version to 4.4.1. . [ Ana Custura ] * New upstream version 5.9.8 * Refresh patch for new version * Upate debian/control fields with Python Team details * Bump debhelper-compat version to 13 * Add Rules-Requires-Root: no to debian/control Checksums-Sha1: f33dfa719f400a306d7bf5580639b2fc689c808b 2173 python-softlayer_5.9.8-1.dsc b72b3ccfebc853da488c2240667a5fd3a0e34213 489563 python-softlayer_5.9.8.orig.tar.gz 5aabdce93e734f252ec3142f57dfc20b44407612 4452 python-softlayer_5.9.8-1.debian.tar.xz 434f297613a3273f1e3d255c14959021c9cb564b 6697 python-softlayer_5.9.8-1_amd64.buildinfo Checksums-Sha256: 5420c0a9b0556f80c1063f59196bebad4cb24f42a4d27bc5bfb00c6e54aa8474 2173 python-softlayer_5.9.8-1.dsc 4231e6629eaffdd9adf7fc1076e30bd0580232a068f3963e73dec88cabb06ee5 489563 python-softlayer_5.9.8.orig.tar.gz 9fcfc6d350f8d9ec27dc0b1a4be9b87a9cc642fcdd96316774b08a6f5ff1adc7 4452 python-softlayer_5.9.8-1.debian.tar.xz b6603b760026534a33fc02371b3eea31cd90cb075923d9b27916f1dc11c6bce7 6697 python-softlayer_5.9.8-1_amd64.buildinfo Files: 23b60193a6d4867746cdbe310393bf65 2173 python optional python-softlayer_5.9.8-1.dsc 68609b60602f910fb6e38ac8bd1bbdb8 489563 python optional python-softlayer_5.9.8.orig.tar.gz 1e06147a91d66eac6786aa63425edfe8 4452 python optional python-softlayer_5.9.8-1.debian.tar.xz 82742b7f9909e35cdece0f2625f0f84e 6697 python optional python-softlayer_5.9.8-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEMEVxS8/NmLlMBvgk0AURaWEueyoFAmH8/5sACgkQ0AURaWEu eypwExAAi16fTL5P0kC24NugwidRhXuyTLOnsBqKE7034EziV0PQP5Z0eU055TG2 6Z0FqcCPCeA00loDwjGGnsBGS2yoKJmFWv/fGauWIkAnu4yeROdFV111wJWUaX0Q NVLrMKBhTzhiqIDHfLUC0LXyRxWBK4hP9qwbMs/OeKOsCX7dnQyP6+HHX/F96lBH Qy9xIgv9+UVmVcwoIN6fdkOxCJs83siRZMwr/OvZE3eix6gIn1rUQnEuF3LoVnPm JC2UUSb/ZoNvYh55cktPKbpLjZV8mba7mw8AXs4PxR1ponIY59xK//TZmIBLmNPT Jihk+6PZzXs1RdMpCr2mBJo3ERkt2J9hOQrEogYlKvVmrh53z4NRYXefO+r0dX9T jr4nX0oX/GK0ddwrJwkQGCiAhmcOrLd0QlD+nuSRA53NF9XJAYYQyVdw97RLPcII 5quc1QA1BV3y+Wt49OmG4W4rLbJFlcGc/FI7+Wf07tvsOu8UBSYObQrijPvIN7E8 kjnWUHZ8hQ7lHmHUz3uhuYBIyUaFEHtHzBzNBM1ZI2WjzSTl2+L7AqpGVqzgjPrX wJ8eoapDii6dR/oP6IponpsZMjkJmEQmAj/JFeA77PJPNgyC7HVTp8/b4OvyEMHf Ss0joky9GsLZUfYkdnEBsx4ek70Xkh2ikjP+/33Atdut31k373s= =HKxR -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#1004960: ITP: cmyt -- Matplotlib colormaps from the yt project
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org, debian-as...@lists.debian.org, debian-scie...@lists.debian.org * Package name: cmyt Version : 1.0.4 Upstream Author : Clement Robert * URL : https://github.com/yt-project/cmyt * License : BSD-3-Clause Programming Lang: Python Description : Matplotlib colormaps from the yt project cmyt integrates with matplotlib in a similar fashion to cmocean or cmasher It is a new build dependency of the "yt" package. I will maintain it within the Debian Python team. Salsa dir is https://salsa.debian.org/python-team/packages/cmyt Best regards Ole
Re: Please make a separate package for mistune 2.x
On Thu, Feb 03, 2022 at 11:34:26PM +0100, Pierre-Elliott Bécue wrote: > Hi Michael, > > > Since Mistune 2.0.0 regresses its support for standard markdown, I ask > > that a separate package be made for mistune 2.x to give more time for > > mistune 0.8.x users to migrate to mistune 2.x or another library entirely. > > > > Cheers, > > I'm not formally against it, but it's not really standard in my > opinion. It'd lead to maintenance of two packages, probably on some long > term (as it'd relieve the pressure to migrate for maintainers of > reverse-deps of mistune). > > Besides, having a source package named "mistune2" while upstream's > package is named "mistune" adds also another layer of complexity. > > I'd like to have some python team members' opinion on this, and I am not > sure to be eager to do it as of now. I agree that this sounds like a terrible idea. What would the Python module be called in a separate python3-mistune2 package be called? If it were called mistune, then python3-mistune2 would have to conflict with python3-mistune (or "python3-mistune0.84" or similar), and there would be little benefit. If the module itself were renamed to mistune2, then the Debian mistune package would be incompatible with any other software requiring mistune. Basically, the mistune upstream author has completely messed up on this by making what is essentially a completely different package with superficially similar functionality but the same name. What the Debian nbconvert maintainers have done is to vendor mistune 0.8.4: they now include it as _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. Maybe not ideal, but it will work until the upstream maintainers find a way to work with mistune 2.0.x. Best wishes, Julian
Re: Please make a separate package for mistune 2.x
On 2/4/22 9:18 PM, Julian Gilbey wrote: Basically, the mistune upstream author has completely messed up on this by making what is essentially a completely different package with superficially similar functionality but the same name. True. [...] _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. But that'd lead to a number of mistune's embedded copies in a huge number of packages; since majority of the rev-deps (when I last checked) haven't adapted to this new version. When they do, and it becomes a overhead to fix each one later. Even worse, if we discover a security problem sometime later, then all such packages would be effected, and that honestly does not look like a good idea to me. I somehow do not understand the urgency of uploading this newer version, as the maintainer said: | I intend to upload src:mistune 2.0.0 to unstable between March the | 15th and April the 15th (depending on the progress of its | reverse-dependencies). We could simply wait a little more for the dust to settle, IMHO. Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Please make a separate package for mistune 2.x
On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote: > On 2/4/22 9:18 PM, Julian Gilbey wrote: > > Basically, the mistune upstream author has completely messed up on > > this by making what is essentially a completely different package with > > superficially similar functionality but the same name. > > True. > > [...] > > _mistune.py within the Debian package, > > and have nbconvert do "import nbconvert.filters._mistune as mistune" > > (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). > > That seems like an eminently sensible solution to this problem. > > But that'd lead to a number of mistune's embedded copies in a huge number of > packages; since majority of > the rev-deps (when I last checked) haven't adapted to this new version. When > they do, > and it becomes a overhead to fix each one later. > Even worse, if we discover a security problem sometime later, then all such > packages would be > effected, and that honestly does not look like a good idea to me. This is true, though there are only 7 reverse dependencies currently in testing. > I somehow do not understand the urgency of uploading this newer version, as > the maintainer said: > > | I intend to upload src:mistune 2.0.0 to unstable between March the > | 15th and April the 15th (depending on the progress of its > | reverse-dependencies). > > We could simply wait a little more for the dust to settle, IMHO. That would be a reasonable approach, but how long will it take for the dust to settle? With this major change, and no guidance from upstream on how to migrate, and at least a number of upstream authors happy to rely on setup.py having "mistune <1.0.0" in the install_requires field, it might be several months or longer before things are fixed upstream. And what do we do when some packages have converted and some haven't? Best wishes, Julian
Re: Please make a separate package for mistune 2.x
On 2/4/22 9:33 PM, Julian Gilbey wrote: _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. But that'd lead to a number of mistune's embedded copies in a huge number of packages; since majority of the rev-deps (when I last checked) haven't adapted to this new version. When they do, and it becomes a overhead to fix each one later. Even worse, if we discover a security problem sometime later, then all such packages would be effected, and that honestly does not look like a good idea to me. This is true, though there are only 7 reverse dependencies currently in testing. Yeah, in total the reverse-deps are 8 and there is one different reverse-build-dep (pasted at end of this mail) But the problem is if these fall through the cracks, and close to the release we notice some package is not looking nice. Also, if you suppose that the upstreams are very slow, and we get to the new debian release with these things still embedded, it'd be a real mess to upload fixes to stable, right... I somehow do not understand the urgency of uploading this newer version, as the maintainer said: | I intend to upload src:mistune 2.0.0 to unstable between March the | 15th and April the 15th (depending on the progress of its | reverse-dependencies). We could simply wait a little more for the dust to settle, IMHO. That would be a reasonable approach, but how long will it take for the dust to settle? With this major change, and no guidance from upstream on how to migrate, and at least a number of upstream authors happy to rely on setup.py having "mistune <1.0.0" in the install_requires field, it might be several months or longer before things are fixed upstream. I think we could do this transition even a month or two before the soft freeze starts, which is roughly an year from now (considering general trend timings of starting in feb in release year). Situation might improve by then, I suppose. If it does not, we could still go ahead with the older python3-mistune in the archive, I do not see a huge problem there, except for maybe a few mistune uploads to stable if desired. And what do we do when some packages have converted and some haven't? In such a case, we atleast will have a few examples to see how to go about doing the API changes the right way. We could patch out at our end and send the changes upstream for review provided we are stuck in an unfortunate situation. Let me know what you'd think about this? Regards, Nilesh Reverse-Depends * giara [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] * iredis * lektor * lookatme * matrix-mirage [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] * python3-flasgger * python3-m2r * python3-schema-salad Reverse-Testsuite-Triggers * markdown-it-py Reverse-Build-Depends * lektor * lookatme * markdown-it-py * python-flasgger * python-m2r * python-schema-salad OpenPGP_signature Description: OpenPGP digital signature
Re: Please make a separate package for mistune 2.x
Le 4 février 2022 16:57:59 GMT+01:00, Nilesh Patra a écrit : >On 2/4/22 9:18 PM, Julian Gilbey wrote: >> Basically, the mistune upstream author has completely messed up on >> this by making what is essentially a completely different package with >> superficially similar functionality but the same name. > >True. > >> [...] >> _mistune.py within the Debian package, >> and have nbconvert do "import nbconvert.filters._mistune as mistune" >> (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). >> That seems like an eminently sensible solution to this problem. > >But that'd lead to a number of mistune's embedded copies in a huge number of >packages; since majority of >the rev-deps (when I last checked) haven't adapted to this new version. When >they do, >and it becomes a overhead to fix each one later. >Even worse, if we discover a security problem sometime later, then all such >packages would be >effected, and that honestly does not look like a good idea to me. > >I somehow do not understand the urgency of uploading this newer version, as >the maintainer said: > >| I intend to upload src:mistune 2.0.0 to unstable between March the >| 15th and April the 15th (depending on the progress of its >| reverse-dependencies). > >We could simply wait a little more for the dust to settle, IMHO. > >Regards, >Nilesh > Because some packages I maintain depend on mistune 2.x and mistune 0.8.4 is, whether we like it or not, obsolete. I can't really afford to wait for a year to try having mailman3 in testing again... -- Pierre-Elliott Bécue From my phone
Re: Please make a separate package for mistune 2.x
Le 2022-02-04 à 11 h 24, Nilesh Patra a écrit : On 2/4/22 9:33 PM, Julian Gilbey wrote: _mistune.py within the Debian package, and have nbconvert do "import nbconvert.filters._mistune as mistune" (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). That seems like an eminently sensible solution to this problem. But that'd lead to a number of mistune's embedded copies in a huge number of packages; since majority of the rev-deps (when I last checked) haven't adapted to this new version. When they do, and it becomes a overhead to fix each one later. Even worse, if we discover a security problem sometime later, then all such packages would be effected, and that honestly does not look like a good idea to me. This is true, though there are only 7 reverse dependencies currently in testing. Yeah, in total the reverse-deps are 8 and there is one different reverse-build-dep (pasted at end of this mail) But the problem is if these fall through the cracks, and close to the release we notice some package is not looking nice. Also, if you suppose that the upstreams are very slow, and we get to the new debian release with these things still embedded, it'd be a real mess to upload fixes to stable, right... I somehow do not understand the urgency of uploading this newer version, as the maintainer said: | I intend to upload src:mistune 2.0.0 to unstable between March the | 15th and April the 15th (depending on the progress of its | reverse-dependencies). We could simply wait a little more for the dust to settle, IMHO. That would be a reasonable approach, but how long will it take for the dust to settle? With this major change, and no guidance from upstream on how to migrate, and at least a number of upstream authors happy to rely on setup.py having "mistune <1.0.0" in the install_requires field, it might be several months or longer before things are fixed upstream. I think we could do this transition even a month or two before the soft freeze starts, which is roughly an year from now (considering general trend timings of starting in feb in release year). Situation might improve by then, I suppose. If it does not, we could still go ahead with the older python3-mistune in the archive, I do not see a huge problem there, except for maybe a few mistune uploads to stable if desired. And what do we do when some packages have converted and some haven't? In such a case, we atleast will have a few examples to see how to go about doing the API changes the right way. We could patch out at our end and send the changes upstream for review provided we are stuck in an unfortunate situation. FWIW, there's a recent patch and PR for the lektor upstream which add mistune 2.x support, so for this particular project I don't think a separate package is necessary. -- Jerome
