<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">On 03/27/2013 03:12 AM, Bernard Fouché
      wrote:<br>
    </div>
    <blockquote cite="mid:%3C5152B815.7030503@kuantic.com%3E"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <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>
    </blockquote>
    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.<br>
    <br>
    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. <br>
    <blockquote cite="mid:%3C5152B815.7030503@kuantic.com%3E"
      type="cite"> <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.</blockquote>
    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. <br>
    <blockquote cite="mid:%3C5152B815.7030503@kuantic.com%3E"
      type="cite"> 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>
    </blockquote>
    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.<br>
    <br>
    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
    <br>
    <br>
    If you have any suggestions on how to improve the situation further,
    I'd be interested to here them.<br>
    <blockquote cite="mid:%3C5152B815.7030503@kuantic.com%3E"
      type="cite"> <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>
    </blockquote>
    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.<br>
    <br>
    However, there are definitely things that can and should be
    improved, and figuring out a better release process is clearly one
    of them.<br>
    <br>
    Kai<br>
    <blockquote cite="mid:%3C5152B815.7030503@kuantic.com%3E"
      type="cite"> <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>
    </blockquote>
    <br>
  </body>
</html>