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

[Sebastiaan Couwenberg]

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

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1