On 07/16/2015 12:45 AM, Jérémy Lal wrote: > 2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: > >> On 07/16/2015 12:35 AM, Jérémy Lal wrote: >>> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: >>> >>>> On 06/28/2015 12:46 PM, Jérémy Lal wrote: >>>>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: >>>>>> On 06/19/2015 06:35 PM, Jérémy Lal wrote: >>>>>>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort <po...@debian.org >>> : >>>>>>> >>>>>>>> (Moving the discussion to #788533; #756867 bcc'ed) >>>>>>>> >>>>>>>> On 19/06/15 14:40, Sebastiaan Couwenberg wrote: >>>>>>>>> The mips* FTBFS are a recurring problem for the mapnik package, >>>>>> previous >>>>>>>>> builds were no different. I'll try to get it to build on a >> porterbox, >>>>>>>>> but I expect intervention from the buildd admins will be required >>>> like >>>>>>>>> last time to make sure only the buildds with the most resources try >>>> to >>>>>>>>> build mapnik. >>>>>>>>> >>>>>>>>> See: https://bugs.debian.org/742149 >>>>>>>>> https://bugs.debian.org/729121 >>>>>>>> >>>>>>>> I'm not sure there are buildds with more RAM. Note that the package >>>>>> failed >>>>>>>> in >>>>>>>> the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of >>>> swap. >>>>>>>> Since >>>>>>>> all these arches are 32bits, more memory is probably not going to >>>> help. >>>>>>>> >>>>>>>> Instead, perhaps you can make the build take less memory, e.g. by >>>>>> reducing >>>>>>>> the >>>>>>>> optimizations (-O1?) or using some flags such as the linker's >>>>>>>> --no-keep-memory. >>>>>>> >>>>>>> >>>>>>> Mapnik 2.2 used to pass builds with some of those options, also with >>>>>>> removing >>>>>>> -ftemplate-depth-300. >>>>>>> That last option i restored with mapnik 3.0, to see what would happen >>>>>> with >>>>>>> upstream options, >>>>>>> since so much has changed in that project. >>>>>>> I'm preparing now an upload with that option removed. >>>>>> >>>>>> The new uploaded didn't resolve the build failures, it still failed on >>>>>> {hurd,kfreebsd}-i386 & mips*. >>>>>> >>>>>> Since it's a recurring problem on mips*, maybe exclude these >>>>>> architectures and request removal of the package on mips*. >>>>> >>>>> I've requested removal of the old mapnik 2.2 libs on the three >>>> architectures >>>>> where it fails. I've been told that's the only thing needed to allow >>>>> migration to testing. >>>>> https://bugs.debian.org/789720 >>>> >>>> The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same >>>> archs again. I've just pushed a change to exclude mips* from the list of >>>> architectures that will prevent them from building mapnik. >>>> >>>> mapnik still can't migrate because the old python-mapnik binaries >>>> (#790043) and the outstanding RC bugs. >>>> >>>> https://release.debian.org/migration/testing.pl?package=mapnik >>>> >>>> I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to >>>> get the mips* exclusion and static libraries for the python-mapnik build >>>> into the archive. After that we can request removal of the mapnik >>>> package for mips & mipsel. >>>> >>>> Jérémy, do you have anything you want to add before the upload? >>>> >>> >>> ok for python-mapnik (and the transition package python-mapnik2) >>> >>> As far as i understand, you just need >>> Architecture: any >>> and removal of the previous 2.2 versions on mips and mipsel that were in >>> testing >>> to get mapnik to go in testing on other architectures again. >>> That is already done... >> >> So do you want to revert the Architecture change? >> >> > Yes. > Unless someone explains how i'm wrong, of course :)
Failing to build on a release architecture is generally an RC bug, which prevents testing migration. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 _______________________________________________ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
