Bug 234581

Summary: Review Request: Mapnik cartography library - first package, need sponsor.
Product: [Fedora] Fedora Reporter: Keith Sharp <kms>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: charlescurley, dom, lemenkov, mtasaka, pertusus, pwouters, rhbugs, rollercow, ruben, sander, snecklifter, tom
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-21 11:11:02 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 201449    
Attachments:
Description Flags
mock build log of mapnik 0.4.0-4 on rawhide i386 none

Description Keith Sharp 2007-03-30 05:49:48 EDT
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.
Comment 1 Sander Hoentjen 2007-03-30 05:57:43 EDT
Spec URL: http://www.passback.org.uk/maps/rpms/SPECS/mapnik.spec
Comment 2 Ruben Kerkhof 2007-06-10 10:12:25 EDT
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
Comment 3 Keith Sharp 2007-06-10 13:19:16 EDT
What version of Fedora are you building for, current development/rawhide?
Comment 4 Ruben Kerkhof 2007-06-10 15:04:38 EDT
Yes, rawhide.

It's using scons-0.97-2.fc8.noarch to build with
Comment 5 Keith Sharp 2007-06-10 15:44:21 EDT
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.
Comment 6 Mamoru TASAKA 2007-07-06 11:15:39 EDT
Please update the status of this bug.
Comment 7 Keith Sharp 2007-07-06 12:50:25 EDT
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
Comment 8 Mamoru TASAKA 2007-07-06 14:48:52 EDT
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
Comment 9 Keith Sharp 2007-07-06 17:14:33 EDT
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.
Comment 10 Mamoru TASAKA 2007-07-06 21:38:56 EDT
(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.
Comment 11 Keith Sharp 2007-07-07 03:33:31 EDT
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.
Comment 12 Mamoru TASAKA 2007-07-24 06:52:55 EDT
Would you have some new information?
Comment 13 Keith Sharp 2007-07-25 04:45:35 EDT
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.
Comment 14 Keith Sharp 2007-07-30 16:29:51 EDT
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.
Comment 15 Keith Sharp 2007-07-31 12:12:19 EDT
> 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.
Comment 16 Charles Curley 2007-08-03 19:53:51 EDT
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.)
Comment 17 Charles Curley 2007-08-03 21:29:59 EDT
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?
Comment 18 Charles Curley 2007-08-03 21:33:10 EDT
You have 88 .hpp files (c++ headers). Can those and other development goodies go
into a -devel subpackage?

Thanks
Comment 19 Mamoru TASAKA 2007-08-03 22:08:34 EDT
(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.
  
Comment 20 Keith Sharp 2007-08-04 03:07:10 EDT
(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.
Comment 21 Keith Sharp 2007-08-04 03:10:33 EDT
(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.
Comment 22 Charles Curley 2007-08-04 09:07:17 EDT
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.
Comment 23 Charles Curley 2007-08-04 09:30:40 EDT
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.
Comment 24 Keith Sharp 2007-08-04 10:01:31 EDT
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.
Comment 25 Patrice Dumas 2007-08-04 10:46:48 EDT
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. 
Comment 26 Mamoru TASAKA 2007-08-04 11:10:52 EDT
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?
Comment 27 Dominic Hargreaves 2007-09-02 06:04:05 EDT
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).
Comment 28 Mamoru TASAKA 2007-09-24 09:24:51 EDT
Well, so what should we do?
Comment 29 Keith Sharp 2007-09-26 03:08:27 EDT
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.
Comment 30 Tom Hughes 2007-10-17 09:48:39 EDT
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.
Comment 31 Tom Hughes 2007-10-31 04:45:03 EDT
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.
Comment 32 Keith Sharp 2007-10-31 08:51:22 EDT
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
Comment 33 Paul Wouters 2007-11-12 19:34:45 EST
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
Comment 34 Keith Sharp 2007-11-13 01:51:19 EST
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.
Comment 35 Jason Tibbitts 2008-01-18 23:21:46 EST
Any progress?
Comment 36 Keith Sharp 2008-01-19 04:55:40 EST
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.
Comment 37 Christopher Brown 2008-03-09 14:23:06 EDT
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 :)
Comment 38 Peter Lemenkov 2008-03-19 09:27:07 EDT
So should we need to close bz# 436704?
I think that you need to sync your efforts with Keith.
Comment 39 Mamoru TASAKA 2008-03-19 09:34:27 EDT
Well, once closing bug 436704  and setting NEEDINFO for Keith.
Comment 40 Mamoru TASAKA 2008-03-19 09:34:45 EDT
*** Bug 436704 has been marked as a duplicate of this bug. ***
Comment 41 Keith Sharp 2008-03-21 10:45:59 EDT
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.
Comment 42 Mamoru TASAKA 2008-03-21 11:11:02 EDT
Okay, then I will open bug 436704 again, close this bug.

*** This bug has been marked as a duplicate of 436704 ***