Re: python-scipy: autopkgtest fails (Re: bug#919929)
On 2019-03-07 20:46, Paul Gevers wrote: If you upload now, your package will not migrate to testing before the full freeze becomes effective so it would need an unblock. If you want to fix this issue with the three lines I saw in the bug report, you can go ahead. However, it is probably worth waiting for a resolution of bug 915738 and combine it with that. Alas, the deprecation patch (in python-scipy 1.1.0-3) doesn't actually prevent emission of the deprecation warnings, so they're still spamming the debci log. On the bright side, s390x is now using gfortran-8 successfully (#915738). To remove the deprecation warnings we'd need to deal with them at the source. Upstream has patches https://github.com/scipy/scipy/commit/614847c5fc8d5f8a618980df3c1b93540428ae46 https://github.com/scipy/scipy/commit/e0cfa29e2fbe86f994924c0c7514ff5bbfffd514 and for completeness https://github.com/scipy/scipy/commit/87e48c3c54d7a85bc6628c88c1de98ac0469b6fa The deprecation problem (matrix API) appears in many places, but the fix is straightfoward: replace np.matrix with matrix from from scipy.sparse.sputils Can you authorise an unblock to apply these 3 upstream patches to python-scipy 1.1.0 ? That won't necessarily fix the debci failure, but it will make it a lot easier to see what's actually failing. Drew
Re: python-scipy: autopkgtest fails (Re: bug#919929)
On 2019-03-07 22:07, Paul Gevers wrote: Hi Drew, On 07-03-2019 14:56, Drew Parsons wrote: On 2019-03-07 20:46, Paul Gevers wrote: However, it is probably worth waiting for a resolution of bug 915738 and combine it with that. There hasn't been recent movement on 915738. I'll apply Julian's patch and see how we go. Huh. There was a comment from doko that the underlying issue is fixed in gcc-8, no? I think you only need to switch to the default gfortran. On the other hand, I don't know how feasible it is at this moment to not release buster with gcc-7. Maybe other release team members can comment on that? Perhaps it's ok now, as Matthias says. Testing on zelenka now. I'll do the 919929 upload if s390x proves fine. Drew
Re: python-scipy: autopkgtest fails (Re: bug#919929)
Hi Drew, On 07-03-2019 14:56, Drew Parsons wrote: > On 2019-03-07 20:46, Paul Gevers wrote: >> However, it is probably worth waiting for a resolution of bug >> 915738 and combine it with that. > > There hasn't been recent movement on 915738. I'll apply Julian's patch > and see how we go. Huh. There was a comment from doko that the underlying issue is fixed in gcc-8, no? I think you only need to switch to the default gfortran. On the other hand, I don't know how feasible it is at this moment to not release buster with gcc-7. Maybe other release team members can comment on that? Paul signature.asc Description: OpenPGP digital signature
Re: python-scipy: autopkgtest fails (Re: bug#919929)
On 2019-03-07 20:46, Paul Gevers wrote: Hi Drew, On 07-03-2019 13:19, Drew Parsons wrote: python-scipy is currently failing all debci tests in both unstable and testing. autopkgtest only, so no FTBFS? That's right, scipy builds fine. Some of us want failing autopkgtest to be RC *after* the release of buster. I am not aware of consensus about that yet. autopkgtest *regression* in testing is effectively RC since the soft freeze of 12-2-2019. The autopkgtest of python-scipy is already failing in testing, so it isn't a regression. Hence, it failing is not RC for buster. Thanks, that clarifies the appropriate severity. Certainly please do unblock if the full freeze is already in place. But my intention was to first upload python-scipy 1.1 with a small patch, not 1.2 just yet. If you upload now, your package will not migrate to testing before the full freeze becomes effective so it would need an unblock. If you want to fix this issue with the three lines I saw in the bug report, you can go ahead. However, it is probably worth waiting for a resolution of bug 915738 and combine it with that. There hasn't been recent movement on 915738. I'll apply Julian's patch and see how we go. Drew
Re: python-scipy: autopkgtest fails (Re: bug#919929)
Hi Drew, On 07-03-2019 13:19, Drew Parsons wrote: >> Can you elaborate why you think that bug should be RC (as that isn't >> clear to me from the report itself) and why you haven't marked it as >> such if you think it should be? > > python-scipy is currently failing all debci tests in both unstable and > testing. autopkgtest only, so no FTBFS? > I haven't marked it RC myself since I'm not 100% certain what the usual > protocol is for marking the severity of debci test failures. But as I > understood it, debci test failures is considered RC under the final > freeze which we're about to enter (but we're not quite in that deep > freeze yet). Some of us want failing autopkgtest to be RC *after* the release of buster. I am not aware of consensus about that yet. autopkgtest *regression* in testing is effectively RC since the soft freeze of 12-2-2019. The autopkgtest of python-scipy is already failing in testing, so it isn't a regression. Hence, it failing is not RC for buster. > Hi Andreas, I may not have been clear. What I mean at this point is to > upload a small patch for scipy 1.1 to ignore the deprecation warnings > (scipy 1.2 already does that). > > If that doesn't help pass the debci tests then we can consider uploading > scipy 1.2 instead. But python-fluids and dipy FTBFS against scipy 1.2 > (a new version of dipy is available which presumeably fixes that) Please *don't* upload scipy 1.2 to fix only this issue (nor for any other issue without discussion first), it's for sure not worth it. >> Slightly depending on the answer above, I'll unblock an upload of >> python-scipy with only that change. > > Certainly please do unblock if the full freeze is already in place. But > my intention was to first upload python-scipy 1.1 with a small patch, > not 1.2 just yet. If you upload now, your package will not migrate to testing before the full freeze becomes effective so it would need an unblock. If you want to fix this issue with the three lines I saw in the bug report, you can go ahead. However, it is probably worth waiting for a resolution of bug 915738 and combine it with that. Paul signature.asc Description: OpenPGP digital signature
Re: python-scipy: autopkgtest fails (Re: bug#919929)
On 2019-03-07 19:00, Paul Gevers wrote: Hi Drew, On 07-03-2019 09:03, Andreas Tille wrote: On Tue, Mar 05, 2019 at 07:01:54PM +0800, Drew Parsons wrote: python-scipy has recently started failing all debci tests in testing and unstable, exacerbating the bug report in Bug#919929 [1]. The failing error is a MemoryError. But understanding the problem is hampered by a flood of deprecation warnings, presumably triggered by numpy 1.16. scipy 1.2 added instructions to pytest.ini to ignore the warnings. Bug#919929 has not yet been marked RC but I guess it's about to happen. Can you elaborate why you think that bug should be RC (as that isn't clear to me from the report itself) and why you haven't marked it as such if you think it should be? python-scipy is currently failing all debci tests in both unstable and testing. I haven't marked it RC myself since I'm not 100% certain what the usual protocol is for marking the severity of debci test failures. But as I understood it, debci test failures is considered RC under the final freeze which we're about to enter (but we're not quite in that deep freeze yet). I propose in the first instance to apply a patch of the pytest.ini diff between scipy 1.1 and 1.2 and see if that clears things up. I'll commit the patch now. Should I proceed with upload to unstable? May be its sensible to coordinate with debian-release (list in CC) and file a unblock request *before* uploading. I confirm that I usually upload simple fixes and ask for unblock afterwards but you intend to do a version change which does not qualify as simple fix (despite I agree with you that it is sensible). Hi Andreas, I may not have been clear. What I mean at this point is to upload a small patch for scipy 1.1 to ignore the deprecation warnings (scipy 1.2 already does that). If that doesn't help pass the debci tests then we can consider uploading scipy 1.2 instead. But python-fluids and dipy FTBFS against scipy 1.2 (a new version of dipy is available which presumeably fixes that) Slightly depending on the answer above, I'll unblock an upload of python-scipy with only that change. Certainly please do unblock if the full freeze is already in place. But my intention was to first upload python-scipy 1.1 with a small patch, not 1.2 just yet. Drew
Re: python-scipy: autopkgtest fails (Re: bug#919929)
Hi Drew, On 07-03-2019 09:03, Andreas Tille wrote: > On Tue, Mar 05, 2019 at 07:01:54PM +0800, Drew Parsons wrote: >> python-scipy has recently started failing all debci tests in testing and >> unstable, exacerbating the bug report in Bug#919929 [1]. >> >> The failing error is a MemoryError. But understanding the problem is >> hampered by a flood of deprecation warnings, presumably triggered by numpy >> 1.16. scipy 1.2 added instructions to pytest.ini to ignore the warnings. >> >> Bug#919929 has not yet been marked RC but I guess it's about to happen. Can you elaborate why you think that bug should be RC (as that isn't clear to me from the report itself) and why you haven't marked it as such if you think it should be? >> I >> propose in the first instance to apply a patch of the pytest.ini diff >> between scipy 1.1 and 1.2 and see if that clears things up. I'll commit the >> patch now. Should I proceed with upload to unstable? > > May be its sensible to coordinate with debian-release (list in CC) and > file a unblock request *before* uploading. I confirm that I usually > upload simple fixes and ask for unblock afterwards but you intend to do > a version change which does not qualify as simple fix (despite I agree > with you that it is sensible). Slightly depending on the answer above, I'll unblock an upload of python-scipy with only that change. Paul signature.asc Description: OpenPGP digital signature
