Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
Sebastiaan Couwenberg
sebastic at xs4all.nl
Wed Jul 15 22:20:47 UTC 2015
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?
> It doesn't forbid trying builds with suggested flags above (-O1,
> --no-keep-memory).
I suspect the failure on kfreebsd-i386 is caused by exhausting the 32bit
address space, but since it's not a release architecture we don't have
to worry about it much.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
More information about the Pkg-grass-devel
mailing list