<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 26/03/2013 17:16, Kai Krueger a
écrit :<br>
</div>
<blockquote cite="mid:5151C9C7.6050401@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
There have been some major refactorings a couple of days ago in
mod_tile / renderd to support new storage backends. That is when
the error you reported got introduced. So if you take a snapshot
from prior to March 23rd it should be more stable.<br>
<br>
However, Fedora seems to have upgraded to Apache 2.4, and until a
commit 2 days ago, mod_tile had build issues as the apache 2.4 and
2.2 apis are not compatible.<br>
<br>
I am also hopping to expand
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true" href="http://ci.openstreetmap.org/">http://ci.openstreetmap.org/</a>
to provide automatic (build) testing on a variety of different
platforms, including Fedora 18, so that errors with
incompatibilities between systems can be spotted faster.<br>
<br>
So far there are no releases or stable branches of mod_tile /
renderd or osm2pgsql. However, as things mature and more and more
people rely on them, it is time to have a more proper release
process for these software.<br>
<br>
Kai<br>
</blockquote>
<br>
Hello Kai,<br>
<br>
I stopped using renderd because of the crashes I got (it can be a
thread race condition bug since the bug disappears when running
renderd with valgrind).<br>
<br>
I fully agree about the need of a real release process: it took me
many days to figure how to have Nominatim and Tirex running, mainly
because the information is split in different wiki pages written
from 2010 to early 2013 (I ignored ealier info) and none of them
reports the release numbers used when wiki entries were written. One
also have to search in mailing list to fix issues that show up one
after the other. It was a painful road, nearly each step of the
installation brings a new step that does not work at first, it may
be necessary to backtrack to some earlier step, change of
version/package, retry, etc.<br>
<br>
For instance F18 provides postgreql 9.2 but postgis 1.5: one has to
get postgis 2 but also to apply legacy.sql, bring stuff from mapnik
source code, get files (like coastlines) from here and there, figure
how to configure postgresql (that I never used before) etc.<br>
<br>
I'm actually trying to configure a secondary system to check that I
didn't forget to note something, to be able to reinstall a system if
this is needed in the future: I have currently a list of about *60*
different things to do one after the other and I still have to add
Tirex setup (and pray that the resulting system is a working one). I
have to save copies of the versions of the different projects to be
sure of what I use since I can't rely on stable versions of
different components. And if someone is using that list in a couple
of weeks, some parts will have to be updated/rechecked etc. so the
installation is messy at best.<br>
<br>
Bernard<br>
<br>
</body>
</html>