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
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 sebas...@xs4all.nl:
On 07/16/2015 12:45 AM, Jérémy Lal wrote:
2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
On 07/16/2015 12:35 AM, Jérémy Lal wrote:
2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
On 06/28/2015 12:46 PM, Jérémy Lal wrote:
2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg sebas...@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
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 11:20 PM, Jérémy Lal wrote: 2015-07-16 7:40 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl: 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)
On 07/16/2015 12:45 AM, Jérémy Lal wrote:
2015-07-16 0:41 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
On 07/16/2015 12:35 AM, Jérémy Lal wrote:
2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
On 06/28/2015 12:46 PM, Jérémy Lal wrote:
2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg sebas...@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 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
--
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 sebas...@xs4all.nl:
On 06/28/2015 12:46 PM, Jérémy Lal wrote:
2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg sebas...@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 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...
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 sebas...@xs4all.nl:
On 06/28/2015 12:46 PM, Jérémy Lal wrote:
2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg sebas...@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 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?
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 sebas...@xs4all.nl:
On 07/16/2015 12:35 AM, Jérémy Lal wrote:
2015-07-16 0:20 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
On 06/28/2015 12:46 PM, Jérémy Lal wrote:
2015-06-20 13:34 GMT+02:00 Sebastiaan Couwenberg sebas...@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 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 :)
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 sebas...@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 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
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 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*.
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=mapnikver=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
