2004/08/18
IRC [00:26] *** tekbasse parted the chat.
IRC [00:30] *** tekbasse joined the chat.
IRC [03:01] *** frankie joined the chat.
IRC [03:42] *** zione joined the chat.
IRC [05:00] <zione> hi ! i am back. i tracked down all my problems related to nspostgres.so not loading libpq.so.3. they where related to /usr/local/pgsql being group-owned by a group which was secondary to the user i setuid'd to thru daemontools.
IRC [05:01] <zione> now i have a very last question, you might help me or direct to a more appropriate venue
IRC [05:02] <zione> the question is: why would nspostgres.so link statically rather than dinamically to libpq.so.3 ? i observed this difference on the same machine, according to what libpq.so.3 i would point to (thru POSTGRES makefile's arg).
IRC [05:03] <zione> obviously a statically linked nspostgres.so woulnd't incur my permissions problem. but that did throw more confusion about
IRC [05:04] <zione> ps: the permissions problem is also related to the aolserver version being prior to 4.0.6 as dossy pointed out this morning
IRC [06:28] <Dossy> howdy.
IRC [07:16] <zione> hi dossy
IRC [07:17] <zione> i'm trying to answer myself above... the difference seems to be related to something different across libpq.so.3 versions
IRC [07:18] <zione> i have the version which is included statically which reports (thru objdump) SYMBOT TABLES: no symbols, while the one which gets statically linked from nspostgres reports an awful lot of symbols.... i think i'm almost onto it
IRC [07:36] *** cnk parted the chat.
IRC [07:36] *** erph parted the chat.
IRC [07:36] *** cnk joined the chat.
IRC [07:36] *** erph joined the chat.
IRC [09:15] *** frankie parted the chat.
IRC [11:08] <Dossy> hey everyone
IRC [11:21] <jcollins> hiya
IRC [11:21] <Dossy> time to formulate a response to Zoran ...
IRC [11:26] <jcollins> that mailing list has blown up the last two days
IRC [11:31] <Dossy> full moon must be coming.
IRC [11:54] <jcollins> must be
IRC [12:02] <zione> please help
IRC [12:02] <jcollins> okay
IRC [12:03] <zione> now every time i compile nspostgres.so i get it statically linked to libpq.*
IRC [12:04] <zione> there is something i don't understand about that... is -lpq in makefile looking for what files ?
IRC [12:07] <zione> is it that if libpq.a is the only available it links statically against it and if there is libpq.so.3 as well it links dinamically against it (provided i'm using distribution makefile) ?
IRC [12:08] <zione> btw, is it here where I should ask about nspostgres.so ?
IRC [12:09] <jcollins> you could try asking on openacs.org forums too
IRC [12:09] <jcollins> but i'm sure somebody here would/will help if they know how
IRC [12:13] <zione> _they_ sent me here ;)... well it was some days ago, now my knowledge of the problem is a bit deeper... let's see what happens...
IRC [12:13] <zione> pardon, i misunderstood openacs.org forums for #openacs
IRC [12:14] <zione> anyway. maybe a post on the forum would be the right place
IRC [12:14] <zione> ok
IRC [12:20] <jcollins> who maintains nspostgres?
IRC [12:20] <jcollins> maybe ask them?
IRC [12:29] *** rubick joined the chat.
IRC [12:41] <zione> i thought nspostgres would be part of aolserver
IRC [12:41] <zione> anyway, i think i have myself the answer.
IRC [12:42] <zione> dynamic linking happens if libwhatever.so is found first in -L path. static if libwhatever.a is found first in that path. this is default behaviour.
IRC [12:42] <zione> does that make sense to you ?
IRC [12:52] <zione> ls -la
IRC [12:52] <zione> w/w
IRC [12:58] *** rubick parted the chat.
IRC [12:58] *** tekbasse parted the chat.
IRC [12:58] *** jcollins parted the chat.
IRC [12:58] *** Dossy parted the chat.
IRC [12:59] *** jcollins joined the chat.
IRC [13:00] *** rubick joined the chat.
IRC [13:00] *** tekbasse joined the chat.
IRC [13:00] *** Dossy joined the chat.
IRC [13:06] *** frodoroot joined the chat.
IRC [13:14] *** frankie joined the chat.
IRC [14:08] *** zione parted the chat.
IRC [14:11] *** GizmoBeastLives joined the chat.
IRC [14:14] <Dossy> Hey, Jamie.
IRC [14:15] <GizmoBeastLives> Hi
IRC [14:15] <Dossy> win32 build should be "fixed" now --
IRC [14:15] <Dossy> going to post another binary release up on SF in a minute.
IRC [14:15] <GizmoBeastLives> great, will give it a try soon
IRC [14:15] <Dossy> want to start tackling some of the other bugs.
IRC [14:15] <Dossy> Let me get your input: I'm torn about continuing to support this custom Tcl script. I'm seriously considering redoing this a NMAKE makefile.
IRC [14:16] <GizmoBeastLives> why would you do that?
IRC [14:17] <Dossy> Not sure ... the Tcl just feels a bit clumsy.
IRC [14:18] <Dossy> Maybe if others look at it and refactor or provide feedback, it can improve.
IRC [14:18] <GizmoBeastLives> I think it is kind of a nice idea actually
IRC [14:18] <GizmoBeastLives> Yeah, I haven't had time to really look at it in depth, I'd like to see if it can be easily extended to support all of the Win32-ready modules
IRC [14:18] <Dossy> Not the way it is currently, unfortunatley.
IRC [14:19] <Dossy> Well, it could be, if we add build rules for all the mdoules to this one script ...
IRC [14:19] <Dossy> Perhaps the ideal situation would be to replace the autoconf/makefile with this tcl script build mechanism entirely for ALL platforms.
IRC [14:19] <Dossy> then, each directory would have a build.tcl in it -- specific rules for building the source for that dir.
IRC [14:19] <Dossy> then, the master build.tcl in the root could be used to build various things
IRC [14:20] <Dossy> as it descends dirs, it could source in those subdirectory build.tcl files.
IRC [14:20] <Dossy> Adding a module would be just dropping it in as a subdir and using the master build.tcl
IRC [14:20] <Dossy> And the master build.tcl woudl detect platform, compiler, etc.
IRC [14:21] <GizmoBeastLives> that's kind of a nice idea, but would take a fair amount of work to get it working equally well across all platforms I think
IRC [14:22] <Dossy> Possibly.
IRC [14:22] <Dossy> I could pretty easily do Linux, Solaris and MacOS X -- as long as gcc can remain the requirement.
IRC [14:22] <GizmoBeastLives> one option I've been considering is to wrap the cvs checkout and build in a batch file and include it in the binary distribution
IRC [14:22] <Dossy> hmm.
IRC [14:22] <GizmoBeastLives> as well as make it available stand alone
IRC [14:23] <GizmoBeastLives> so that someone who needs to build could have the script checkout and build a reasonable configuration
IRC [14:23] <Dossy> Hmm.
IRC [14:23] <GizmoBeastLives> you don't sound convinced that this is a good idea :-)
IRC [14:23] <Dossy> Not decided either way.
IRC [14:24] <Dossy> What exactly would it build? All of the add-on modules?
IRC [14:24] <Dossy> Right now, you can do a cvs checkout; tclsh win32\build.tcl install INSTALLDIR=destination
IRC [14:24] <Dossy> although the install assumes TCL_DIR ...
IRC [14:25] <GizmoBeastLives> it would probably do the checkout of tcl and aolserver, including getting various modules from places other than sf when necessary,
IRC [14:25] <Dossy> brb.
IRC [14:25] <Dossy> Hmm.
IRC [14:25] <GizmoBeastLives> do the tcl build and then the aolserver + module build for debug and release
IRC [14:25] <Dossy> sounds interesting but sounds like a lot of work.
IRC [14:26] <GizmoBeastLives> the nightly build I've been working on is written in tcl, running on aolserver, and it does some of this. I wish SF would fix CVS...
IRC [14:27] <GizmoBeastLives> but there is an issue of bootstrapping there
IRC [14:30] <Dossy> anon CVS is busted, but yo have project CVS access don't you?
IRC [14:30] <GizmoBeastLives> anyway, if there is a stable archive of stable binary versions and the sources that built them, that would probably be sufficient for almost all win32 users (there are only a handful of us anyway)
IRC [14:31] <GizmoBeastLives> yeah, I do, but I wanted this system to use anon, otherwise, when someone gets the zipfile of sources the CVS dirs will have my username etc., and they won't be able to use them to diff or up
IRC [14:41] <Dossy> True.
IRC [14:41] <GizmoBeastLives> http://www.jamierasmussen.com/download/ now has a current Win32 build with a bunch of patches, extra modules, etc.
IRC [14:41] <Dossy> Are you using the build.tcl, or the MSVC project files?
IRC [14:42] <GizmoBeastLives> this is using my .NET 2003 solution files
IRC [14:42] <Dossy> aha. you doing some command-line build too?
IRC [14:42] <Dossy> brb
IRC [14:43] <GizmoBeastLives> with .NET 2003 you can choose to build the same solution files used by the GUI from the command line
IRC [14:43] <GizmoBeastLives> but as far as I can tell the free compiler doesn't support that
IRC [14:49] <Dossy> nope, free compiler can't use project workspaces.
IRC [15:15] <Dossy> Jamie, could you read this and give feedback: http://panoptic.com/wiki/aolserver/CVSCommitGuidelines
IRC [15:16] <Dossy> Still writing it, but there's enough to see if I'm being unreasonable or whatnot.
IRC [15:17] <tekbasse> Where can one read the cvs comments for aolserver?
IRC [15:18] <Dossy> what comments? commit logs?
IRC [15:18] <tekbasse> yeah.. sorry
IRC [15:18] <GizmoBeastLives> It sounds good to me
IRC [15:18] <GizmoBeastLives> the AOLserver.com mailing list page should maybe link to the AOLserver-SF archive
IRC [15:19] <Dossy> tekbasse: looks like SF's cvs web interface is broken, but it starts here: http://cvs.sourceforge.net/viewcvs.py/aolserver/
IRC [15:19] <Dossy> aolserver-sf archive too? Hmm.
IRC [15:19] <GizmoBeastLives> http://listserv.aol.com/archives/aolserver-sf.html
IRC [15:19] <tekbasse> okay, so it's not just me =)
IRC [15:19] <Dossy> tekbasse: nope :)
IRC [15:19] <Dossy> giz: thanks - adding now.
IRC [15:20] <GizmoBeastLives> in your CVS guidelines doc, can you also say how you determine if a feature request should be committed
IRC [15:21] <tekbasse> I think the comment about openssl not sharing keys is in the nsopenssl commit logs
IRC [15:27] <Dossy> yup
IRC [15:27] <Dossy> Jamie: that's going to be #4 on the list. :)
IRC [15:27] <Dossy> tekbasse - really? Interesting - let me grep.
IRC [15:27] <Dossy> I do remember seeing something about it, but can't remember where.
IRC [15:31] <Dossy> revision 1.59
IRC [15:31] <Dossy> date: 2003/08/30 15:26:37; author: scottg; state: Exp; lines: +33 -15
IRC [15:31] <Dossy> Fixed bug; multiple SSL contexts can now share the same certificate. Also,
IRC [15:31] <Dossy> multiple drivers now work for the same virtual server.
IRC [15:31] <Dossy> So, it looks like it SHOULD work.
IRC [15:33] <tekbasse> Dossy, good to know. thanks.
IRC [15:36] *** bart1 joined the chat.
IRC [15:37] *** bartt parted the chat.
IRC [15:40] *** frodoroot parted the chat.
IRC [16:24] *** tekbasse parted the chat.
IRC [16:31] <Dossy> bot, CVS commit guidelines are http://panoptic.com/wiki/aolserver/CVSCommitGuidelines
IRC [16:31] <Dossy> OK, the CVS commit guidelines are mostly done -- at least, this first draft. Can everyone take a peek and give me feedback?
IRC [16:53] *** frodoroot joined the chat.
IRC [17:03] <frodoroot> is anyone here clustering postgres?
IRC [17:12] <jhavard> using erserv?
IRC [17:12] <jhavard> or clustering on an index?
IRC [17:15] <jhavard> err, a particular column
IRC [18:09] <frodoroot> replicating the whole database across the internet in a master slave or dual master manner
IRC [18:15] *** frankie parted the chat.
IRC [18:53] <jhavard> which is replication and not clustering, wouldn't you say?
IRC [18:54] <jhavard> While I play with postgres exclusively, even daring to use cvs head for my toy web sites, I've yet to play with replication
IRC [18:55] <jhavard> mainly because I lack a few good machines to run it on.
IRC [19:01] *** frodoroot parted the chat.
IRC [20:14] *** rubick parted the chat.