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

[Jérémy Lal]

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...

Jérémy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-grass-devel/attachments/20150716/e75ddd05/attachment.html>