Bug#848758: Re: Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)
On Wed, Dec 21, 2016 at 02:05:57PM +0100, Ole Streicher wrote: >... > The according functions are since then marked as "deprecated" and issue > a warning. Numpy introduced this change with 1.11rc already, which was > uploaded to Debian about 6 months ago. After it appears that many > packages (als in Debian) have problems with this, they postponed it for > another release -- which happens just now. >... You are saying you knew for 6 months that many packages in Debian have problems with the changes that have just been uploaded. Why were no bugs filed a few months before the upload? > Best regards > > Ole cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#848758: Re: Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)
Hi Ole, On Wed, Dec 21, 2016 at 02:05:57PM +0100, Ole Streicher wrote: > On 21.12.2016 11:59, Andreas Tille wrote: > > On Wed, Dec 21, 2016 at 11:40:16AM +0200, Adrian Bunk wrote: > >> For python-skbio it is *really* time to panic *right now*. > > Thanks for confirming that I was not actually panicing. ;-) > > While I agree in principle, I would like to remind the following as well: > > The current FTBFS mainly (as far as I can see) come from a change that > was announced already two numpy versions ago: that numpy will refuse to > accept floats as indices. > > The according functions are since then marked as "deprecated" and issue > a warning. Numpy introduced this change with 1.11rc already, which was > uploaded to Debian about 6 months ago. After it appears that many > packages (als in Debian) have problems with this, they postponed it for > another release -- which happens just now. Thanks for the information. However, you know that not all upstreams are following these changes in a timely manner and not every maintainer is following the changes of the reverse dependencies that closely. In any case we have a transition freeze and my point was *also* to check whether there are other rdepends of Numpy. I admit that python-skbio is a low popcon package and if there are no other problems with the new Numpy verision *and* the new version has large advantages over the old one *and* is as RC candidate stable enough to go into Stretch its probably not a big deal if we backport python-skbio. > I am a bin angry here about unresponsive upstreams, which just ignore > these changes as long as possible, and I am not sure whether we should > ship Stretch with an outdated numpy release As far as I can see the current stable is 1.11.2 the current target for Stretch is just an RC candidate. > (I am too lazy in the moment to support my statement with links; if you > need, I will do so ofcourse) I fully believe you without links. :-) Kind regards Andreas. -- http://fam-tille.de
Bug#848758: Re: Bug#848758: Latest upgrade of Numpy breaks tests of other packages (Was: Bug#848758: python-skbio: FTBFS: Test failures)
Hi all, On 21.12.2016 11:59, Andreas Tille wrote: > On Wed, Dec 21, 2016 at 11:40:16AM +0200, Adrian Bunk wrote: >> For python-skbio it is *really* time to panic *right now*. > Thanks for confirming that I was not actually panicing. ;-) While I agree in principle, I would like to remind the following as well: The current FTBFS mainly (as far as I can see) come from a change that was announced already two numpy versions ago: that numpy will refuse to accept floats as indices. The according functions are since then marked as "deprecated" and issue a warning. Numpy introduced this change with 1.11rc already, which was uploaded to Debian about 6 months ago. After it appears that many packages (als in Debian) have problems with this, they postponed it for another release -- which happens just now. I am a bin angry here about unresponsive upstreams, which just ignore these changes as long as possible, and I am not sure whether we should ship Stretch with an outdated numpy release just because there are a number of upstreams that are too lazy to keep their packages up to date. I would really ask to push upstream hardly to do the required changes; maybe we can decide if it is needed to revert that later. The changes are required anyway; doing them sooner than later is no mistake in any case. (I am too lazy in the moment to support my statement with links; if you need, I will do so ofcourse) Best regards Ole
