Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
On Thu, Jul 16, 2015 at 23:20:59 +0200, Jérémy Lal wrote:
> > Failing to build on a release architecture is generally an RC bug, which
> > prevents testing migration.
> >
> > Kind Regards,
> >
> > Bas
> >
> >
> I'm very surprised by this. The opposite was explained to me on
> #debian-devel by
> by Julien Cristau (cc-ing him in case he can tell me how i got this the
> wrong way).
> Is this written somewhere ?
>
Failing to build on a release architecture is not an RC bug, unless it's
a regression. See section 4 of
https://release.debian.org/stretch/rc_policy.txt
If there's no version of the package on ${architecture} in unstable
(either because it never built or because old builds have been removed),
then a failure to build on ${architecture} is somewhere between
wishlist and important, but it's not RC.
Cheers,
Julien
signature.asc
Description: Digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Processed: Re: Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
Processing commands for cont...@bugs.debian.org: > fixed 788533 mapnik/3.0.0+ds-2 Bug #788533 [src:mapnik] mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory Marked as fixed in versions mapnik/3.0.0+ds-2. > thanks Stopping processing here. Please contact me if you need assistance. -- 788533: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788533 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
On 07/16/2015 11:20 PM, Jérémy Lal wrote: > 2015-07-16 7:40 GMT+02:00 Sebastiaan Couwenberg : >> On 07/16/2015 12:45 AM, Jérémy Lal wrote: >> Failing to build on a release architecture is generally an RC bug, which >> prevents testing migration. >> > I'm very surprised by this. The opposite was explained to me on > #debian-devel by > by Julien Cristau (cc-ing him in case he can tell me how i got this the > wrong way). > Is this written somewhere ? I guess that's implied by the severity description: " serious is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. " https://www.debian.org/Bugs/Developer#severities Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
2015-07-16 7:40 GMT+02:00 Sebastiaan Couwenberg :
> On 07/16/2015 12:45 AM, Jérémy Lal wrote:
> > 2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg :
> >
> >> On 07/16/2015 12:35 AM, Jérémy Lal wrote:
> >>> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
> >>>
> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> > 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg >:
> >> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> >>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort <
> po...@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
>
>
I'm very surprised by this. The opposite was explained to me on
#debian-devel by
by Julien Cristau (cc-ing him in case he can tell me how i got this the
wrong way).
Is this written somewhere ?
Jérémy
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
On 07/16/2015 12:45 AM, Jérémy Lal wrote:
> 2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg :
>
>> On 07/16/2015 12:35 AM, Jérémy Lal wrote:
>>> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
>>>
On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
>> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
>>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort >> :
>>>
(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
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg :
> On 07/16/2015 12:35 AM, Jérémy Lal wrote:
> > 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
> >
> >> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> >>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> > 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort >:
> >
> >> (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 :)
Jérémy.
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
On 07/16/2015 12:35 AM, Jérémy Lal wrote:
> 2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
>
>> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
>>> 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
>
>> (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?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg :
> On 06/28/2015 12:46 PM, Jérémy Lal wrote:
> > 2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
> >> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> >>> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
> >>>
> (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.
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg :
> On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> > 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
> >
> >> (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
It doesn't forbid trying builds with suggested flags above (-O1,
--no-keep-memory).
Jérémy.
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory (Was: Bug#756867: transition: gdal)
On 06/19/2015 06:35 PM, Jérémy Lal wrote:
> 2015-06-19 18:22 GMT+02:00 Emilio Pozuelo Monfort :
>
>> (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*.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
Bug#788533: mapnik: FTBFS: virtual memory exhausted: Cannot allocate memory
Source: mapnik Version: 3.0.0~rc3+ds-1 Severity: serious Hi, Your package is failing to build on mips and mipsel (release architectures) and kfreebsd-i386: https://buildd.debian.org/status/logs.php?pkg=mapnik&ver=3.0.0~rc3%2Bds-1 This seems related to #742149. Cheers, Emilio ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
