On 03/27/2013 03:12 AM, Bernard Fouché wrote:
Le 26/03/2013 17:16, Kai Krueger a écrit :
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.
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.
I am also hopping to expand http://ci.openstreetmap.org/ 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.
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.
Kai
Hello Kai,
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).
I think that crash was a buffer overflow and should also now be fixed,
thanks to Jon spotting the error and the help of some people on the irc
channel #osm-dev. This bug was also introduced just 4 days days ago.
Normally mod_tile and renderd should be pretty stable with not many
bigger changes. So normally taking the latest SVN snapshot should work
fairly reliable. Unfortunately you seem to have hit just the two or
three days where I committed some bigger changes to help mod_tile scale
up to larger installations that caused some instability.
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.
Yes, the information is split into too many different wiki pages, which
makes keeping them updated pretty much an impossibility. I think that is
at least partly the reason why Richard started the webpage
switch2osm.org to have a single source of good documentation of how to
set things up. Of cause as any documentation (in OSM) there is also room
for improvement and expansion but I think that is probably the most up
to date and clear descriptions of how to set up the tile rendering
infrastructure. It could probably do with an equivalent description for
nominatim.
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.
Well, it is a system with many components. I always try to make the
installation process as easy as possible and improve the error messages
to more easily track down setup issues, but the fact that every single
linux distribution has its own set of versions of key components, has
different packaging systems, puts files into different locations and
therefore unique set of issues doesn't directly make that easier. And
that is without even touching other unix derivatives like freeBSD,
Solaris or Mac OSX, let alone Windows.
As mentioned I'd like to try and automate more of the testing on
different systems, but so far that infrastructure doesn't exist in OSM.
So all we have to go on at the moment are bug reports by people
If you have any suggestions on how to improve the situation further, I'd
be interested to here them.
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.
Well, for Ubuntu I have created the PPA packages as linked to on
switch2osm.org. Those try and take care of all the necessary steps as
much as possible. To the extent even that they make many default
decision on things and do other "magic setup steps" which violate the
official packaging guidelines. However, as mentioned above, it is
unfortunately difficult to create similar packages for all the different
systems, as there are simply not enough developers around to do that.
However, there are definitely things that can and should be improved,
and figuring out a better release process is clearly one of them.
Kai
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.
Bernard
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
