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 :) Jérémy.
_______________________________________________ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
