[El] Re: proj, GDAL, MapServer, mod_geocache updated in testing

[Mathieu Baudier]

Hello,

another bunch of updates:

# mapserver
There was a php require (instead of php53) left, which has been fixed
in php-mapserver 5.6.6-2

# mod_geocache
Peter contributed the spec file for a newer version (0.3.1) which has
now been built and deployed to testing.

# tinyows
TinyOWS has been updated to 0.9.0 (thanks again Peter!)

Cheers,

Mathieu

On Mon, Apr 11, 2011 at 23:49, Mathieu Baudier <mbaudier at argeo.org> wrote:
> Hello,
>
> our release strategy is to concentrate significant updates of the
> ELGIS repositories around the minor releases of the Enterprise Linux
> platform (based on the CentOS releases).
>
> With CentOS 5.6 now available, here are already some important ones:
>
> # proj
> - proj now requires proj-epsg, as discussed here:
> http://www.osgeo.org/pipermail/el/2010-November/000161.html
> - proj-nad has been updated to 1.5
>
> # geos
> - has been rebuilt against EL 5.6 without changes
>
> # gdal
> - upgraded to 1.8.0
> - gdal-iioext removed
> => use 'yum remove gdal-iioext' if you have it installed
> - fixed multilibs conflict
> => no gdal-java.i386 and gdal-python.i386 anymore for x86_64, but
> gdal.386 and gdal.x86_64 now work together
> (many more details about GDAL at the end of this mail)
> Thanks to Nikolaos for his contribution!
>
> # mapserver
> - updated to 5.6.6
> - php bindings now use the php53 package introduced in EL 5.6
> Thanks to Peter for his contribution!
>
> # mod_geocache
> - upgraded to 0.2.1
> Thanks to Peter for his contribution!
>
> That would be great to push these packages to stable fairly quickly,
> so don't hesitate to test them over the next few weeks.
>
> I will now work on QGIS (the new version of the hplip package now
> requires sip which is conflicting with python26-sip... I will try to
> make python26-sip non conflicting with the original sip) and on some
> more experimental packages (osm2pgsql, mapnik, etc.)
>
> Cheers,
>
> Mathieu
>
> # More details about some choices around GDAL
>
> - upgraded to 1.8.0:
> After quite a few trials in various directions, I finally decided to
> update the 1.7.3 we were still working on because some features had
> been added (e.g. PCRaster) since the 1.7.2 version upon which Nikolaos
> based his work.
> But having the working version of Nikolaos was very helpful and helped
> me to solve some weird issues which had been introduced when trying to
> maintain a single spec file with Fedora. (see below for more details
> about the collaboration with Fedora)
>
> - gdal-iioext removed
> Together with Ralph, we reviewed in details the work that had been
> done around the Java bindings and realized that it was probably not
> necessary to have both gdal-java and gdal-iioext (wich was basically
> the same with patches from the imageio-ext project).
> Now, our approach is to maintain a single gdal-java, and make sure
> that it is compatible with imageio-ext since this will be what we will
> use for geotools, geoserver, etc.
> As usual, feel free to discuss this approach as long as they are still
> in the testing repo.
>
> - Collaboration with Fedora
> With regard to the tentative maintenance of a single spec file across
> Fedora, ELGIS and EPEL, we had reached a point where this was making
> an already complex spec file even more complex for everybody to
> maintain. The approach is now for Fedora to innovate much more freely
> and we will take care to merge their work, rather than trying to
> maintain a single spec file.
> Feel free to discuss this as well of course.
>
> NOTE: for the time being I have removed the ref manual generation and
> the automated test in order to fasten the build time.
> I also want to spend a bit more time digging into why some automated
> tests are failing (or, worse, hanging...) before deactivating them.
> This is pretty clear that not all will pass (there are quite a few
> TIFF failures probably related to the known issues with libtiff
> already discussed onb the list) but I would like to know more
> precisely which ones and ask the upstream developers.
> This would be interesting to know which features are not supported on
> our platform by leveraging upstream work on these tests.
>