<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg <span dir="ltr"><<a href="mailto:sebastic@xs4all.nl" target="_blank">sebastic@xs4all.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">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>
>>>> (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 porterbox,<br>
>>>>> but I expect intervention from the buildd admins will be required like<br>
>>>>> last time to make sure only the buildds with the most resources try 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 swap.<br>
>>>> Since<br>
>>>> all these arches are 32bits, more memory is probably not going to 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 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>
</div></div>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></blockquote><div><br></div><div>ok for python-mapnik (and the transition package python-mapnik2)</div><div><br></div><div>As far as i understand, you just need</div><div>Architecture: any</div><div>and removal of the previous 2.2 versions on mips and mipsel that were in testing</div><div>to get mapnik to go in testing on other architectures again.</div><div>That is already done...</div><div><br></div><div>Jérémy.</div><div><div class=""><div class="h5"><br></div></div></div></div></div></div>