On Mon, 3 Oct 2016 17:25:39 +0200 Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> wrote: > On Monday, 03 October 2016 at 10:43, Dan Horák wrote: > > On Thu, 22 Sep 2016 18:10:44 +0200 > > Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> wrote: > > > > > On Thursday, 22 September 2016 at 16:55, Dan Horák wrote: > > > > On Thu, 22 Sep 2016 15:41:01 +0200 > > > > Dominik 'Rathann' Mierzejewski <dominik@xxxxxxxxxxxxxx> wrote: > > > > > > > > > Hello, > > > > > I've just pushed (but not built) python-matplotlib-2.0.0b4 to > > > > > rawhide. I'll be attempting to rebuild all the affected > > > > > packages locally to test if they're compatible. In the > > > > > meantime, feel free to git pull and build locally for your > > > > > own testing. > > > > > > > > python-matplotlib has been a pain for alternative arches > > > > recently, due failures in the test-suite (in 1.5.x). Is the 2.0 > > > > version going to be better in this regard? > > > > > > tldr: no, but upstream is aware and working on it. > > > > > > There are quite a few issues opened on upstream github tracker > > > either by me or by Debian maintainer. The main problem is that > > > upstream checks that rendering output matches their generated > > > images. This changes slightly with different versions of > > > freetype. As a workaround, I reintroduced a certain base > > > tolerance in order not to add specific tolerance value to each > > > failing test (there are ~900 failing due to slight rendering > > > differences). Then, there are some arch-specific issues, mainly > > > on ARM. > > > > Could we disable the test-suite for alternative arches until there > > is proper upstream fix? Quite a number of packages/builds are > > blocked on python-matplotlib currently. > > Which arches are we talking about? s390x, ppc64(le)? Anything else? plus aarch64, question can be whether to make the list "positive" %ifnarch arm, x86 then skip test results or "negative" with %ifarch aarch64 ppc64 s390 ... > > > For math precision issues -ffp-contract=off often helps. And yes, > > comparing rendered output can be considered fragile, we have already > > met it ... > > Where does that parameter go? into CFLAGS, it's for gcc Dan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
