Re: Python 3 Statsmodels & Pandas
On 16.09.2017 22:59, Yuri D'Elia wrote:
> On Sat, Sep 16 2017, Diane Trout wrote:
>> python3-pandas: Pandas is not installable
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875723
>
> I would have expected the rebuild of python packages affected by the
> fpectl extension with a transition, but it doesn't seem to be the case?
no, we don't want to rename the python2.7 package.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874253
>
> More Breaks where added to {python,python3}-stdlib itself, but there are
> still packages which didn't rebuild.
fix them, they fail for unrelated reasons ;)
Re: Python 3 Statsmodels & Pandas
Hi Diane & other science+python people, Thanks for spending time on pandas and statsmodels. They are two very valuable but very painful packages to work on. I've not looked at pandas and statsmodels packages carefully beyond "why hasn't pandas migrated this time!?" investigations but the circular relationship between pandas and statsmodels and its associated problems has come up several times before. It seems to be an on-going point of pain that sucks in quite a lot of developer time. On Saturday, 16 September 2017 14:18:10 AEST Diane Trout wrote: > My solution was to use build-profiles to flag the test dependency with > !nocheck this is, of course, a very elegant solution and exactly what build profiles are for... I wonder though, is it really sustainable given this problem keeps coming up? For the maintainer upload, you can do this bootstrapping with build profiles. For other archs, however, I don't believe we can tell the buildd to use build profiles so we'd need it to built by hand on porter boxes for every arch and then uploaded. Is it feaible to completely break this circular dependency? If it is only needed for tests, would be possible to disable the build-time tests and rely on the tests run on ci.d.n instead? If it's used for generating documentation too, then would creating a separate source package for the documentation that build-depends on statsmodels and pandas be possible such that there is now no circular dependency? (thinking aloud) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Python 3 Statsmodels & Pandas
> On Saturday, 16 September 2017 14:18:10 AEST Diane Trout wrote: > > My solution was to use build-profiles to flag the test dependency > > with > > !nocheck > > this is, of course, a very elegant solution and exactly what build > profiles > are for... > > I wonder though, is it really sustainable given this problem keeps > coming up? I just did it that way because it was the least disruptive change I could make that would let me build and test the package. Also I wasn't sure how much magic was happening on the Debian build servers. > > Is it feaible to completely break this circular dependency? If it is > only > needed for tests, would be possible to disable the build-time tests > and rely In my experience I'm much more likely to to notice a build time test failure than one from the CI system. Though I did adjust my pbuilder config to fail on test failures in the autopkgtests so I already solved my own concern... What do other people think? If there are autopkgtests, should you still let dh_auto_test run tests? Diane
