Bug#937791: Blocked on reverse dependencies
On 4/13/20 2:25 PM, Moritz Mühlenhoff wrote: On Sat, Feb 08, 2020 at 11:13:20AM -0800, Martin Kelly wrote: On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly wrote: On 2/2/20 8:39 PM, Sandro Tosi wrote: should we remove this package then? or do you want to generate a python3-gmpy? I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? Looking further, it seems that with current versions of Python 3 (I tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run test3/gmpy_test.py, I'm getting: $ python3 test3/gmpy_test.py ... 8 items had failures: 1 of 4 in gmpy_test_cvr 4 of 126 in gmpy_test_cvr.__test__.user_errors 1 of 1 in gmpy_test_dec 2 of 2 in gmpy_test_mpf 2 of 60 in gmpy_test_mpf.__test__.binio 2 of 2 in gmpy_test_mpq 2 of 4 in gmpy_test_mpz 7 of 25 in gmpy_test_rnd.__test__.rand 1504 tests in 42 items. 1483 passed and 21 failed. ***Test Failed*** 21 failures. In contrast, the tests for GMPY 2 all succeed, so I think the author clearly intended for tests to fully pass. Since this hasn't been maintained for 7 or so years, I'm not too surprised. Given this, I think we should let this package be removed and consider resurrecting it in the future if people ask for it and someone will step up to maintain it. Sandro, is there anything more to do if I want to let this package be removed, or do I just wait for the auto-removal? Martin, what are you referring here to with "removed"? Removal from testing or unstable? The former happened automatically in the mean time, the latter needs a bug using "reportbug ftp.debian.org" Cheers, Moritz Thanks for clarifying; I filed a bug to remove this package from unstable, as it's dead upstream and all reverse dependencies are removed from unstable at this point: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958138
Bug#937791: Blocked on reverse dependencies
On Sat, Feb 08, 2020 at 11:13:20AM -0800, Martin Kelly wrote: > On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly > wrote: > > On 2/2/20 8:39 PM, Sandro Tosi wrote: > > > should we remove this package then? or do you want to generate a > > > python3-gmpy? > > > > > > > I didn't realize, but it looks like this package actually does support > > Python 3. I had assumed we would let this package die when Python 2 > > dies, since the package is dead upstream since 2013. However, looking at > > the popcon stats, the original python GMPY is still much more popular > > than than python GMPY2 (3543 vs 443). So I think it's worth keeping this > > package. > > > > I'm working on converting it over now and should be able to get it done > > in the next few weeks. > > > > Is it possible to remove the AUTORM tag until this is done, or should we > > let it get deleted and upload a new python3-gmpy package after that? > > > > Looking further, it seems that with current versions of Python 3 (I tested > with 3.7.3), the old GMPY 1.17 is no longer passing. When I run > test3/gmpy_test.py, I'm getting: > > $ python3 test3/gmpy_test.py > ... > 8 items had failures: >1 of 4 in gmpy_test_cvr >4 of 126 in gmpy_test_cvr.__test__.user_errors >1 of 1 in gmpy_test_dec >2 of 2 in gmpy_test_mpf >2 of 60 in gmpy_test_mpf.__test__.binio >2 of 2 in gmpy_test_mpq >2 of 4 in gmpy_test_mpz >7 of 25 in gmpy_test_rnd.__test__.rand > 1504 tests in 42 items. > 1483 passed and 21 failed. > ***Test Failed*** 21 failures. > > In contrast, the tests for GMPY 2 all succeed, so I think the author clearly > intended for tests to fully pass. Since this hasn't been maintained for 7 or > so years, I'm not too surprised. > > Given this, I think we should let this package be removed and consider > resurrecting it in the future if people ask for it and someone will step up > to maintain it. > > Sandro, is there anything more to do if I want to let this package be > removed, or do I just wait for the auto-removal? Martin, what are you referring here to with "removed"? Removal from testing or unstable? The former happened automatically in the mean time, the latter needs a bug using "reportbug ftp.debian.org" Cheers, Moritz
Bug#937791: Blocked on reverse dependencies
> Is it possible to remove the AUTORM tag until this is done, or should we > let it get deleted and upload a new python3-gmpy package after that? it will just be removed from testing, which is fine: it will go back in when the python3 package hits unstable and no more RC bugs pop up -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#937791: Blocked on reverse dependencies
On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly wrote: On 2/2/20 8:39 PM, Sandro Tosi wrote: > should we remove this package then? or do you want to generate a python3-gmpy? > I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? Looking further, it seems that with current versions of Python 3 (I tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run test3/gmpy_test.py, I'm getting: $ python3 test3/gmpy_test.py ... 8 items had failures: 1 of 4 in gmpy_test_cvr 4 of 126 in gmpy_test_cvr.__test__.user_errors 1 of 1 in gmpy_test_dec 2 of 2 in gmpy_test_mpf 2 of 60 in gmpy_test_mpf.__test__.binio 2 of 2 in gmpy_test_mpq 2 of 4 in gmpy_test_mpz 7 of 25 in gmpy_test_rnd.__test__.rand 1504 tests in 42 items. 1483 passed and 21 failed. ***Test Failed*** 21 failures. In contrast, the tests for GMPY 2 all succeed, so I think the author clearly intended for tests to fully pass. Since this hasn't been maintained for 7 or so years, I'm not too surprised. Given this, I think we should let this package be removed and consider resurrecting it in the future if people ask for it and someone will step up to maintain it. Sandro, is there anything more to do if I want to let this package be removed, or do I just wait for the auto-removal?
Bug#937791: Blocked on reverse dependencies
On 2/2/20 8:39 PM, Sandro Tosi wrote: $ apt-cache rdepends python-gmpy python-gmpy Reverse Depends: obfsproxy python-tlslite-ng python-sympy python-gmpy-doc Dependencies on obfsproxy and python-sympy documented with affects and blocks. python-tlslite-ng has been removed already, there are no more reverse dependencies on python-gmpy, what should we do next? i see the source package doesnt produce any python3 package, and the last changelog entry contains: * Override python-foo-but-no-python3-foo Lintian warning, since this package is end-of-life after Python 2 support ends. should we remove this package then? or do you want to generate a python3-gmpy? I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? and we can rename python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved. please dont, -doc package must preserve the python- prefix. Cheers, Sandro
Bug#937791: Blocked on reverse dependencies
> > $ apt-cache rdepends python-gmpy > > python-gmpy > > Reverse Depends: > >obfsproxy > >python-tlslite-ng > >python-sympy > >python-gmpy-doc > > > > > > Dependencies on obfsproxy and python-sympy documented with affects and > blocks. python-tlslite-ng has been removed already, there are no more reverse dependencies on python-gmpy, what should we do next? i see the source package doesnt produce any python3 package, and the last changelog entry contains: * Override python-foo-but-no-python3-foo Lintian warning, since this package is end-of-life after Python 2 support ends. should we remove this package then? or do you want to generate a python3-gmpy? > and we can rename > python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved. please dont, -doc package must preserve the python- prefix. Cheers, Sandro
