2015-07-16 7:40 GMT+02:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>:
> 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 > > I'm very surprised by this. The opposite was explained to me on #debian-devel by by Julien Cristau (cc-ing him in case he can tell me how i got this the wrong way). Is this written somewhere ? Jérémy
