Spec URL: http://www.passback.org.uk/maps/rpms/mapnik.spec SRPM URL: http://www.passback.org.uk/maps/rpms/SRPMS/mapnik-0.4.0-3.src.rpm Description: Mapnik is an OpenSource C++/Python toolkit for developing GIS (Geographic Information Systems) applications. At the core is a C++ shared library providing algorithms/patterns for spatial data access and visualization.
Spec URL: http://www.passback.org.uk/maps/rpms/SPECS/mapnik.spec
It fails to build in mock for me: RPM build errors: File not found: /var/tmp/mapnik-0.4.0-3.fc8-root-mockbuild/usr/bin/.sconsign
What version of Fedora are you building for, current development/rawhide?
Yes, rawhide. It's using scons-0.97-2.fc8.noarch to build with
Unfortunately I've not even upgraded to Fedora 7 yet :-( I'll try and get around to reproducing this in the next few days, thought I'm a bit busy with my day job.
Please update the status of this bug.
It looks like the excludes I had in the SPEC for the .sconsign files are not needed on F7 or Rawhide. New SPEC file and SRPM here: http://www.passback.org.uk/maps/rpms/SPECS/mapnik.spec http://www.passback.org.uk/maps/rpms/SRPMS/mapnik-0.4.0-4.src.rpm
Created attachment 158690 [details] mock build log of mapnik 0.4.0-4 on rawhide i386 Very quick comment: ! Details are written in http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ReviewGuidelines * rpmlint: ---------------------------------------------------- W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/boundaries_l.shp.xml W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/boundaries.shp.xml W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/qcdrainage.shp.xml W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/ontdrainage.shp.xml W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/popplaces.shp.xml W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/COPYRIGHT.txt W: mapnik wrong-file-end-of-line-encoding /usr/share/doc/mapnik-0.4.0/demo/data/roads.shp.xml W: mapnik summary-ended-with-dot Library providing algorithms for spatial data access and visualization. E: mapnik invalid-soname /usr/lib/libmapnik.so libmapnik.so W: mapnik summary-ended-with-dot Library providing algorithms for spatial data access and visualization. W: mapnik rpm-buildroot-usage %build scons PREFIX=%{_prefix} DESTDIR=%{buildroot} %{?_smp_mflags} W: mapnik macro-in-%changelog _prefix ----------------------------------------------------------------- SUMMARY: - Some files have Windows-style end-of-file encodings. Please fix them to Unix-style encodings - Summary should not end with dot. ? QUESTION How is libmapnik.so used? - Is this library used only by this package? - Or can this library be linked from other software? - In %changelog, please use %%_prefix. Otherwise %_prefix is expanded in %changelog. * compilation flags - Fedora specific compilation flags are not honored. - -O3 flag is generally forbidden (this make debugging difficult) * Fonts - Fedora has dejavu-fonts, dejavu-fonts-experimental and shipping duplicate dejavu fonts in this package is not allowed. * sitelib vs sitearch - This package installs /usr/lib/python2.5/site-packages/mapnik/_mapnik.so , which is arch dependent. python related files must be installed under %python_sitearch. not under %python_sitelib. http://fedoraproject.org/wiki/Packaging/Python
In response to the question in comment #8 about the use of Mapnik. Mapnik can be used either as a Python or a C++ library. Apart from the demo code included you need to write either a python or C++ program to do something useful. Mapnik is mainly used in the OpenStreetMap project, http://www.openstreetmap.org/. The ultimate plan is to submit all of the components of the OSM toolchain to Fedora. The goals of OSM fit neatly with Fedora - free map data to allow the development of novel GIS applications. I'll work through the issues you raise over the next couple of days and submit an updated SPEC and SRPM.
(In reply to comment #9) > In response to the question in comment #8 about the use of Mapnik. Mapnik can > be used either as a Python or a C++ library. What is the problem is that is if libmapnik.so *is linked (dynamically)* from other packages, then having no soversion is a problem because the ABI of libmapnik.so may change in the future. At that point, all the applications linking to libmapnik.so silently gets useless.
Ok. I'll need to work with upstream to get the following fixed: - Fix the line endings on the XML demo files - Fix the soname/ABI stuff - Fix the compilation flags I could do most of this in the SPEC file but it makes more sense to do it upstream, and they are generally quite responsive.
Would you have some new information?
Sorry, I've been busy at work and this slipped my mind. I've sent an email upstream and hope to hear back in the next couple of days.
Upstream have agreed to make some changes and I'll need to do the rest in the SPEC file. Currently working with the package maintainers for other distributions to coordinate the changes and get a new version released.
> Some files have Windows-style end-of-file encodings. Please fix them > to Unix-style encodings Files removed in upstream SVN. > Summary should not end with dot. Fixed. > QUESTION How is libmapnik.so used? > - Is this library used only by this package? > - Or can this library be linked from other software? Still waiting on upstream. > - In %changelog, please use %%_prefix. Otherwise %_prefix is expanded > in %changelog. Fixed. > * compilation flags > - Fedora specific compilation flags are not honored. > - -O3 flag is generally forbidden (this make debugging difficult) Fixed in SPEC file / patches. Upstream did not want to change. > * Fonts > - Fedora has dejavu-fonts, dejavu-fonts-experimental and > shipping duplicate dejavu fonts in this package is not > allowed. Fixed in SPEC file / patches. Still needed in upstream to build on other platforms (eg Windows). > * sitelib vs sitearch > - This package installs > /usr/lib/python2.5/site-packages/mapnik/_mapnik.so , > which is arch dependent. > python related files must be installed under %python_sitearch. > not under %python_sitelib. Fixed. I am still waiting on upstream to fix the soversion and then to make a release. I have not published an updated version of my SPEC file as I have switched to building from SVN prior to the upstream release.
It will be nice to have this, as the development version of GPSdrive (http://www.gpsdrive.de/) will use mapnik if it can find it. (Which answers the question in comment 15, above, about whether other programs can use mapnik.)
Build problem: -------------------------------------------------- ... + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: mapnik-0.4.0-3.fc7 error: File not found: /var/tmp/mapnik-0.4.0-3.fc7-root-ccurley/usr/bin/.sconsign error: File not found: /var/tmp/mapnik-0.4.0-3.fc7-root-ccurley/usr/lib/.sconsign Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.95117 ... -------------------------------------------------- I installed scons immediately before starting to run this build. Is there something I should have done with scons first? Or is something calling the wrong program: [ccurley@charlesc rpm]$ ll /usr/bin/.sconsign ls: cannot access /usr/bin/.sconsign: No such file or directory [ccurley@charlesc rpm]$ ll /usr/bin/sconsign -rwxr-xr-x 1 root root 14935 2007-05-17 10:36 /usr/bin/sconsign [ccurley@charlesc rpm]$ ll /usr/lib/.sconsign ls: cannot access /usr/lib/.sconsign: No such file or directory [ccurley@charlesc rpm]$ ll /usr/lib/sconsign ls: cannot access /usr/lib/sconsign: No such file or directory I am python illiterate, so this could be something I haven't done. If so, can you automate it so that other python illiterates can use the package?
You have 88 .hpp files (c++ headers). Can those and other development goodies go into a -devel subpackage? Thanks
(In reply to comment #16) > It will be nice to have this, as the development version of GPSdrive > (http://www.gpsdrive.de/) will use mapnik if it can find it. (Which answers the > question in comment 15, above, about whether other programs can use mapnik.) > - No, this does not answer my question. I am not asking how this program is used, but how *libmapnik.so* is used. I am asking if * this library is linked from other applications * or this library is dlopened * or this library is never used from other applications (In reply to comment #18) > You have 88 .hpp files (c++ headers). Can those and other development goodies go > into a -devel subpackage? - If the software itself is a development tool, it may contain header files etc.. by default.
(In reply to comment #18) > > You have 88 .hpp files (c++ headers). Can those and other development goodies > > go into a -devel subpackage? > > - If the software itself is a development tool, it may contain header files etc.. by default. I agree - Mapnik does nothing on its own, so I would consider the whole thing to be a development package.
(In reply to comment #17) > I installed scons immediately before starting to run this build. Is there > something I should have done with scons first? Or is something calling the wrong > program: > > [ccurley@charlesc rpm]$ ll /usr/bin/.sconsign > ls: cannot access /usr/bin/.sconsign: No such file or directory > [ccurley@charlesc rpm]$ ll /usr/bin/sconsign > -rwxr-xr-x 1 root root 14935 2007-05-17 10:36 /usr/bin/sconsign > [ccurley@charlesc rpm]$ ll /usr/lib/.sconsign > ls: cannot access /usr/lib/.sconsign: No such file or directory > [ccurley@charlesc rpm]$ ll /usr/lib/sconsign > ls: cannot access /usr/lib/sconsign: No such file or directory Use the most recent SPEC (0.4.0-4) file from comment #7. The way Scons works changed from FC6 to F7.
Re Comment #21: The spec file from comment 7 works with the older SRPM. I got a 404 on the SRPM in comment 7, though. Thank you.
Sorry, I should have been clearer. My thinking on a separate devel package (comment 18) is that while a developer would need the headers, an end user -- someone not developing with mapnik, but using a program which calls the library -- would not need or want them. Case in point: I have the X11 libraries loaded, but no X11 header files.
Apologies, the URL for the SRPM should be: http://www.passback.org.uk/maps/rpms/SRPMS/mapnik-0.4.0-4.fc7.src.rpm I take your point about splitting into mapnik and mapnik-devel. Comments from other reviewers or potential sponsors would be welcome.
runtime libraries (and executables) should be separated from development parts, ie parts that are needed only when building against mapnik library. scripts that are used only during the build can go to the -devel subpackage. It may also be relevant to split the python part, depending on the case.
So again back to my question. (In reply to comment #19) > (In reply to comment #16) > > It will be nice to have this, as the development version of GPSdrive > > (http://www.gpsdrive.de/) will use mapnik if it can find it. (Which answers the > > question in comment 15, above, about whether other programs can use mapnik.) > > > - No, this does not answer my question. I am not asking how > this program is used, but how *libmapnik.so* is used. > I am asking if > * this library is linked from other applications > * or this library is dlopened > * or this library is never used from other applications (In reply to comment #25) > runtime libraries (and executables) should be separated So is libmapnik.so "runtime library"? i.e. how libmapnik.so is used from other application?
In case it's useful, you may wish to cross-reference with my Mapnik Debian packages: http://packages.debian.org/unstable/source/mapnik . Upstream is still a bit unsure about versioned sonames - for the time being I'm using a private soname scheme as you can see from the package. Re Comment #14 - do get in touch if you need any coordination (apologies if I missed an email before).
Well, so what should we do?
Upstream is on vacation for the next couple of weeks with no Internet access. I'll ping them when they return and try to get this moving.
If mapnik is going to use the system copy of dejavu instead of it's own then the setting of fontscollectionpath in paths.py in the python binding should probably be changed as well so that it points at /usr/share/fonts/dejavu or it won't register any fonts by default.
The current mapnik code also contains a copy of the agg library and it looks like the RPM is currently building that as a static library and linking it into libmapnik.so rather than linking against the system libagg.so from the agg package. The mapnik headers also need the agg headers, so any mapnik-devel package will need to require the agg-devel package.
An updated SPEC file (builds from SVN) with the following fixes: - Fix fontpath from Comment #30 - Use system libagg rather than private version, Comment #31 - Split into mapnik/mapnik-devel/mapnik-python as per Comments #18 and #25 I still need to work out what to do about the soname issue and get upstream to do a release rather than rely on SVN. SPEC: http://www.passback.org.uk/svn/fedora/rpms/SPECS/mapnik-svn.spec SRPM: http://www.passback.org.uk/packages/fedora/SRPMS/mapnik-0.4.0-1.20071031.fc7.src.rpm
On fedora8 (x86_64) I get an error while trying to build: Checking for C++ library gigabase_r... no Checking for C++ library boost_thread... no Could not find header or shared library for boost thread, exiting! error: Bad exit status from /var/tmp/rpm-tmp.14514 (%build) I do seem to have all of the boost packages installed: [paul@bofh GIS]$ rpm -qa|grep boost boost-devel-1.34.1-5.fc8 boost-devel-1.34.1-5.fc8 boost-1.34.1-5.fc8 boost-1.34.1-5.fc8 boost-devel-static-1.34.1-5.fc8 [paul@bofh GIS]$ locate boost|grep thre [paul@bofh GIS]$ find /usr/lib* |grep boost|grep thread /usr/lib/libboost_thread-mt.so.1.34.1 /usr/lib/libboost_thread-mt.so.3 /usr/lib/libboost_thread-mt.so /usr/lib64/libboost_thread-mt.a find: /usr/lib64/audit: Permission denied /usr/lib64/libboost_thread-mt.so.1.34.1 /usr/lib64/libboost_thread-mt.so.3 find: /usr/libexec/utempter: Permission denied /usr/lib64/libboost_thread-mt.so
The build error on F8 is a known issue. The problem is that the boost libraries have changed name for F7 -> F8. The fix is to split out the boost part of the SConstruct patch and make it conditional on Fedora version. I hope to do this in the next day or so.
Any progress?
Good news from upstream - they have fixed the sonames issue and are preparing a release, so we should see progress soon. I am travelling on business until the 28th and will not be able to do anything with this package until the end of the month.
I have just filed a review request without realising Kieth had been working on this - https://bugzilla.redhat.com/show_bug.cgi?id=436704 The above review is for mapnik 0.5 which builds happily in koji against dist-f8. Needed a single patch for ppc64. Kieth - happy to work together on getting this one into the repo's if you wish :)
So should we need to close bz# 436704? I think that you need to sync your efforts with Keith.
Well, once closing bug 436704 and setting NEEDINFO for Keith.
*** Bug 436704 has been marked as a duplicate of this bug. ***
I don't have much time to spend on this at the moment, so if Christoper wants to take over that is fine with me.
Okay, then I will open bug 436704 again, close this bug. *** This bug has been marked as a duplicate of 436704 ***