The Mapnik team is pleased to announce that Mapnik 2.0 is finally here! See : http://mapnik.org/news/2011/sep/26/release_2_0/ The source code is available at : http://prdownload.berlios.de/mapnik/mapnik-2.0.0.tar.bz2 Reproducible: Always
In case it helps, here is an ebuild for -9999: https://gitorious.org/drzraf/gentoo/blobs/master/sci-geosciences/mapnik/mapnik-9999.ebuild
Thanks for the ebuild. Unfortunately, there is a problem during install : >>> Install mapnik-9999 into /var/tmp/portage/sci-geosciences/mapnik-9999/image/ category sci-geosciences scons install scons: Reading SConscript files ... Using previous successful configuration... Re-configure by running "python scons/scons.py configure". Welcome to Mapnik... ********************************************* You are compiling Mapnik trunk (aka Mapnik2) See important details at: http://trac.mapnik.org/wiki/Mapnik2 ********************************************* scons: done reading SConscript files. scons: Building targets ... Install file: "src/libmapnik2.so" as "/usr/lib64/libmapnik2.so.2.0.0" ACCESS DENIED open_wr: /usr/lib64/libmapnik2.so.2.0.0 scons: *** [/usr/lib64/libmapnik2.so.2.0.0] /usr/lib64/libmapnik2.so.2.0.0: Permission denied scons: building terminated because of errors. * ERROR: sci-geosciences/mapnik-9999 failed (install phase): * escons failed. * * Call stack: * ebuild.sh, line 56: Called src_install * environment, line 2890: Called escons 'install' * environment, line 1770: Called die * The specific snippet of code: * [[ ${ret} -ne 0 && ${EAPI:-0} -ge 4 ]] && die "escons failed."; * * If you need support, post the output of 'emerge --info =sci-geosciences/mapnik-9999', * the complete build log and the output of 'emerge -pqv =sci-geosciences/mapnik-9999'. * The complete build log is located at '/var/tmp/portage/sci-geosciences/mapnik-9999/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-geosciences/mapnik-9999/temp/environment'. * S: '/var/tmp/portage/sci-geosciences/mapnik-9999/work/mapnik-9999' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-5888.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /usr/lib64/libmapnik2.so.2.0.0 A: /usr/lib64/libmapnik2.so.2.0.0 R: /usr/lib64/libmapnik2.so.2.0.0 C: python2 /usr/bin/scons install --------------------------------------------------------------------------
mapnik2 is now in the tree, but it's currently masked since it will break gpsdrive. If you don't use gpsdrive, then please unmask mapnik2 and give it a try.
Could we reopen this so we can discuss this new ebuild ? 1) the URL about the release is now http://mapnik.org/news/2011/09/26/release_2_0/ 2) the scons script rebuilds the whole at each run, this is suboptimal: try to run ebuild mapnik-2.0.0.ebuild twice (or even `scons shared=1` twice in the source directory) 3) should we make osm a useflag or use a MAPNIK_plugins useflag mechanism so that, eg, libcurl dep' depends on "osm" format activation ? 4) I didn't though enough before using the "nobfonts" semantic. I think it would be better to invert this: a "bundled-font" useflag defaulting to "off" ? 5) I don't understand the scons ${MAKEOPTS} shared=1 (especially the presence of MAKEOPTS here) in src_compile() 6) could we stay away from patching SConstruct if possible and rather using scons parameters (like I did in the original ebuild for PROJ_LIBS and PROJ_INCLUDE). It's probably proper in the long-run. 7) why does the patch introduce AGG_LIBS ? can't we rely on INTERNAL_LIBAGG (which seems to use pkg-config) ? 8) we may avoid some ebuild customizations using LINK_PRIORITY to override DEFAULT_LINK_PRIORITY.
these issues are still to be resolved (see also open bugs against 2.0 in the bugtracker). I would add that there are problems related to boost version selection as it seems that : 1° ebuild request >= 1.48 2° scons search for > 1.41 3° whatever BOOST* variables passed to scons, it appears (at least for me) that 1.46 is always selected (while I do have both 1.46 and 1.48 installed). The double-compilation (confirmed in bug #397421) and the impossibility to resume a build are especially annoying.
