Bug 436704

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

Reopening...

*** Bug 234581 has been marked as a duplicate of this bug. ***

Rebuild failed on dist-f9 (seems that gcc43 adjustment is needed)
http://koji.fedoraproject.org/koji/taskinfo?taskID=525473

Also, Fedora specific compilation flags are not honored.
For scons, maybe the spec file of aqsis is useful.

(In reply to comment #4)
> Rebuild failed on dist-f9 (seems that gcc43 adjustment is needed)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=525473

Thanks Mamoru. Yes, just a few one-liners. Being sent upstream as I type. Its
now happy, see:

http://koji.fedoraproject.org/koji/taskinfo?taskID=527498

I've split out the package a bit, as per Dominic Hargreaves work @ debian. Its
now four packages:

mapnik
mapnik-devel
mapnik-python
mapnik-utils

I think this makes good sense for what is contained. I've also added build flags
as appropriate. I'm going to track subversion for devel and keep F-8 at 0.5. I
don't intend to work at F-7 so will just be requesting tags for the above.

Cheers
Chris

Rebuilt and patched to use system fonts. Upstream is adding gcc 4.3 patches to
stable 0.5 series so will most likely revert to 0.5 for both F-8 and F-9.

http://snecker.fedorapeople.org/mapnik/devel/mapnik-0.5.0svn671-1.fc8.src.rpm
http://snecker.fedorapeople.org/mapnik/devel/mapnik.spec

http://koji.fedoraproject.org/koji/taskinfo?taskID=528296

Rpmlint is quiet. Please advise on anything further that has to be done.

Cheers
Chris

I have not checked this package _at all_ yet, however the versioning
"0.5.0svn671" is against Fedora naming guidelines.

(In reply to comment #8)
> I have not checked this package _at all_ yet, however the versioning
> "0.5.0svn671" is against Fedora naming guidelines.

Indeed it is. Updated package now available.

http://snecker.fedorapeople.org/mapnik/devel/mapnik-0.5.0-0.1.20080324svn.fc8.src.rpm
http://snecker.fedorapeople.org/mapnik/devel/mapnik.spec

Cheers
Chris

Upstream have now merged the gcc 4.3 fixes. Updated package now available.

http://snecker.fedorapeople.org/mapnik/devel/mapnik-0.5.0-0.2.20080324svn.fc8.src.rpm
http://snecker.fedorapeople.org/mapnik/devel/mapnik.spec

Cheers
Chris

For 0.5.0-0.2

* License
  - The license of mapnik is LGPLv2+.

* Release number
  - If this tarball is created from svn repo, IMO it is better
    to include not date but svn revision number for Release tag.

* Explicit library dependency
-----------------------------------------------------------
Requires: boost
Requires: zlib
Requires: freetype
Requires: proj
Requires: gdal
Requires: cairo
Requires: cairomm
-----------------------------------------------------------
  - These library related requires should be catched by
    find_require.sh and these type of explicit Requries must be
    removed (except for some cases such as mono/java related
    packages)

-----------------------------------------------------------
Requires: python
-----------------------------------------------------------
  - This requires is not needed and must be removed.

* Requires for subpackages
  - Requires for -devel subpackage are not added automatically
    and you have to find out and add proper Requires.
    * Example:
      %_includedir/%name/jpeg_io.hpp contains
-----------------------------------------------------------
    25  extern "C"
    26  {
    27  #include <jpeglib.h>
    28  }
-----------------------------------------------------------
       This means that mapnik-devel should have
       "Requires: libjpeg-devel".
    The following command is useful for detecting such dependency.
-----------------------------------------------------------
$ rpm -ql mapnik-devel | grep /usr/include | xargs grep -h 'include ' | sort | uniq
-----------------------------------------------------------

   - Similarly, please check the dependency for -python subpackage
     by
-----------------------------------------------------------
$ rpm -ql mapnik-python | grep python | xargs grep -h 'import ' | sort | uniq
-----------------------------------------------------------

* Fedora specific compilation flags
  - This is not yet correctly honored.

* Use of system wide libraries
  - build.log shows
-----------------------------------------------------------
    76  g++ -o agg/src/agg_vcgen_dash.o -c -O3 -fPIC -DNDEBUG -Iagg/include
agg/src/agg_vcgen_dash.cpp
   101  ar rc agg/libagg.a agg/src/agg_line_profile_aa.o ......
   190  g++ -o src/libmapnik.so ....  -L/usr/local/lib -lagg -lfreetype ....
-----------------------------------------------------------
     Here libmapnik.so uses internal libagg.a, not libagg.so provided
     by agg-devel.
     Please apply patches so that libmapnik.so uses system-wide
     libagg.so
  - Also
------------------------------------------------------------
   166  g++ -o tinyxml/tinystr.os .... tinyxml/tinystr.cpp
   190  g++ -o src/libmapnik.so ....  tinyxml/tinystr.os ...
------------------------------------------------------------
     Here libmapnik.so uses internal tinyxml, however Fedora has
     tinyxml-devel so please use system-wide tinyxml.
   - By the way Fedora's optimation level is -O2 and -O3 is not
     allowed.

* Macros
  - Please use macros. For example, /usr must be %{_prefix}.

* Fonts
  - Patch1 shows
-------------------------------------------------------------
    19           datasource_cache::instance()->register_datasources(mapnik_dir +
"/lib/mapnik/input/"); 
    20  -        freetype_engine::register_font(mapnik_dir +
"/lib/mapnik/fonts/DejaVuSans.ttf");
    21  +        freetype_engine::register_font(mapnik_dir +
"/usr/share/fonts/dejavu/DejaVuSans.ttf");
-------------------------------------------------------------
     However /usr/share/fonts/dejavu/DejaVuSans.ttf does not exist on
     my system.
     * By the way is 'mapnik_dir + "/usr/...."' correct?
   - Also if you want to use dejavu fonts, it must be added to
     Requires (I am not talking about BuildRequires here).

ping?

(In reply to comment #12)
> ping?

Hi Mamoru,

Firstly, thanks very much for doing the review. I'm currently trying to patch
out internal agg and tinyxml as per your comments but will probably have to
liase with upstream. Patching out isn't the issue but whether the included
versions differ from fedora agg/tinyxml which from my review so far they appear
to. Other than that I have resolved all other issues and will hopefully be
submitting an updated package within the week.

Regards
Chris

Groan. Sorry about the delay on all this folks. I have not forgotten about it
though...

Mr. Christopher,

 If you dont mind I wold like to take this 
package for maintainership with yyour permission,
as I already own core GIS ones. My interest is a 
comercial one, i would like to push some quality 
into this stuff.

 First of all let me propose to further review it.

http://openrisc.rdsor.ro/mapnik.spec
http://openrisc.rdsor.ro/mapnik-0.5.1-1.fc9.src.rpm

(In reply to comment #11)
> For 0.5.0-0.2
> 
> * License
>   - The license of mapnik is LGPLv2+.

done.

> 
> * Release number
>   - If this tarball is created from svn repo, IMO it is better
>     to include not date but svn revision number for Release tag.
> 

done.
Its stable upstream for this time.

> * Explicit library dependency
> -----------------------------------------------------------
> Requires: boost
> Requires: zlib
> Requires: freetype
> Requires: proj
> Requires: gdal
> Requires: cairo
> Requires: cairomm
> -----------------------------------------------------------
>   - These library related requires should be catched by
>     find_require.sh and these type of explicit Requries must be
>     removed (except for some cases such as mono/java related
>     packages)
> 

done.

> -----------------------------------------------------------
> Requires: python
> -----------------------------------------------------------
>   - This requires is not needed and must be removed.

done.

> 
> * Requires for subpackages
>   - Requires for -devel subpackage are not added automatically
>     and you have to find out and add proper Requires.
>     * Example:
>       %_includedir/%name/jpeg_io.hpp contains
> -----------------------------------------------------------
>     25  extern "C"
>     26  {
>     27  #include <jpeglib.h>
>     28  }
> -----------------------------------------------------------
>        This means that mapnik-devel should have
>        "Requires: libjpeg-devel".
>     The following command is useful for detecting such dependency.
> -----------------------------------------------------------
> $ rpm -ql mapnik-devel | grep /usr/include | xargs grep -h 'include ' | sort |
uniq

done.

> -----------------------------------------------------------
> 
>    - Similarly, please check the dependency for -python subpackage
>      by
> -----------------------------------------------------------
> $ rpm -ql mapnik-python | grep python | xargs grep -h 'import ' | sort | uniq
> -----------------------------------------------------------

done.

> 
> * Fedora specific compilation flags
>   - This is not yet correctly honored.

done.

> * Use of system wide libraries
>   - build.log shows
> -----------------------------------------------------------
>     76  g++ -o agg/src/agg_vcgen_dash.o -c -O3 -fPIC -DNDEBUG -Iagg/include
> agg/src/agg_vcgen_dash.cpp
>    101  ar rc agg/libagg.a agg/src/agg_line_profile_aa.o ......
>    190  g++ -o src/libmapnik.so ....  -L/usr/local/lib -lagg -lfreetype ....
> -----------------------------------------------------------
>      Here libmapnik.so uses internal libagg.a, not libagg.so provided
>      by agg-devel.
>      Please apply patches so that libmapnik.so uses system-wide
>      libagg.so
>   - Also
> ------------------------------------------------------------
>    166  g++ -o tinyxml/tinystr.os .... tinyxml/tinystr.cpp
>    190  g++ -o src/libmapnik.so ....  tinyxml/tinystr.os ...
> ------------------------------------------------------------
>      Here libmapnik.so uses internal tinyxml, however Fedora has
>      tinyxml-devel so please use system-wide tinyxml.
>    - By the way Fedora's optimation level is -O2 and -O3 is not
>      allowed.

I got rid of local tinyxml, libxml2-devel external replaces it.
I got rid of local agg, external agg-devel replaces it.

> 
> * Macros
>   - Please use macros. For example, /usr must be %{_prefix}.

done.

> 
> * Fonts
>   - Patch1 shows
> -------------------------------------------------------------
>     19           datasource_cache::instance()->register_datasources(mapnik_dir +
> "/lib/mapnik/input/"); 
>     20  -        freetype_engine::register_font(mapnik_dir +
> "/lib/mapnik/fonts/DejaVuSans.ttf");
>     21  +        freetype_engine::register_font(mapnik_dir +
> "/usr/share/fonts/dejavu/DejaVuSans.ttf");
> -------------------------------------------------------------
>      However /usr/share/fonts/dejavu/DejaVuSans.ttf does not exist on
>      my system.
>      * By the way is 'mapnik_dir + "/usr/...."' correct?
>    - Also if you want to use dejavu fonts, it must be added to
>      Requires (I am not talking about BuildRequires here).

fixed.


Olso other liftups, see from changelog:
%changelog
* Sun Jul 06 2008 Balint Cristian <rezso> - 0.5.1-1
- the license of mapnik is LGPLv2+
- release is now 0.5.1 from upstream stable
- fix explicit library dependency requirement
- fix library dependency for -devel requirement
- fix library dependency for -python requirement
- fix to use fedora specific compile flag
- fix to use external agg-devel library as shared
- make sure get rid of internal tinyxml and agg chunks
- use libxml2 by default instead of tinyxml
- use macros everywhere in specfile
- use external fedora dejavu fonts insted, get rid of local one
- place tool binaries in _bindir
- add check section and run testsuite, they should pass
- add one python tool
- build and add doxygen docs
- fix multilib issue
- fix UTF-8 and some spurious permission
- include local copied web license of some demo data
- rpmlint should print zarro bugs

rpmlint output:
mapnik-utils.x86_64: W: no-documentation
6 packages and 0 specfiles checked; 0 errors, 1 warnings.

complete koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=699146

Tasaka,

  I parsed all review guidelines, probably I missed one, 
its very possible since I did a lot of things, something 
might be skew from my eye.

//cristian

Additional Remark:

  Tests from %check sections now pass everything, 
strange was that with old internal static agg it 
failed in two points.
  Sounds good for proper functionality.

//cristian

Hi Cristian,

(In reply to comment #15)
> Mr. Christopher,
> 
>  If you dont mind I wold like to take this 
> package for maintainership with yyour permission,
> as I already own core GIS ones. My interest is a 
> comercial one, i would like to push some quality 
> into this stuff.

No problem at all. I was about to give it up - just after I took this up my time
constraints changed drastically. More than happy for you to take this over! I
think you will need to open a new review request however as I am unsure how to
change the reporter field.

Regards
Chris

Additional Remark:

  I choosed 0.5.1 stable instead of svn due to fact svn is highly unstable, it
even doesnt compile. Olso, 0.5.1 has some issue with shape.input driver on
64bit, it abuses of integers, however spending several hours and formatting to
int32_t type does still not solve the issue, i am still investigating the issue,
and commit upstream if i catch it.
  It's safer for now to use gdal as input source insted of direct shape.input
driver.

//cristian

For 0.5.1-1:

* License
  - I re-checked the whole source codes and:
----------------------------------------------------------
bindings/python/mapnik/__init__.py	GPLv2+
demo/					GPLv2+
----------------------------------------------------------
    So the license tags of -python and -demo must be fixed as
    "LGPLv2+ and GPLv2+". Also write some comments in the spec file
    about how files are licensed.

* About data files under %_docdir/%name-%version/data
  - I can think you want to include these data files for some reasons?
    If so, while I think for now this license has no problem, however
    I also think I must once pass this license to spot.

* Dependency for -python subpackage
  - Would you check this again?
    For example, /usr/lib/python2.5/site-packages/mapnik/ogcserver/common.py
    contains:
-----------------------------------------------------------
    24  from PIL.Image import fromstring, new
    25  from PIL.ImageDraw import Draw
    30  from lxml import etree as ElementTree
-----------------------------------------------------------
    This means this file needs "python-imaging" and "python-lxml". However
    I don't know this file is always needed or just optional.

* Linkage error
  - For example:
-----------------------------------------------------------
$ ldd -r /usr/bin/gdal.input >/dev/null
undefined symbol: _ZNK6mapnik8EnvelopeIdE4minyEv        (/usr/bin/gdal.input)
undefined symbol: _ZN6mapnik8EnvelopeIdEC1Edddd (/usr/bin/gdal.input)
undefined symbol: _ZN6mapnik8EnvelopeIdE4initEdddd      (/usr/bin/gdal.input)
undefined symbol: _ZNK6mapnik8EnvelopeIdE4minxEv        (/usr/bin/gdal.input)
undefined symbol: _ZN6mapnik8EnvelopeIdEC1Ev    (/usr/bin/gdal.input)
undefined symbol: _ZNK6mapnik8EnvelopeIdE4maxxEv        (/usr/bin/gdal.input)
undefined symbol: _ZN6mapnik8EnvelopeIdEC1ERKS1_        (/usr/bin/gdal.input)
undefined symbol: _ZNK6mapnik8EnvelopeIdE6heightEv      (/usr/bin/gdal.input)
undefined symbol: _ZNK6mapnik8EnvelopeIdE4maxyEv        (/usr/bin/gdal.input)
undefined symbol: _ZNK6mapnik8EnvelopeIdE9intersectERKS1_      
(/usr/bin/gdal.input)
undefined symbol: _ZNK6mapnik8EnvelopeIdE5widthEv       (/usr/bin/gdal.input)
-----------------------------------------------------------
    perhaps some linkage error happened.
    By the way:
------------------------------------------------------------
$ file /usr/bin/gdal.input
/usr/bin/gdal.input: ELF 32-bit LSB shared object, Intel 80386, version 1
(SYSV), dynamically linked, stripped
------------------------------------------------------------
    This seems to be a library, not executable binary?? (you seem to
    be moving these files intentionally to %_bindir, would you verify if
    it is correct?)

ping?

new packs:
http://openrisc.rdsor.ro/mapnik.spec
http://openrisc.rdsor.ro/mapnik-0.5.1-2.fc9.src.rpm


(In reply to comment #19)
> For 0.5.1-1:
> 
> * License
>   - I re-checked the whole source codes and:
> ----------------------------------------------------------
> bindings/python/mapnik/__init__.py	GPLv2+
> demo/					GPLv2+
> ----------------------------------------------------------
>     So the license tags of -python and -demo must be fixed as
>     "LGPLv2+ and GPLv2+". Also write some comments in the spec file
>     about how files are licensed.
> 
> * About data files under %_docdir/%name-%version/data
>   - I can think you want to include these data files for some reasons?
>     If so, while I think for now this license has no problem, however
>     I also think I must once pass this license to spot.

done.
- python has explicit license tag
- created a new -demo package with explicit license tag
- those vector datas should stay for demo purpose, explicit license cover
tham fine (a local copy from original website):
     /usr/share/doc/mapnik-demo-0.5.1/data/mapnik-data.license


> 
> * Dependency for -python subpackage
>   - Would you check this again?
>     For example, /usr/lib/python2.5/site-packages/mapnik/ogcserver/common.py
>     contains:
> -----------------------------------------------------------
>     24  from PIL.Image import fromstring, new
>     25  from PIL.ImageDraw import Draw
>     30  from lxml import etree as ElementTree
> -----------------------------------------------------------
>     This means this file needs "python-imaging" and "python-lxml". However
>     I don't know this file is always needed or just optional.
> 

done.
- added two requrirements for python subpackage


> * Linkage error
>   - For example:
> -----------------------------------------------------------
> $ ldd -r /usr/bin/gdal.input >/dev/null
> undefined symbol: _ZNK6mapnik8EnvelopeIdE4minyEv        (/usr/bin/gdal.input)
> undefined symbol: _ZN6mapnik8EnvelopeIdEC1Edddd (/usr/bin/gdal.input)
> undefined symbol: _ZN6mapnik8EnvelopeIdE4initEdddd      (/usr/bin/gdal.input)
> undefined symbol: _ZNK6mapnik8EnvelopeIdE4minxEv        (/usr/bin/gdal.input)
> undefined symbol: _ZN6mapnik8EnvelopeIdEC1Ev    (/usr/bin/gdal.input)
> undefined symbol: _ZNK6mapnik8EnvelopeIdE4maxxEv        (/usr/bin/gdal.input)
> undefined symbol: _ZN6mapnik8EnvelopeIdEC1ERKS1_        (/usr/bin/gdal.input)
> undefined symbol: _ZNK6mapnik8EnvelopeIdE6heightEv      (/usr/bin/gdal.input)
> undefined symbol: _ZNK6mapnik8EnvelopeIdE4maxyEv        (/usr/bin/gdal.input)
> undefined symbol: _ZNK6mapnik8EnvelopeIdE9intersectERKS1_      
> (/usr/bin/gdal.input)
> undefined symbol: _ZNK6mapnik8EnvelopeIdE5widthEv       (/usr/bin/gdal.input)
> -----------------------------------------------------------
>     perhaps some linkage error happened.
>     By the way:
> ------------------------------------------------------------
> $ file /usr/bin/gdal.input
> /usr/bin/gdal.input: ELF 32-bit LSB shared object, Intel 80386, version 1
> (SYSV), dynamically linked, stripped
> ------------------------------------------------------------
>     This seems to be a library, not executable binary?? (you seem to
>     be moving these files intentionally to %_bindir, would you verify if
>     it is correct?)

done.
- fixed linkage error for all plugins
- these plugins will stay in _libdir/mapnik/

Once sendint to spot.
Spot, would you verify the following?

http://geogratis.cgdi.gc.ca/geogratis/en/licence.jsp

For 0.5.1-2:

* General rpmlint check
---------------------------------------------------------
mapnik.src:217: E: files-attr-not-set
mapnik.src:218: E: files-attr-not-set
mapnik.src:219: E: files-attr-not-set
mapnik.src:220: E: files-attr-not-set
mapnik-demo.i386: E: devel-dependency mapnik-devel
---------------------------------------------------------
  + I guess the last one (i.e. mapnik-demo depends on mapnik-devel)
    is intentional

  - On the other hand, the first rpmlint (i.e. %files demo entry
    does not have %defattr(-,root,root,-) ) must be fixed.

* Directory ownership issue
  - %{_libdir}/mapnik is not owned by any packages.

Please fix above. Once spot approves data license, I can say go for
this package.

Thank you Tasaka for the patience !
I'll fix #23 comments ASAP on my side.

Spot, I don't insist with the license:
http://geogratis.cgdi.gc.ca/geogratis/en/licence.jsp

Would be fine w/o, at last this particular package 
can live fine without those vector datasets
even forever, if they are declined I'll repack a -fedora 
tarball with README.fedora placeholder where I will
mention the explicit removal out from original tarball.

--------------------------------------------------------
 I am bit dissapointed  with functional misbehavior of some 
plugins/parts, invested some time to fix it, functionality 
is pretty worse on linux, upstream politics is wierd too,
next release will e.g depend on significantly totaly other 
libs, cmake seems to be dropped in SVN, but package still provide
something unique in opensource land, e.g openstreetmap.org
render their maps with mapnik, apperantly google maps too, 
and there is no other replacement tool to do this fine render 
job in GIS world for free yet.
  I wanted a SVN one pack but its impossible to compile/fix,
due to total different lib requirements which even dont exist
(i wasnt able to locate where such external functions lives
at all).

new packs:
http://openrisc.rdsor.ro/mapnik.spec
http://openrisc.rdsor.ro/mapnik-0.5.1-3.fc9.src.rpm

-----------------------
This is intentionate:
mapnik-demo.x86_64: E: devel-dependency mapnik-devel

Plugins are "clean":
ldd -r /usr/lib64/mapnik/input/* >/dev/null

Dir ownership fixed:
# rpm -qf /usr/lib64/mapnik
mapnik-0.5.1-3.fc9.x86_64

If you're disappointed with the upstream, have you considered asking them about
the problems you are having? Only I don't recall seeing any trac tickets from
you, or questions on the mailing lists...

I have now gone over the svn code and as of right now it is compiling fine for
me on Fedora 9 but please do let us know if you encounter any further problems.

Further to Tom's point, if there are fixes that you think should go in a stable
release, make a note on http://trac.mapnik.org/wiki/StableMergeQueue - I'll have
a look at doing another stable point release at some point soon.

(In reply to comment #26)
> If you're disappointed with the upstream, have you considered asking them about
> the problems you are having? Only I don't recall seeing any trac tickets from
> you, or questions on the mailing lists...
> 
> I have now gone over the svn code and as of right now it is compiling fine for
> me on Fedora 9 but please do let us know if you encounter any further problems.

1) Did you try on x86_64 any of *.input drivers ?!
- they are unusable, I spent some limited time debug it, still cant catch the issue.
2) Notice the workarounds for scons, pretty ugly ones.
3) Olso autoconf/automake works better than scons but no python magic support.
4) Upstream now switched to libicu and some cairo stuff, no major release or
some API documentation is done, and SVN is highly unstable.

  I know upstream folks, this project will soon merge with osgeo.org , and
pass their incubation process, at this point no one can tell what directions
will take, but certainly a very good one whatever future choice will be.

  However the tool is still valuable, it can render and work fine if user
know what is doing and know how to avoid problems, i plan to fix 64bit-ness at
all and still carry all .spec warkarounds even if next release will be a
complete revamp.

  Guys, today's SVN didnt changed for shape.input code, that wierd one issue
still persist, I will fill a ticket into their track with my catches, on 64 bit
simply cannot sanely parse any lets say a vector shapefile via shape.input, it
even fails to interpret the magick bits form the file header returning a totally
diffenet value than what a normal shapefile magic header value is.
  Workaround ? Yes, dont use shape.input use gdal.imput which relay on external
libs and clearly works fine, but its annoying for me as packager since tarball
comes with lots of nice and educative example of usage all relaying on
shape.input driver, so now drop those nice demos and chink down the package ?! :(
  I tryied on other distro, and same result so compile flags doesnt influence,
lib compindation not influence the issue, its clearly 64bitness somewhere.
 Another dissapointment is that they just changed some libs form one minor to
other without any signifiant debate or something, but lets wave this one fedora
can suppoort it as long tool works at all.

  
  To summarize thread:

   I would like stay with this stable (no matther that 2 subdrivers are broken),
its not my first GIS package for fedora, there was others GIS related where I
offered upstream large 64biness clean and license-due whole chunks rewrites, I
ATM simply failed with this one mapnik and its a question of time to solve it.
   I just expressed some frustrations regarding this particular package, lets
not detail more, i will try manage tham ASAP.

 Tasaka, if Tom (spot) approve that non-trivial license issue can we go further?

//cristian.

(In reply to comment #30)
>  Tasaka, if Tom (spot) approve that non-trivial license issue can we go further?

Yes.

(In reply to comment #28)
> (In reply to comment #26)
> > If you're disappointed with the upstream, have you considered asking them about
> > the problems you are having? Only I don't recall seeing any trac tickets from
> > you, or questions on the mailing lists...
> > 
> > I have now gone over the svn code and as of right now it is compiling fine for
> > me on Fedora 9 but please do let us know if you encounter any further problems.
> 
> 1) Did you try on x86_64 any of *.input drivers ?!
> - they are unusable, I spent some limited time debug it, still cant catch the
issue.

Yes. I have rendered maps using both the cairo and agg backends from a mixture
of shapefile and postgis data sources on an x86_64 machine without any problems.

> 2) Notice the workarounds for scons, pretty ugly ones.

Workarounds? Is this in the spec file? I haven't looked at that yet as I was
building from my checkout by hand.

> 3) Olso autoconf/automake works better than scons but no python magic support.

I also prefer autoconf, but Artem seems to like scons and it seems to work so I
don't see it as a major problem.

> 4) Upstream now switched to libicu and some cairo stuff, no major release or
> some API documentation is done, and SVN is highly unstable.

I know. Aside from anything else I wrote the cairo stuff... OpenStreetMap is
running with libicu and cairo support, so it can't that unstable. We're about to
update to the latest svn head in fact.

>   I know upstream folks, this project will soon merge with osgeo.org , and
> pass their incubation process, at this point no one can tell what directions
> will take, but certainly a very good one whatever future choice will be.

I'm not aware of any plans for mapnik to become an osgeo project, and I don't
see it listed on the incubator, so I'm not sure where you're getting that
information from.

>   However the tool is still valuable, it can render and work fine if user
> know what is doing and know how to avoid problems, i plan to fix 64bit-ness at
> all and still carry all .spec warkarounds even if next release will be a
> complete revamp.

Perhaps if you just tell us what problem you're having we can fix it!

Tom

(In reply to comment #30)
>   
>   To summarize thread:
> 
>    I would like stay with this stable (no matther that 2 subdrivers are broken),
> its not my first GIS package for fedora, there was others GIS related where I
> offered upstream large 64biness clean and license-due whole chunks rewrites, I
> ATM simply failed with this one mapnik and its a question of time to solve it.
>    I just expressed some frustrations regarding this particular package, lets
> not detail more, i will try manage tham ASAP.
> 
>  Tasaka, if Tom (spot) approve that non-trivial license issue can we go further?
> 
> //cristian.

The work that you have done so far is great and I'm both grateful and relieved
that someone else took up the challenge. However please send your patches
upstream - you have still yet to make any comments on the development mailing
list for this project - they can then be merged into the stable branch as
suggested. I have found them to be extremely receptive and responsive to what I
have sent. Sending patches upstream is one of the core principles of packaging
for Fedora:

http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream

I would urge you to convert the sed processing and other code-munging present in
the .spec file into a patch and post it to the relevant list.

Regards
Chris

I have now added an option to the build scripts in svn to build using the system
libagg by passing INTERNAL_LIBAGG=False to scons. That should allow some of your
patching to be dropped.

There shouldn't be any need to patch out tinyxml as you are doing as you are
building with libxml2 so the tinyxml code is not pulled in at all.

(In reply to comment #34)
> I have now added an option to the build scripts in svn to build using the system
> libagg by passing INTERNAL_LIBAGG=False to scons. That should allow some of
your patching to be dropped.

 Thats nice, I will take care of it for next stable upstream.

>I know. Aside from anything else I wrote the cairo stuff... OpenStreetMap is
>running with libicu and cairo support, so it can't that unstable. We're about
>to update to the latest svn head in fact.

  If 0.5.2 or other major is issued I will, see no sense ATM, simply
frustrated with #103 trac ticket which render all shipped demo unusable,
and looking in trunk https://trac.mapnik.org/browser/trunk/plugins/input/shape
I can't see for now relevant code change for the issue since my last 
trunk trial.


> Perhaps if you just tell us what problem you're having we can fix it!
> Tom

> I'm not aware of any plans for mapnik to become an osgeo project, and I don't
> see it listed on the incubator, so I'm not sure where you're getting that
> information from.

  At this point I might be dissinformed, however overall isn't a bad idea.

Please look at this most one: 
https://trac.mapnik.org/ticket/103

  Olso, actual .spec will stay as-is until next upstream release,
i simply cannot do more than better magic for now, its not possible.

//cristian


 

> The work that you have done so far is great and I'm both grateful and relieved
> that someone else took up the challenge. However please send your patches
> upstream - you have still yet to make any comments on the development mailing
> list for this project - they can then be merged into the stable branch as
> suggested. I have found them to be extremely receptive and responsive to what I
> have sent. Sending patches upstream is one of the core principles of packaging
> for Fedora:
> 
> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> 
> I would urge you to convert the sed processing and other code-munging present in
> the .spec file into a patch and post it to the relevant list.
> 
> Regards
> Chris
> 

Chirs,

  I wish too to be so magical to fix evrything in this minute, but I
am afraid its not possible. First trac ticket #103 render all shiped
demo unusable for our mapnik, its annoying for this package to not have those
nice demos, second i still don't worked out a working patch so lets see upstream
 what have to say too for this issue, third I have to carry sed/grep 
workarounds since they are higly visible in the .spec but I olso want to get rid
of them ASAP by colaborate upsteam. I dislike patches for build infra (Makfiles,
scons, automagic stuff), but _totaly_ agree and follow tham only for source code
(c++/c/.py) for same reason as spot article says it, olso I always behave to
submitt relevant functional source code patch upstream. 
  With build infrastructure patch, I carry tham as sed/grep hacks as i explained.

  Its not the first one package which carry workarounds like this way,
please look at grass package, its simply terrifying one due to many arches and
OS supported upstream, upstream folk are pretty complex and its extremly hard
booth for tham and me to merge tham ATM, olso understood from tham that they
not focus only for particular distro e.g. fedora but for global functionality.
  Or, e.g lets take ogdi (another GIS) wich I maintain even upstream, simply
cannot get the time to rewrote a nice autoconf/automake to get rid of ugly hacks
due to fact that I have to issue a MS-VS project file wich i cannot deal,
and be aware of multiple unixes than, olso spent lot of time to clean license
and rewrote chunks, so for upstream could be hard too, not only for fedora
packager which can easily say "this/that I dont like".

 Chirs i agree, but its hard, and yes I am all to willing.

> I have found them to be extremely receptive and responsive to what 

Chris, Tom (Hughes),

 Yes, regarding receptivness, true. Nice to see comments even in this review
thread. Appologise for not moving earlyear to their -devel list, but
out of my experience and frustration I would needed some time to spend for 
dive in deeper in this packages before move to -devel, olso wanted silently to
watch next release commitment from their side to decide scons vs autoconf and
see libicu insted -liconv, see how cairo is dragged in, and other of my dilema,
olso I beheve to be higly sceptic to "receptivnes" due to past hard experience
with other folks, so now I am more than happy to see movement like this from e.g
Tom side.

  I go with this 0.5.1 since please to not forget Taska's real effort and ours,
we invested noticable time for this review and this particular package
configuration, I kindly tried SVN but at that time (~3weeks) wasn't suitable,
and didn't solve trac#103 too, so I decided stay 0.5.1 at all with this review.

Tasaka,

  Is Tom Callaway aviable to review that data license ?


/Cristian.

Well, I thought (and perhaps this is correct) that spot is watching all FE-Legal blockers,
however for now I explicitly add spot to CC list.

Spot, would you review the license in the comment 24 (which is the same as
http://geogratis.cgdi.gc.ca/geogratis/en/licence.jsp )?

Sorry for the delay. The GeoGratis License Agreement For Unrestricted Use Of Digital Data is Free, and has been added to the list of acceptable content licenses. Please use: 

  License: GeoGratis

Lifting FE-Legal.

Thanks, spot!!

Now I can approve this package. Please fix the license tag to "GPLv2+ and GeoGratis"
on -demo when you import this package into Fedora CVS.

---------------------------------------------------------------------
    This package (mapnik) is APPROVED by mtasaka
---------------------------------------------------------------------

Thanks for this Mamoru.

As Balint Cristian has done the heavy lifting on this one, what is the best way to import this? As owner of this bug do I have to do the import then pass it on to him or can he do the initial import?

I am away for one week so won't be able to do much until then anyway however I am happy for whoever to take ownership to get the ball rolling sooner.

Cheers
Chris

New Package CVS Request
=======================
Package Name: mapnik
Short Description: a Free toolkit for developing mapping applications
Owners: rezso
Branches: F-8 F-9 devel
InitialCC: snecklifter

I would add Chris Brown too as Owner, but we must know his fedoraid, so
far i added him as watcher CC.

(In reply to comment #45)
> I would add Chris Brown too as Owner, but we must know his fedoraid, so
> far i added him as watcher CC.

Fedoraid is snecker

cvs done. 

I added snecker as co-maintainer. Feel free to adjust via the pkgdb web interface or reset the fedora-cvs flag if you need further changes.

(In reply to comment #42)
> Thanks, spot!!
> 
> Now I can approve this package. Please fix the license tag to "GPLv2+ and
> GeoGratis"
> on -demo when you import this package into Fedora CVS.
> 
> ---------------------------------------------------------------------
>     This package (mapnik) is APPROVED by mtasaka
> ---------------------------------------------------------------------

License: GPLv2+ GeoGratis

[done]