<div dir="ltr">2015-07-16 7:40 GMT+02:00 Sebastiaan Couwenberg <span dir="ltr"><<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/16/2015 12:45 AM, Jérémy Lal wrote:<br>
> 2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl">sebastic@xs4all.nl</a>>:<br>
><br>
>> On 07/16/2015 12:35 AM, Jérémy Lal wrote:<br>
>>> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl">sebastic@xs4all.nl</a>>:<br>
>>><br>
>>>> On 06/28/2015 12:46 PM, Jérémy Lal wrote:<br>
>>>>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg <<a href="mailto:sebastic@xs4all.nl">sebastic@xs4all.nl</a>>:<br>
>>>>>> On 06/19/2015 06:35 PM, Jérémy Lal wrote:<br>
>>>>>>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort <<a href="mailto:pochu@debian.org">pochu@debian.org</a><br>
>>> :<br>
>>>>>>><br>
>>>>>>>> (Moving the discussion to #788533; #756867 bcc'ed)<br>
>>>>>>>><br>
>>>>>>>> On 19/06/15 14:40, Sebastiaan Couwenberg wrote:<br>
>>>>>>>>> The mips* FTBFS are a recurring problem for the mapnik package,<br>
>>>>>> previous<br>
>>>>>>>>> builds were no different. I'll try to get it to build on a<br>
>> porterbox,<br>
>>>>>>>>> but I expect intervention from the buildd admins will be required<br>
>>>> like<br>
>>>>>>>>> last time to make sure only the buildds with the most resources try<br>
>>>> to<br>
>>>>>>>>> build mapnik.<br>
>>>>>>>>><br>
>>>>>>>>> See: <a href="https://bugs.debian.org/742149" rel="noreferrer" target="_blank">https://bugs.debian.org/742149</a><br>
>>>>>>>>>      <a href="https://bugs.debian.org/729121" rel="noreferrer" target="_blank">https://bugs.debian.org/729121</a><br>
>>>>>>>><br>
>>>>>>>> I'm not sure there are buildds with more RAM. Note that the package<br>
>>>>>> failed<br>
>>>>>>>> in<br>
>>>>>>>> the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of<br>
>>>> swap.<br>
>>>>>>>> Since<br>
>>>>>>>> all these arches are 32bits, more memory is probably not going to<br>
>>>> help.<br>
>>>>>>>><br>
>>>>>>>> Instead, perhaps you can make the build take less memory, e.g. by<br>
>>>>>> reducing<br>
>>>>>>>> the<br>
>>>>>>>> optimizations (-O1?) or using some flags such as the linker's<br>
>>>>>>>> --no-keep-memory.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Mapnik 2.2 used to pass builds with some of those options, also with<br>
>>>>>>> removing<br>
>>>>>>> -ftemplate-depth-300.<br>
>>>>>>> That last option i restored with mapnik 3.0, to see what would happen<br>
>>>>>> with<br>
>>>>>>> upstream options,<br>
>>>>>>> since so much has changed in that project.<br>
>>>>>>> I'm preparing now an upload with that option removed.<br>
>>>>>><br>
>>>>>> The new uploaded didn't resolve the build failures, it still failed on<br>
>>>>>> {hurd,kfreebsd}-i386 & mips*.<br>
>>>>>><br>
>>>>>> Since it's a recurring problem on mips*, maybe exclude these<br>
>>>>>> architectures and request removal of the package on mips*.<br>
>>>>><br>
>>>>> I've requested removal of the old mapnik 2.2 libs on the three<br>
>>>> architectures<br>
>>>>> where it fails. I've been told that's the only thing needed to allow<br>
>>>>> migration to testing.<br>
>>>>> <a href="https://bugs.debian.org/789720" rel="noreferrer" target="_blank">https://bugs.debian.org/789720</a><br>
>>>><br>
>>>> The subsequent mapnik (3.0.0+ds-1) upload failed to build on the same<br>
>>>> archs again. I've just pushed a change to exclude mips* from the list of<br>
>>>> architectures that will prevent them from building mapnik.<br>
>>>><br>
>>>> mapnik still can't migrate because the old python-mapnik binaries<br>
>>>> (#790043) and the outstanding RC bugs.<br>
>>>><br>
>>>> <a href="https://release.debian.org/migration/testing.pl?package=mapnik" rel="noreferrer" target="_blank">https://release.debian.org/migration/testing.pl?package=mapnik</a><br>
>>>><br>
>>>> I'd like to upload mapnik (3.0.0+ds-2) as it currently exists in git to<br>
>>>> get the mips* exclusion and static libraries for the python-mapnik build<br>
>>>> into the archive. After that we can request removal of the mapnik<br>
>>>> package for mips & mipsel.<br>
>>>><br>
>>>> Jérémy, do you have anything you want to add before the upload?<br>
>>>><br>
>>><br>
>>> ok for python-mapnik (and the transition package python-mapnik2)<br>
>>><br>
>>> As far as i understand, you just need<br>
>>> Architecture: any<br>
>>> and removal of the previous 2.2 versions on mips and mipsel that were in<br>
>>> testing<br>
>>> to get mapnik to go in testing on other architectures again.<br>
>>> That is already done...<br>
>><br>
>> So do you want to revert the Architecture change?<br>
>><br>
>><br>
> Yes.<br>
> Unless someone explains how i'm wrong, of course :)<br>
<br>
</div></div>Failing to build on a release architecture is generally an RC bug, which<br>
prevents testing migration.<br>
<div class="HOEnZb"><div class="h5"><br>
Kind Regards,<br>
<br>
Bas<br>
</div><div class="h5"><br></div></div></blockquote><div><br></div><div>I'm very surprised by this. The opposite was explained to me on #debian-devel by</div><div>by Julien Cristau (cc-ing him in case he can tell me how i got this the wrong way).</div><div>Is this written somewhere ?</div><div><br></div></div>Jérémy</div></div>