NEW: geo/osm2pgsql

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

NEW: geo/osm2pgsql

patrick keshishian
Any interest in this port? I need it for a project. Got it built on amd64
and been testing it with an extract dump from BBBike.org. I'll be
expanding my tests as the project progresses.

Things I had to tweak:
- configure.ac
  . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
  . add --without-lua option. Lua is option its README says. I
    figure this should be a FLAVOR
- Fixed a few warnings about printf() format strings.
- Fixed one warning about unused variable as it ends up inside
  an #ifdef not compiled.

After comments here I'll try and see how much of these changes
upstream may accept.

Any comments? Did I miss stuff? etc.

Thanks,
--patrick

geo_osm2pgsql.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Fri, Sep 11, 2015 at 12:27:40AM -0700, patrick keshishian wrote:

> Any interest in this port? I need it for a project. Got it built on amd64
> and been testing it with an extract dump from BBBike.org. I'll be
> expanding my tests as the project progresses.
>
> Things I had to tweak:
> - configure.ac
>   . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
>   . add --without-lua option. Lua is option its README says. I
>     figure this should be a FLAVOR
> - Fixed a few warnings about printf() format strings.
> - Fixed one warning about unused variable as it ends up inside
>   an #ifdef not compiled.
>
> After comments here I'll try and see how much of these changes
> upstream may accept.
>
> Any comments? Did I miss stuff? etc.

Yes, there's interest in this - i thought we already had it but it was
osm2pgrouting which got recently imported. I'm a bit surprised that
all the deps are BDEPs, how is linking done ?
Technically im not sure you need a RDEP on postgis, since you could be
targetting a postgis db on a remote host....

Anyway, i'll look into this deeper nextnext weekend.

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
On 9/11/15, Landry Breuil <[hidden email]> wrote:

> On Fri, Sep 11, 2015 at 12:27:40AM -0700, patrick keshishian wrote:
>> Any interest in this port? I need it for a project. Got it built on amd64
>> and been testing it with an extract dump from BBBike.org. I'll be
>> expanding my tests as the project progresses.
>>
>> Things I had to tweak:
>> - configure.ac
>>   . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
>>   . add --without-lua option. Lua is option its README says. I
>>     figure this should be a FLAVOR
>> - Fixed a few warnings about printf() format strings.
>> - Fixed one warning about unused variable as it ends up inside
>>   an #ifdef not compiled.
>>
>> After comments here I'll try and see how much of these changes
>> upstream may accept.
>>
>> Any comments? Did I miss stuff? etc.
>
> Yes, there's interest in this - i thought we already had it but it was
> osm2pgrouting which got recently imported.

I thought the same and was surprised there wasn't a port
already.

> I'm a bit surprised that
> all the deps are BDEPs, how is linking done ?

I see what you mean. Is there a "tool" within the ports
infrastructure that helps sort this stuff out?

I'll revisit the porter's guide sometime tomorrow and may
have a new tar-ball by the weekend.

> Technically im not sure you need a RDEP on postgis, since you could be
> targetting a postgis db on a remote host....

That's correct.

> Anyway, i'll look into this deeper nextnext weekend.

Thanks,

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Fri, Sep 11, 2015 at 01:05:56AM -0700, patrick keshishian wrote:

> On 9/11/15, Landry Breuil <[hidden email]> wrote:
> > On Fri, Sep 11, 2015 at 12:27:40AM -0700, patrick keshishian wrote:
> >> Any interest in this port? I need it for a project. Got it built on amd64
> >> and been testing it with an extract dump from BBBike.org. I'll be
> >> expanding my tests as the project progresses.
> >>
> >> Things I had to tweak:
> >> - configure.ac
> >>   . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
> >>   . add --without-lua option. Lua is option its README says. I
> >>     figure this should be a FLAVOR
> >> - Fixed a few warnings about printf() format strings.
> >> - Fixed one warning about unused variable as it ends up inside
> >>   an #ifdef not compiled.
> >>
> >> After comments here I'll try and see how much of these changes
> >> upstream may accept.
> >>
> >> Any comments? Did I miss stuff? etc.
> >
> > Yes, there's interest in this - i thought we already had it but it was
> > osm2pgrouting which got recently imported.
>
> I thought the same and was surprised there wasn't a port
> already.
>
> > I'm a bit surprised that
> > all the deps are BDEPs, how is linking done ?
>
> I see what you mean. Is there a "tool" within the ports
> infrastructure that helps sort this stuff out?
>
> I'll revisit the porter's guide sometime tomorrow and may
> have a new tar-ball by the weekend.

make port-lib-depends-check will tell you :)

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
On 9/11/15, Landry Breuil <[hidden email]> wrote:

> On Fri, Sep 11, 2015 at 01:05:56AM -0700, patrick keshishian wrote:
>> On 9/11/15, Landry Breuil <[hidden email]> wrote:
>> > On Fri, Sep 11, 2015 at 12:27:40AM -0700, patrick keshishian wrote:
>> >> Any interest in this port? I need it for a project. Got it built on
>> >> amd64
>> >> and been testing it with an extract dump from BBBike.org. I'll be
>> >> expanding my tests as the project progresses.
>> >>
>> >> Things I had to tweak:
>> >> - configure.ac
>> >>   . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
>> >>   . add --without-lua option. Lua is option its README says. I
>> >>     figure this should be a FLAVOR
>> >> - Fixed a few warnings about printf() format strings.
>> >> - Fixed one warning about unused variable as it ends up inside
>> >>   an #ifdef not compiled.
>> >>
>> >> After comments here I'll try and see how much of these changes
>> >> upstream may accept.
>> >>
>> >> Any comments? Did I miss stuff? etc.
>> >
>> > Yes, there's interest in this - i thought we already had it but it was
>> > osm2pgrouting which got recently imported.
>>
>> I thought the same and was surprised there wasn't a port
>> already.
>>
>> > I'm a bit surprised that
>> > all the deps are BDEPs, how is linking done ?
>>
>> I see what you mean. Is there a "tool" within the ports
>> infrastructure that helps sort this stuff out?
>>
>> I'll revisit the porter's guide sometime tomorrow and may
>> have a new tar-ball by the weekend.
>
> make port-lib-depends-check will tell you :)
Thanks for the hints, now both portcheck and port-lib-depends-check
pass.

Does the Makefile look better? I think it is headed toward a more
correct direction.

--patrick


Pasted here for easier review (but also in attached archive).

--- 8< -------------------------------------------------------------------------
# $OpenBSD$

COMMENT = OSM data to PostgreSQL converter

GH_TAGNAME = 0.88.1
GH_PROJECT = osm2pgsql
GH_ACCOUNT = openstreetmap
REVISION = 0

DISTNAME = osm2pgsql-${GH_TAGNAME}
CATEGORIES = geo databases

HOMEPAGE = http://wiki.openstreetmap.org/wiki/Osm2pgsql

# Not sure
#MAINTAINER = patrick keshishian <[hidden email]>

# GPLv2
PERMIT_PACKAGE_CDROM = Yes

CONFIGURE_STYLE = autoconf
AUTOMAKE_VERSION = 1.14
AUTOCONF_VERSION = 2.69

USE_GMAKE = Yes

WANTLIB += boost_filesystem boost_system boost_system-mt
WANTLIB += boost_thread-mt bz2 c crypto geos iconv lzma
WANTLIB += m pq proj protobuf-c pthread ssl stdc++ xml2 z

MODULES = converters/libiconv \
                        databases/postgresql \

LIB_DEPENDS = databases/postgresql \
                        devel/proj \
                        devel/protobuf-c \
                        geo/geos \
                        textproc/libxml \
                        devel/boost \

BUILD_DEPENDS = devel/gmake \
                        devel/libtool \


# XXX TODO lua flavor (optional)
FLAVORS = lua
FLAVOR ?=

.if ${FLAVOR:Mlua}
MODULES += lang/lua
.else
CONFIGURE_ARGS += --without-lua
.endif

post-patch:
        cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
                AUTOCONF_VERSION=${AUTOCONF_VERSION} \
                AUTOMAKE_VERSION=${AUTOMAKE_VERSION}\
                autoreconf -vfi

.include <bsd.port.mk>
------------------------------------------------------------------------- >8 ---

geo_osm2pgsql.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Daniel Jakots
On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
<[hidden email]> wrote:

> Does the Makefile look better? I think it is headed toward a more
> correct direction.

Hi,

I tried to build it, I had an error, but Patrick quickly sent me a new
Makefile (attached), I could build it without problem then. I imported a
bunch of osm data in a pgsql database to test, I had the same output
that I usually have on Ubuntu so I guess it's good.

Thanks for the port!

Cheers,
Daniel


Makefile (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
On 9/12/15, Daniel Jakots <[hidden email]> wrote:

> On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
> <[hidden email]> wrote:
>
>> Does the Makefile look better? I think it is headed toward a more
>> correct direction.
>
> Hi,
>
> I tried to build it, I had an error, but Patrick quickly sent me a new
> Makefile (attached), I could build it without problem then. I imported a
> bunch of osm data in a pgsql database to test, I had the same output
> that I usually have on Ubuntu so I guess it's good.
>
> Thanks for the port!
>
> Cheers,
> Daniel
Thanks for your test and report Daniel.

Attached the new tar-ball.

--patrick

geo_osm2pgsql.tar.gz (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:

> On 9/12/15, Daniel Jakots <[hidden email]> wrote:
> > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
> > <[hidden email]> wrote:
> >
> >> Does the Makefile look better? I think it is headed toward a more
> >> correct direction.
> >
> > Hi,
> >
> > I tried to build it, I had an error, but Patrick quickly sent me a new
> > Makefile (attached), I could build it without problem then. I imported a
> > bunch of osm data in a pgsql database to test, I had the same output
> > that I usually have on Ubuntu so I guess it's good.
> >
> > Thanks for the port!
> >
> > Cheers,
> > Daniel
>
> Thanks for your test and report Daniel.
>
> Attached the new tar-ball.

After actually looking into it...

- you have a typo in the patch adding without-lua to configure.ac... but
  since this wasnt a build option provided by upstream, why bother with
adding it and doing a flavor for this? i mean, lua dependency isnt
usually big, and since it provides quite some useful features
(scriptable tag transforming ?) why not enabling it by default ?

- REVISION should be removed, no need to start at 0

- devel/gmake doesnt need to got to BDEP, it's usually done with USE_GMAKE=Yes

- make check fails here:
tests/middle-tests.cpp:7:17: error: tuple: Fichier ou répertoire introuvable
tests/middle-tests.cpp: In function 'int test_node_set(middle_t*)':
tests/middle-tests.cpp:54: warning: comparison between signed and unsigned integer expressions
tests/middle-tests.cpp: In function 'int test_nodes_comprehensive_set(middle_t*)':
tests/middle-tests.cpp:79: error: 'class expected_nodelist_t' has no member named 'emplace_back'

Tried installing libpqxx (as a potential candidate for providing tuple
header) but that didnt help... installing g++ 4.9 didnt help either.
Did you run the tests ?

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Thu, Sep 17, 2015 at 11:44:12PM +0200, Landry Breuil wrote:

> On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
> > On 9/12/15, Daniel Jakots <[hidden email]> wrote:
> > > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
> > > <[hidden email]> wrote:
> > >
> > >> Does the Makefile look better? I think it is headed toward a more
> > >> correct direction.
> > >
> > > Hi,
> > >
> > > I tried to build it, I had an error, but Patrick quickly sent me a new
> > > Makefile (attached), I could build it without problem then. I imported a
> > > bunch of osm data in a pgsql database to test, I had the same output
> > > that I usually have on Ubuntu so I guess it's good.
> > >
> > > Thanks for the port!
> > >
> > > Cheers,
> > > Daniel
> >
> > Thanks for your test and report Daniel.
> >
> > Attached the new tar-ball.
>
> After actually looking into it...
>
> - you have a typo in the patch adding without-lua to configure.ac... but
>   since this wasnt a build option provided by upstream, why bother with
> adding it and doing a flavor for this? i mean, lua dependency isnt
> usually big, and since it provides quite some useful features
> (scriptable tag transforming ?) why not enabling it by default ?
>
> - REVISION should be removed, no need to start at 0
>
> - devel/gmake doesnt need to got to BDEP, it's usually done with USE_GMAKE=Yes

As for the autohell stuff, please use MODGNU_AUTOMAKE_DEPENDS &
MODGNU_AUTOCONF_DEPENDS as everywhere else.

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
Hi,

On 9/17/15, Landry Breuil <[hidden email]> wrote:

> On Thu, Sep 17, 2015 at 11:44:12PM +0200, Landry Breuil wrote:
>> On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
>> > On 9/12/15, Daniel Jakots <[hidden email]> wrote:
>> > > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
>> > > <[hidden email]> wrote:
>> > >
>> > >> Does the Makefile look better? I think it is headed toward a more
>> > >> correct direction.
>> > >
>> > > Hi,
>> > >
>> > > I tried to build it, I had an error, but Patrick quickly sent me a
>> > > new
>> > > Makefile (attached), I could build it without problem then. I imported
>> > > a
>> > > bunch of osm data in a pgsql database to test, I had the same output
>> > > that I usually have on Ubuntu so I guess it's good.
>> > >
>> > > Thanks for the port!
>> > >
>> > > Cheers,
>> > > Daniel
>> >
>> > Thanks for your test and report Daniel.
>> >
>> > Attached the new tar-ball.
>>
>> After actually looking into it...
>>
>> - you have a typo in the patch adding without-lua to configure.ac... but
>>   since this wasnt a build option provided by upstream, why bother with
>> adding it and doing a flavor for this? i mean, lua dependency isnt
>> usually big, and since it provides quite some useful features
>> (scriptable tag transforming ?) why not enabling it by default ?

You are right. Making adjustments.

>> - REVISION should be removed, no need to start at 0
>>
>> - devel/gmake doesnt need to got to BDEP, it's usually done with
>> USE_GMAKE=Yes

OK.

> As for the autohell stuff, please use MODGNU_AUTOMAKE_DEPENDS &
> MODGNU_AUTOCONF_DEPENDS as everywhere else.

OK.

and currently working on the compile error you reported on
'make test' and hope to have a new tar-ball soon.

--patrick


> Landry
>
>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
In reply to this post by Landry Breuil-6
On 9/17/15, Landry Breuil <[hidden email]> wrote:

> On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
>> On 9/12/15, Daniel Jakots <[hidden email]> wrote:
>> > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
>> > <[hidden email]> wrote:
>> >
>> >> Does the Makefile look better? I think it is headed toward a more
>> >> correct direction.
>> >
>> > Hi,
>> >
>> > I tried to build it, I had an error, but Patrick quickly sent me a new
>> > Makefile (attached), I could build it without problem then. I imported
>> > a
>> > bunch of osm data in a pgsql database to test, I had the same output
>> > that I usually have on Ubuntu so I guess it's good.
>> >
>> > Thanks for the port!
>> >
>> > Cheers,
>> > Daniel
>>
>> Thanks for your test and report Daniel.
>>
>> Attached the new tar-ball.
>
> After actually looking into it...
>
> - you have a typo in the patch adding without-lua to configure.ac... but
>   since this wasnt a build option provided by upstream, why bother with
> adding it and doing a flavor for this? i mean, lua dependency isnt
> usually big, and since it provides quite some useful features
> (scriptable tag transforming ?) why not enabling it by default ?
>
> - REVISION should be removed, no need to start at 0
>
> - devel/gmake doesnt need to got to BDEP, it's usually done with
> USE_GMAKE=Yes
>
> - make check fails here:
> tests/middle-tests.cpp:7:17: error: tuple: Fichier ou répertoire
> introuvable
> tests/middle-tests.cpp: In function 'int test_node_set(middle_t*)':
> tests/middle-tests.cpp:54: warning: comparison between signed and unsigned
> integer expressions
> tests/middle-tests.cpp: In function 'int
> test_nodes_comprehensive_set(middle_t*)':
> tests/middle-tests.cpp:79: error: 'class expected_nodelist_t' has no member
> named 'emplace_back'
>
> Tried installing libpqxx (as a potential candidate for providing tuple
> header) but that didnt help... installing g++ 4.9 didnt help either.
> Did you run the tests ?
Your comment one libpqxx threw me for a wild-goose chase.
The intended <tuple> is from c++/4.9.3/tuple.

Attached is new tar-ball that compile, but unfortunately "make test"
mostly fails[1].

Most failures are due test DB not existing followed by core dump.
One hints of bad option.
One on Python module import.

I figure the last two should be easy to fix. The ones with DB not found
failures might be a bit tougher to figure out.

I'll look further at this later, but welcome any help or hints.

Thanks,
--patrick


[1] $ cat test-suite.log
========================================
   osm2pgsql 0.88.1: ./test-suite.log
========================================

# TOTAL: 18
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  14
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/test-middle-pgsql
=============================

./tests/test-middle-pgsql:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-28481-1442644086" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-middle-flat
============================

./tests/test-middle-flat:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-17708-1442644107" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-tags
==================================

./tests/test-output-multi-tags:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-10989-1442644127" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-line
==================================

./tests/test-output-multi-line:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-29667-1442644148" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-line-storage
==========================================

./tests/test-output-multi-line-storage:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-21058-1442644168" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-point
===================================

./tests/test-output-multi-point:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-26329-1442644189" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-point-multi-table
===============================================

./tests/test-output-multi-point-multi-table:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-11160-1442644209" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-polygon
=====================================

./tests/test-output-multi-polygon:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-23387-1442644230" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-poly-trivial
==========================================

./tests/test-output-multi-poly-trivial:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-24660-1442644251" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-pgsql
=============================

./tests/test-output-pgsql:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
test_regression_simple
NOTICE:  database "osm2pgsql-test-26783-1442644271" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-pgsql-z_order
=====================================

./tests/test-output-pgsql-z_order:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
test_z_order
NOTICE:  database "osm2pgsql-test-5252-1442644291" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-pgsql-tablespace
========================================

./tests/test-output-pgsql-tablespace:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
test_regression_simple
NOTICE:  database "osm2pgsql-test-7653-1442644312" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-parse-options
==============================

./tests/test-parse-options:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
test_insufficient_args
terminate called after throwing an instance of 'std::runtime_error'
  what():  Usage error. For further information see:
        osm2pgsql -h|--help

Abort trap (core dumped)

FAIL: tests/regression-test
===========================

Traceback (most recent call last):
  File "tests/regression-test.py", line 4, in <module>
    import psycopg2
ImportError: No module named psycopg2

geo_osm2pgsql.tar.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:

> On 9/17/15, Landry Breuil <[hidden email]> wrote:
> > On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
> >> On 9/12/15, Daniel Jakots <[hidden email]> wrote:
> >> > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
> >> > <[hidden email]> wrote:
> >> >
> >> >> Does the Makefile look better? I think it is headed toward a more
> >> >> correct direction.
> >> >
> >> > Hi,
> >> >
> >> > I tried to build it, I had an error, but Patrick quickly sent me a new
> >> > Makefile (attached), I could build it without problem then. I imported
> >> > a
> >> > bunch of osm data in a pgsql database to test, I had the same output
> >> > that I usually have on Ubuntu so I guess it's good.
> >> >
> >> > Thanks for the port!
> >> >
> >> > Cheers,
> >> > Daniel
> >>
> >> Thanks for your test and report Daniel.
> >>
> >> Attached the new tar-ball.
> >
> > After actually looking into it...
> >
> > - you have a typo in the patch adding without-lua to configure.ac... but
> >   since this wasnt a build option provided by upstream, why bother with
> > adding it and doing a flavor for this? i mean, lua dependency isnt
> > usually big, and since it provides quite some useful features
> > (scriptable tag transforming ?) why not enabling it by default ?
> >
> > - REVISION should be removed, no need to start at 0
> >
> > - devel/gmake doesnt need to got to BDEP, it's usually done with
> > USE_GMAKE=Yes
> >
> > - make check fails here:
> > tests/middle-tests.cpp:7:17: error: tuple: Fichier ou répertoire
> > introuvable
> > tests/middle-tests.cpp: In function 'int test_node_set(middle_t*)':
> > tests/middle-tests.cpp:54: warning: comparison between signed and unsigned
> > integer expressions
> > tests/middle-tests.cpp: In function 'int
> > test_nodes_comprehensive_set(middle_t*)':
> > tests/middle-tests.cpp:79: error: 'class expected_nodelist_t' has no member
> > named 'emplace_back'
> >
> > Tried installing libpqxx (as a potential candidate for providing tuple
> > header) but that didnt help... installing g++ 4.9 didnt help either.
> > Did you run the tests ?
>
> Your comment one libpqxx threw me for a wild-goose chase.
> The intended <tuple> is from c++/4.9.3/tuple.
>
> Attached is new tar-ball that compile, but unfortunately "make test"
> mostly fails[1].

Yes, but at least it builds :) Lots of ports have failing tests in the
tree..

> Most failures are due test DB not existing followed by core dump.

Hmm, maybe have a look at databases/postgresql MODULE and the ports that
use it, the module provides helpers to run/create databases for testing.

> One hints of bad option.

This one is strange..

> One on Python module import.

Needs TEST_DEPENDS on databases/py-psycopg2

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
In reply to this post by patrick keshishian
On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:

> On 9/17/15, Landry Breuil <[hidden email]> wrote:
> > On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
> >> On 9/12/15, Daniel Jakots <[hidden email]> wrote:
> >> > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
> >> > <[hidden email]> wrote:
> >> >
> >> >> Does the Makefile look better? I think it is headed toward a more
> >> >> correct direction.
> >> >
> >> > Hi,
> >> >
> >> > I tried to build it, I had an error, but Patrick quickly sent me a new
> >> > Makefile (attached), I could build it without problem then. I imported
> >> > a
> >> > bunch of osm data in a pgsql database to test, I had the same output
> >> > that I usually have on Ubuntu so I guess it's good.
> >> >
> >> > Thanks for the port!
> >> >
> >> > Cheers,
> >> > Daniel
> >>
> >> Thanks for your test and report Daniel.
> >>
> >> Attached the new tar-ball.
> >
> > After actually looking into it...
> >
> > - you have a typo in the patch adding without-lua to configure.ac... but
> >   since this wasnt a build option provided by upstream, why bother with
> > adding it and doing a flavor for this? i mean, lua dependency isnt
> > usually big, and since it provides quite some useful features
> > (scriptable tag transforming ?) why not enabling it by default ?
> >
> > - REVISION should be removed, no need to start at 0
> >
> > - devel/gmake doesnt need to got to BDEP, it's usually done with
> > USE_GMAKE=Yes
> >
> > - make check fails here:
> > tests/middle-tests.cpp:7:17: error: tuple: Fichier ou répertoire
> > introuvable
> > tests/middle-tests.cpp: In function 'int test_node_set(middle_t*)':
> > tests/middle-tests.cpp:54: warning: comparison between signed and unsigned
> > integer expressions
> > tests/middle-tests.cpp: In function 'int
> > test_nodes_comprehensive_set(middle_t*)':
> > tests/middle-tests.cpp:79: error: 'class expected_nodelist_t' has no member
> > named 'emplace_back'
> >
> > Tried installing libpqxx (as a potential candidate for providing tuple
> > header) but that didnt help... installing g++ 4.9 didnt help either.
> > Did you run the tests ?
>
> Your comment one libpqxx threw me for a wild-goose chase.
> The intended <tuple> is from c++/4.9.3/tuple.
>
> Attached is new tar-ball that compile, but unfortunately "make test"
> mostly fails[1].
>
> Most failures are due test DB not existing followed by core dump.
> One hints of bad option.
> One on Python module import.
>
> I figure the last two should be easy to fix. The ones with DB not found
> failures might be a bit tougher to figure out.
>

Looking a bit more at the new version of the Makefile itself:

CONFIGURE_ENV += CC=egcc CXX=eg++ CPP=ecpp

This shouldnt be needed, using gcc4 module properly sets symlinks in
WRKDIR/bin so that they are used by default.

AUTO_ENV isnt a known/used idiom, and it seems strange to define this
just to use it once...

If the port itself builds fine with base toolchain, and only the testsuite
needs recent g++ headers, that's a bit sad to have the whole thing being
built with ports gcc ... maybe set NO_TEST with a comment ? Fix the
offending code using tuple header ? dunno.

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
In reply to this post by Landry Breuil-6
On 9/19/15, Landry Breuil <[hidden email]> wrote:
> On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
>> On 9/17/15, Landry Breuil <[hidden email]> wrote:
[...]

>> Attached is new tar-ball that compile, but unfortunately "make test"
>> mostly fails[1].
>
> Yes, but at least it builds :) Lots of ports have failing tests in the
> tree..
>
>> Most failures are due test DB not existing followed by core dump.
>
> Hmm, maybe have a look at databases/postgresql MODULE and the ports that
> use it, the module provides helpers to run/create databases for testing.
>
>> One hints of bad option.
>
> This one is strange..
>
>> One on Python module import.
>
> Needs TEST_DEPENDS on databases/py-psycopg2
After adding this, the tests which were FAILing change state to
SKIP. The error message relating to their SKIP state, indicated
PG template0 database encoding was ASCII vs expected UTF8.

Patching databases/postgresql/postgresql.port.mk[1] to accept
an encoding to be specified in port's Makefile. Now more tests
PASS:

# TOTAL: 18
# PASS:  6
# SKIP:  1
# XFAIL: 0
# FAIL:  11
# XPASS: 0
# ERROR: 0

Those which FAIL claim "Out of memory" (see attached test-suite.log).

I tried building with DEBUG="-g -O0", and the test results vary
slightly:

# TOTAL: 18
# PASS:  7
# SKIP:  2
# XFAIL: 0
# FAIL:  9
# XPASS: 0
# ERROR: 0

I can play with these tests later.

New tar-ball with suggested changes from Landry:
- Get rid of AUTO_ENV
- MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
  g++, gcc.
- TEST_DEPENDS = databases/py-psycopg2

My "hack" for ensuring test-PG database uses UTF8 encoding:
- MODPOSTGRESQL_TEST_PGENCODING = -E UTF8

Thoughts, comments, etc?

--patrick



[1] cvs diff -up postgresql.port.mk # also attached.
Index: postgresql.port.mk
===================================================================
RCS file: /cvs/ports/databases/postgresql/postgresql.port.mk,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 postgresql.port.mk
--- postgresql.port.mk 3 Aug 2015 07:42:30 -0000 1.5
+++ postgresql.port.mk 23 Sep 2015 02:49:29 -0000
@@ -1,4 +1,4 @@
-# $OpenBSD: postgresql.port.mk,v 1.5 2015/08/03 07:42:30 kirby Exp $
+# $OpenBSD: postgresql.port.mk,v 1.4 2015/07/19 12:42:20 zhuk Exp $
 #
 # Helps testing PostgreSQL-based software, no B/L/R-DEPS here.

@@ -19,6 +19,7 @@ MODPOSTGRESQL_TEST_TARGET = \
  rm -Rf ${_MODPOSTGRESQL_TEST_PGDATA}; \
  export ${ALL_TEST_ENV}; \
  ${LOCALBASE}/bin/initdb -D ${_MODPOSTGRESQL_TEST_PGDATA} \
+    ${MODPOSTGRESQL_TEST_PGENCODING} \
     -A trust --locale=C --nosync; \
  ${LOCALBASE}/bin/pg_ctl start -w -D ${_MODPOSTGRESQL_TEST_PGDATA} \
     -l ${WRKDIR}/pg-test.log \

databases_postgresql_postgresql.port.mk.diff (1K) Download Attachment
test-suite.log-without_DEBUG (11K) Download Attachment
test-suite.log-with_DEBUG (11K) Download Attachment
geo_osm2pgsql.tar.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
>> Needs TEST_DEPENDS on databases/py-psycopg2
>
> After adding this, the tests which were FAILing change state to
> SKIP. The error message relating to their SKIP state, indicated
> PG template0 database encoding was ASCII vs expected UTF8.
>
> Patching databases/postgresql/postgresql.port.mk[1] to accept
> an encoding to be specified in port's Makefile. Now more tests
> PASS:
>
> # TOTAL: 18
> # PASS:  6
> # SKIP:  1
> # XFAIL: 0
> # FAIL:  11
> # XPASS: 0
> # ERROR: 0
>
> Those which FAIL claim "Out of memory" (see attached test-suite.log).
>
> I tried building with DEBUG="-g -O0", and the test results vary
> slightly:
>
> # TOTAL: 18
> # PASS:  7
> # SKIP:  2
> # XFAIL: 0
> # FAIL:  9
> # XPASS: 0
> # ERROR: 0
>
> I can play with these tests later.
>
> New tar-ball with suggested changes from Landry:
> - Get rid of AUTO_ENV
> - MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
>   g++, gcc.
> - TEST_DEPENDS = databases/py-psycopg2
>
> My "hack" for ensuring test-PG database uses UTF8 encoding:
> - MODPOSTGRESQL_TEST_PGENCODING = -E UTF8
>
> Thoughts, comments, etc?


I think this is a problem, and I can't quite guess how this
became:

$ ldd /usr/local/bin/osm2pgsql | grep stdc++
        00001c0e00869000 00001c0e00d7f000 rlib 0    6   0
/usr/lib/libstdc++.so.57.0
        00001c0e48dcc000 00001c0e492fa000 rlib 0    1   0
/usr/local/lib/libestdc++.so.17.0


The libestdc++ (from /usr/local/lib) is because the port is
built using gcc 4.9.3, but where is the base libstdc++ coming
from?

Is it from a dependency port which was built using base compiler?

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
In reply to this post by patrick keshishian
On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:

> On 9/19/15, Landry Breuil <[hidden email]> wrote:
> > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
> >> On 9/17/15, Landry Breuil <[hidden email]> wrote:
> [...]
> >> Attached is new tar-ball that compile, but unfortunately "make test"
> >> mostly fails[1].
> >
> > Yes, but at least it builds :) Lots of ports have failing tests in the
> > tree..
> >
> >> Most failures are due test DB not existing followed by core dump.
> >
> > Hmm, maybe have a look at databases/postgresql MODULE and the ports that
> > use it, the module provides helpers to run/create databases for testing.
> >
> >> One hints of bad option.
> >
> > This one is strange..
> >
> >> One on Python module import.
> >
> > Needs TEST_DEPENDS on databases/py-psycopg2
>
> After adding this, the tests which were FAILing change state to
> SKIP. The error message relating to their SKIP state, indicated
> PG template0 database encoding was ASCII vs expected UTF8.
>
> Patching databases/postgresql/postgresql.port.mk[1] to accept
> an encoding to be specified in port's Makefile. Now more tests
> PASS:
>
> # TOTAL: 18
> # PASS:  6
> # SKIP:  1
> # XFAIL: 0
> # FAIL:  11
> # XPASS: 0
> # ERROR: 0
>
> Those which FAIL claim "Out of memory" (see attached test-suite.log).

What if you bump ulimit -d ?

> New tar-ball with suggested changes from Landry:
> - Get rid of AUTO_ENV
> - MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
>   g++, gcc.
> - TEST_DEPENDS = databases/py-psycopg2
>
> My "hack" for ensuring test-PG database uses UTF8 encoding:
> - MODPOSTGRESQL_TEST_PGENCODING = -E UTF8

I'll let vadim comment on this one but i think it should just be the
default in postgresql.port.mk, i'm not sure we need a new knob for this.
Few ports use this module, and they probably are all tested with UTFcrap anyway.

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Thu, Sep 24, 2015 at 07:50:15AM +0200, Landry Breuil wrote:

> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
> > On 9/19/15, Landry Breuil <[hidden email]> wrote:
> > > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
> > >> On 9/17/15, Landry Breuil <[hidden email]> wrote:
> > [...]
> > >> Attached is new tar-ball that compile, but unfortunately "make test"
> > >> mostly fails[1].
> > >
> > > Yes, but at least it builds :) Lots of ports have failing tests in the
> > > tree..
> > >
> > >> Most failures are due test DB not existing followed by core dump.
> > >
> > > Hmm, maybe have a look at databases/postgresql MODULE and the ports that
> > > use it, the module provides helpers to run/create databases for testing.
> > >
> > >> One hints of bad option.
> > >
> > > This one is strange..
> > >
> > >> One on Python module import.
> > >
> > > Needs TEST_DEPENDS on databases/py-psycopg2
> >
> > After adding this, the tests which were FAILing change state to
> > SKIP. The error message relating to their SKIP state, indicated
> > PG template0 database encoding was ASCII vs expected UTF8.
> >
> > Patching databases/postgresql/postgresql.port.mk[1] to accept
> > an encoding to be specified in port's Makefile. Now more tests
> > PASS:
> >
> > # TOTAL: 18
> > # PASS:  6
> > # SKIP:  1
> > # XFAIL: 0
> > # FAIL:  11
> > # XPASS: 0
> > # ERROR: 0
> >
> > Those which FAIL claim "Out of memory" (see attached test-suite.log).
>
> What if you bump ulimit -d ?

Hm, after actually looking at the log, it's coming from the default
value for --cache. When i tried osm2pgsql locally, with the default it
was *always* complaining about this so i had to use a lower value. Maybe
we should patch out in the code the default cache size so that it's more
system-friendly, instead of forcing the user to specify it.... and it
would fix the tests :)

Landry

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
In reply to this post by Landry Breuil-6
On 9/23/15, Landry Breuil <[hidden email]> wrote:

> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
>> On 9/19/15, Landry Breuil <[hidden email]> wrote:
>> > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
>> >> On 9/17/15, Landry Breuil <[hidden email]> wrote:
>> [...]
>> >> Attached is new tar-ball that compile, but unfortunately "make test"
>> >> mostly fails[1].
>> >
>> > Yes, but at least it builds :) Lots of ports have failing tests in the
>> > tree..
>> >
>> >> Most failures are due test DB not existing followed by core dump.
>> >
>> > Hmm, maybe have a look at databases/postgresql MODULE and the ports
>> > that
>> > use it, the module provides helpers to run/create databases for
>> > testing.
>> >
>> >> One hints of bad option.
>> >
>> > This one is strange..
>> >
>> >> One on Python module import.
>> >
>> > Needs TEST_DEPENDS on databases/py-psycopg2
>>
>> After adding this, the tests which were FAILing change state to
>> SKIP. The error message relating to their SKIP state, indicated
>> PG template0 database encoding was ASCII vs expected UTF8.
>>
>> Patching databases/postgresql/postgresql.port.mk[1] to accept
>> an encoding to be specified in port's Makefile. Now more tests
>> PASS:
>>
>> # TOTAL: 18
>> # PASS:  6
>> # SKIP:  1
>> # XFAIL: 0
>> # FAIL:  11
>> # XPASS: 0
>> # ERROR: 0
>>
>> Those which FAIL claim "Out of memory" (see attached test-suite.log).
>
> What if you bump ulimit -d ?
>
>> New tar-ball with suggested changes from Landry:
>> - Get rid of AUTO_ENV
>> - MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
>>   g++, gcc.
>> - TEST_DEPENDS = databases/py-psycopg2
>>
>> My "hack" for ensuring test-PG database uses UTF8 encoding:
>> - MODPOSTGRESQL_TEST_PGENCODING = -E UTF8
>
> I'll let vadim comment on this one but i think it should just be the
> default in postgresql.port.mk, i'm not sure we need a new knob for this.
> Few ports use this module, and they probably are all tested with UTFcrap
> anyway.

If the goal is to bring the tests results closer to all-PASS,
the test DB needs to be initdb-ed with '-E UTF8" option.

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

patrick keshishian
In reply to this post by Landry Breuil-6
On 9/23/15, Landry Breuil <[hidden email]> wrote:

> On Thu, Sep 24, 2015 at 07:50:15AM +0200, Landry Breuil wrote:
>> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
>> > On 9/19/15, Landry Breuil <[hidden email]> wrote:
>> > > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
>> > >> On 9/17/15, Landry Breuil <[hidden email]> wrote:
>> > [...]
>> > >> Attached is new tar-ball that compile, but unfortunately "make test"
>> > >> mostly fails[1].
>> > >
>> > > Yes, but at least it builds :) Lots of ports have failing tests in
>> > > the
>> > > tree..
>> > >
>> > >> Most failures are due test DB not existing followed by core dump.
>> > >
>> > > Hmm, maybe have a look at databases/postgresql MODULE and the ports
>> > > that
>> > > use it, the module provides helpers to run/create databases for
>> > > testing.
>> > >
>> > >> One hints of bad option.
>> > >
>> > > This one is strange..
>> > >
>> > >> One on Python module import.
>> > >
>> > > Needs TEST_DEPENDS on databases/py-psycopg2
>> >
>> > After adding this, the tests which were FAILing change state to
>> > SKIP. The error message relating to their SKIP state, indicated
>> > PG template0 database encoding was ASCII vs expected UTF8.
>> >
>> > Patching databases/postgresql/postgresql.port.mk[1] to accept
>> > an encoding to be specified in port's Makefile. Now more tests
>> > PASS:
>> >
>> > # TOTAL: 18
>> > # PASS:  6
>> > # SKIP:  1
>> > # XFAIL: 0
>> > # FAIL:  11
>> > # XPASS: 0
>> > # ERROR: 0
>> >
>> > Those which FAIL claim "Out of memory" (see attached test-suite.log).
>>
>> What if you bump ulimit -d ?
>
> Hm, after actually looking at the log, it's coming from the default
> value for --cache. When i tried osm2pgsql locally, with the default it
> was *always* complaining about this so i had to use a lower value. Maybe
> we should patch out in the code the default cache size so that it's more
> system-friendly, instead of forcing the user to specify it.... and it
> would fix the tests :)

Glad you suggested the patch, I wasn't sure if you'd like that
idea. My own tests work with "-C 300", anything above fails in
different manners; i.e., -C 400 fails more "silently" v -C 500.
I am, however, messing about with small .osm files ATM.

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: NEW: geo/osm2pgsql

Landry Breuil-6
On Thu, Sep 24, 2015 at 10:58:43AM -0700, patrick keshishian wrote:

> On 9/23/15, Landry Breuil <[hidden email]> wrote:
> > On Thu, Sep 24, 2015 at 07:50:15AM +0200, Landry Breuil wrote:
> >> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
> >> > On 9/19/15, Landry Breuil <[hidden email]> wrote:
> >> > > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
> >> > >> On 9/17/15, Landry Breuil <[hidden email]> wrote:
> >> > [...]
> >> > >> Attached is new tar-ball that compile, but unfortunately "make test"
> >> > >> mostly fails[1].
> >> > >
> >> > > Yes, but at least it builds :) Lots of ports have failing tests in
> >> > > the
> >> > > tree..
> >> > >
> >> > >> Most failures are due test DB not existing followed by core dump.
> >> > >
> >> > > Hmm, maybe have a look at databases/postgresql MODULE and the ports
> >> > > that
> >> > > use it, the module provides helpers to run/create databases for
> >> > > testing.
> >> > >
> >> > >> One hints of bad option.
> >> > >
> >> > > This one is strange..
> >> > >
> >> > >> One on Python module import.
> >> > >
> >> > > Needs TEST_DEPENDS on databases/py-psycopg2
> >> >
> >> > After adding this, the tests which were FAILing change state to
> >> > SKIP. The error message relating to their SKIP state, indicated
> >> > PG template0 database encoding was ASCII vs expected UTF8.
> >> >
> >> > Patching databases/postgresql/postgresql.port.mk[1] to accept
> >> > an encoding to be specified in port's Makefile. Now more tests
> >> > PASS:
> >> >
> >> > # TOTAL: 18
> >> > # PASS:  6
> >> > # SKIP:  1
> >> > # XFAIL: 0
> >> > # FAIL:  11
> >> > # XPASS: 0
> >> > # ERROR: 0
> >> >
> >> > Those which FAIL claim "Out of memory" (see attached test-suite.log).
> >>
> >> What if you bump ulimit -d ?
> >
> > Hm, after actually looking at the log, it's coming from the default
> > value for --cache. When i tried osm2pgsql locally, with the default it
> > was *always* complaining about this so i had to use a lower value. Maybe
> > we should patch out in the code the default cache size so that it's more
> > system-friendly, instead of forcing the user to specify it.... and it
> > would fix the tests :)
>
> Glad you suggested the patch, I wasn't sure if you'd like that
> idea. My own tests work with "-C 300", anything above fails in
> different manners; i.e., -C 400 fails more "silently" v -C 500.
> I am, however, messing about with small .osm files ATM.

Maybe to be brought upstream, but they probably dont care and like
having a greedy-memory behaviour on linux where limits are ...
mostly unlimited.

Re database encoding, i was meaning that the module could default to
create databases using UTFcrap, instead of the default SQL_ASCII we use
now. To be tested on the other ports using the module, but i doubt
there would be fallout.

Vadim ?

Landry

12