Created attachment 698540 [details] Patch to update to mapnik 2.1.0 Mapnik 2.1.0 has been out for six months now so I think we should update... I'm attaching a diff against the packing repo to update it which has been tested locally. Note that the library name does change from libmapnik2 to libmapnik but it doesn't look like there are any dependent packages at the moment.
Created attachment 699384 [details] Patch to update to mapnik 2.1.0 Realised when doing a mock build that a BR on sqlite-devel is now needed, so I've updated the patch to add that as well.
Anything more I can do to help with this? I'm happy to come on board as a co-maintainer if you need help maintaining mapnik.
It would be good to get this sorted before it's too late to get it into F19 so please do say if there's anything more I can do to help progress it.
While trying to use Mapnik to render tiles using Tirex for OpenStreetMap, I ran in the following bug using mapnik-2.0.0-7: 'mapnik-config --dep-libs' returns '-l[agg]', which breaks linking when building Tirex. Is this issue fixed with 2.1.0? (I reported this at https://github.com/mapnik/mapnik/issues/1779 and was told to report it at Fedora bug tracker, I can open a new bug entry on Bugzilla if needed) Thanks, Bernard
(In reply to comment #4) > While trying to use Mapnik to render tiles using Tirex for OpenStreetMap, I > ran in the following bug using mapnik-2.0.0-7: 'mapnik-config --dep-libs' > returns '-l[agg]', which breaks linking when building Tirex. Is this issue > fixed with 2.1.0? > > (I reported this at https://github.com/mapnik/mapnik/issues/1779 and was > told to report it at Fedora bug tracker, I can open a new bug entry on > Bugzilla if needed) What on earth does any of this have to do with this bug? My comment on the mapnik bug about reporting it here was (a) about the fonts issues (b) meaning that you should create your own bug here and (c) not necessary as I explained about the fonts in the mapnik bug anyway.
While doing a mock build of the new package scons started recompiling everything in the install phase, probably because a different set of options were given on the scons command line in the install section from what was given in the build section. Also, I noticed that an "osm" plugin wasn't built because libcurl wasn't available. Not sure if that was deliberately left out or not.
Hmm, so getting scons to stop rebuilding everything during install wasn't quite as easy as I thought, it wasn't completely impossible. It seems that the first time scons is run it creates a config.py file all of the custom options is created that is read by subsequent runs of scons. The trick was to make the first run of scons not build anything which I accomplished with "scons configure". I also added a dependency on libcurl-devel so that the OSM input plugin can be built and some other stylistic cleanups. As as side effect this should fix Bernard's problem as I was able to build mod_tile/renderd against the new mapnik. I haven't tried building tirex yet.
Created attachment 718069 [details] Upgrade to 2.1.0
Created attachment 718075 [details] Upgrade to 2.1.0
Created attachment 730938 [details] Patch to update to mapnik 2.1.0 Here's an updated version of my patch that does the separate configure and adds in libcurl-devel, but without all the whitespace changes and other rearrangement. Scratch build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5199522
Created attachment 730969 [details] Add some requires to devel subpackage I added some requires to the -devel subpackage to make compiling tirex easier (probably helps mod_tile/renderd too but I haven't tried it yet).
It's hard to tell what requires it is you added, but I think it would only be appropriate to add a require to the devel package if it was something that was needed into order to be able to link to mapnik. Certainly some of your requires look inappropriate - there shouldn't be any reason for mapnik-utils to pull in mapnik-devel for example. Just making it easier to compile tirex is not a valid reason to pull things in certainly - if tirex wants something that is not strictly necessary to link against mapnik then it should require that.
(In reply to comment #12) > It's hard to tell what requires it is you added, but I think it would only > be appropriate to add a require to the devel package if it was something > that was needed into order to be able to link to mapnik. All of the following packages were required to build/link tirex (in addition to the requires already there): boost-devel cairomm-devel libicu-devel libtiff-devel libtool-ltdl-devel libxml2-devel I'd have to double-check but with the possible exception of boost-devel I'm fairly sure that tirex does not directly access any of the other APIs. > Certainly some of your requires look inappropriate - there shouldn't be any > reason for mapnik-utils to pull in mapnik-devel for example. Hmm, mapnik-utils in my version doesn't require mapnik-devel. > Just making it easier to compile tirex is not a valid reason to pull things > in certainly - if tirex wants something that is not strictly necessary to > link against mapnik then it should require that. I'm pretty sure that all of the above are required, boost, cairomm, libicu and libtool-ltdl are referenced directly in some of mapnik's header files and I couldn't link without pulling in libtiff and libxml2.
Created attachment 730986 [details] complete mapnik spec file For reference, here's my complete mapnik spec file.
Yes it's quite likely that those devel requires are reasonable, but your patch seemed to be adding various other ones. Anyway for now I really just want to get it updated and get things more active again...
(In reply to comment #15) > Yes it's quite likely that those devel requires are reasonable, but your > patch seemed to be adding various other ones. Probably a side effect of my "clean up"... I'm particular about how I format my spec files and find it hard to resist. > Anyway for now I really just want to get it updated and get things more > active again... Yeah, I think I'm going to submit RPMs for mod_tile/renderd and tirex. I'm pretty satisfied with the mod_tile/renderd specs but the tirex one still needs some tweaking.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
(In reply to comment #12) > It's hard to tell what requires it is you added, but I think it would only > be appropriate to add a require to the devel package if it was something > that was needed into order to be able to link to mapnik. > > Certainly some of your requires look inappropriate - there shouldn't be any > reason for mapnik-utils to pull in mapnik-devel for example. > > Just making it easier to compile tirex is not a valid reason to pull things > in certainly - if tirex wants something that is not strictly necessary to > link against mapnik then it should require that. Applied your patch to master, but I get an error at build time on f20 (rawhide): /usr/include/boost/fusion/container/list/cons.hpp:83:40: error: invalid initialization of reference of type 'boost::fusion::cons<mapnik::feature_impl&, boost::fusion::nil>::car_type {aka mapnik::feature_impl&}' from expression of type 'const car_type {aka const boost::error_cant_deduce_type}' : car(rhs.car), cdr(rhs.cdr) {} full log: http://kojipkgs.fedoraproject.org//work/tasks/4491/5314491/build.log
I think this is down to rawhide having a newer boost. There's a patch on the 2.1.x branch that I think will fix it: https://github.com/mapnik/mapnik/commit/cf70b9959a45b9ab6af4a34824a5e4e80ce1d05c
(In reply to comment #19) > I think this is down to rawhide having a newer boost. There's a patch on the > 2.1.x branch that I think will fix it: > > https://github.com/mapnik/mapnik/commit/ > cf70b9959a45b9ab6af4a34824a5e4e80ce1d05c Thanks, rebuilding with that patch.
(In reply to comment #20) > (In reply to comment #19) > > I think this is down to rawhide having a newer boost. There's a patch on the > > 2.1.x branch that I think will fix it: > > > > https://github.com/mapnik/mapnik/commit/ > > cf70b9959a45b9ab6af4a34824a5e4e80ce1d05c > > Thanks, rebuilding with that patch. Hmm, still no workie. http://kojipkgs.fedoraproject.org//work/tasks/4874/5314874/build.log If you're OK with it, I'll release primary maintainership and let you take over at this point, as I don't have enough time to devote to debugging this right now.
I'll stay on as co-maintainer, btw.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I'm not sure what caused that compiler crash as a koji scratch build is working for me, so long as I turn SMP builds off again - there still seem to be missing dependencies somewhere in the build scripts. A bigger problem is that the unbundling of agg is no longer working, and there are now local changes to agg which mean the system one won't work, so I have filed for a bundling exception: https://fedorahosted.org/fpc/ticket/279
An updated mapnik (actually version 2.2 in the end) has now been built in rawhide.