Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)

[Jérémy Lal]

2015-07-16 7:40 GMT+02:00 Sebastiaan Couwenberg <sebastic at xs4all.nl>:

> On 07/16/2015 12:45 AM, Jérémy Lal wrote:
> > 2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg <sebastic at xs4all.nl>:
> >
> >> On 07/16/2015 12:35 AM, Jérémy Lal wrote:
> >>> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg <sebastic at xs4all.nl>:
> >>>
> >>>> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> >>>>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg <sebastic at 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 <
> pochu at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-grass-devel/attachments/20150716/b31b4941/attachment-0001.html>