init script in RPMs

Hi,

Per recent discussions on the list, I'm planning to commit an init script 
into CVS.

I'd like to create a redhat/ directory and put the init script there.

Any objections on that?

Regards,
--
Devrim GUNDUZ 
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com.tr                      http://www.gunduz.org

[PATCH] fix typo

The attached patch fixes two typos in slon/confoptions.h

-Neil

_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://gborg.postgresql.org/mailman/listinfo/slony1-general

[PATCH] libpq detection on Win32/Mingw

Hi,

The attached patch fixes configure to detect libpq on Windows boxes.
Unfortunately it is necessary to explicitly specify the appropriate
options on the command line (with msys/unix style paths) because
pg_config returns semi-DOS style paths (such as
C:/msys/1.0/local/pgsql/include) which GCC doesn't like.

I haven't included an updated version of configure as I only have
autoconf 2.59 on Windows, and wasn't sure if an update would be
accepted. I can supply it if required though.

Regards, Dave

_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://gborg.postgresql.org/mailman/listinfo/slony1-general

[PATCH] Win32/Mingw build

Hi,

The attached patch (in addition to my earlier patch) configures the
build properly for Win32/Mingw. The following points should be noted.

- A Mingw/Msys PostgreSQL installation is required. pgInstaller doesn't
yet install all the required headers, and as previously noted, gcc seems
to barf on C:/path/to/file style paths. I do not anticipate this to be a
problem as I intend to eventually include a pre-built Slony with
pgInstaller so only developers will need to worry about this (and they
will probably already have the required enviroment for PostgreSQL
development anyway).

- Currently slon and slonik do not compile. These will need additional
porting. xxid and slony1_funcs do compile however, consequently this
patch obsoletes the /Win32 directory containing Andreas' pgxs makefiles.

- Failure of the posix signals test is noted with a warning, but not a
configure failure at this time to allow compilation of working
components, and porting of the rest.

As with my previous patch, I have not included an updated configure
script as I'm running autoconf 2.59. I can send it if required.

Regards, Dave

_______________________________________________
Slony1-general mailing list

Re: [Slony1-commit] By devrim: Move --with-docdir definition, it breaks builds in the

The following is not about this particular commit, but more general 
about what is going on.

Yesterday I got an "RC1" tarball from Chris, only to discover that the 
ducttape test_x_pgbench scripts don't finish any more. The database 
comparision at the end has been moved out into a script part that is 
sourced in, but the source syntax doesn't take parameters, at least not 
in a standard Bourne shell. The change responsible for that was done 
nearly a month ago and not discovered. This makes me wonder on how many 
platforms this change was tested.

Now we have changes to the build system AFTER the tree has been tagged 
as Release Candidate.

This is really not the way to ensure the quality of the upcoming 
release. I call this modus operandi a sure recipe for a release with a 
lot of trouble.

Chris, since the RC1 tarball was not uploaded thus far I suggest we fix 
the scripts, make sure they and the changes to the build system pass a 
decent number of different platforms and then "retag" (move the rc1 tag) 
for a new tarball.

Jan

On 6/2/2005 4:00 AM, CVS User Account wrote:

> Log Message:
> -----------
> 

Missing (?) files in GNUmakefile.in

Hi,

Is there any reason why we didn't include UPGRADING, HISTORY-1.1, INSTALL,
SAMPLE and UPGRADING files in GNUmakefile.in, among DISTFILES?

If we need to include, the attached very small patch fixes it.

Regards,
--
Devrim GUNDUZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com.tr                      http://www.gunduz.org

--- GNUmakefile.in.old	2005-06-02 11:01:17.377423851 +0300
+++ GNUmakefile.in	2005-06-02 11:02:06.028666207 +0300
 <at>  <at>  -17,6 +17,10  <at>  <at> 
   configure \
   COPYRIGHT \
   README \
+  UPGRADING \
+  HISTORY-1.1 \
+  INSTALL \	  
+  SAMPLE \
   Makefile \
   Makefile.global.in \
   GNUmakefile.in \

Missing (?) files in GNUmakefile.in

Hi,

Is there any reason why we didn't include UPGRADING, HISTORY-1.1, INSTALL,
SAMPLE and UPGRADING files in GNUmakefile.in, among DISTFILES?

If we need to include, the attached very small patch fixes it.

Regards,
--
Devrim GUNDUZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com.tr                      http://www.gunduz.org

--- GNUmakefile.in.old	2005-06-02 11:01:17.377423851 +0300
+++ GNUmakefile.in	2005-06-02 11:02:06.028666207 +0300
 <at>  <at>  -17,6 +17,10  <at>  <at> 
   configure \
   COPYRIGHT \
   README \
+  UPGRADING \
+  HISTORY-1.1 \
+  INSTALL \	  
+  SAMPLE \
   Makefile \
   Makefile.global.in \
   GNUmakefile.in \

[PATCH] Win32/Msys Ducttape tests

Hi,

The attached patch rewrites the ducttape tests during the build to work
correctly on Msys/MinGW on Win32. I am not a make expert by any stretch
of the imagination, so if there's a more appropriate way of doing this,
please let me know.

The following changes are made, provided $(host_os) == mingw32:

- xterm is replaced with /bin/rxvt as there is no xterm in Msys by
default.

- /bin/which is specified. Mingw has it's own 'which' in /mingw/bin,
however in my experience this often crashes. The Msys one is a simple
script that calls 'type -p $1' and works reliably. The order of these 2
directories in the path is affected by the value of $MSYSTEM, so it
seems easiest just to hard code the correct path.

Also, the following change seems reasonable for all platforms.

- Use psql's -o option to output data dumps to files in
compare_pgbench_dumps. This avoids using the pager which is likely to be
C:\windows\System32\more.com on Win32 and cannot handle more than 8MB of
data at once. Even the MinGW/Msys pager (less.exe) fails to work
properly, outputting spurious extra spaces thus requiring diff -b
instead of plain diff.

Regards, Dave.

[Bug 159382] NAMELEN too short in sgml stylesheet (fwd)

FYI...
---------- Forwarded message ----------
Date: Thu, 2 Jun 2005 09:07:31 -0400
From: bugzilla@...
To: devrim@...
Subject: [Bug 159382] NAMELEN too short in sgml stylesheet

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: NAMELEN too short in sgml stylesheet

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159382

twaugh@... changed:

            What    |Removed                     |Added
----------------------------------------------------------------------------
              Status|ASSIGNED                    |CLOSED
          Resolution|                            |RAWHIDE
    Fixed In Version|                            |1.0-27

------- Additional Comments From twaugh@...  2005-06-02 09:07
EST 
-------
Fixed in Fedora development, and so the next full release of Red Hat Enterprise
Linux will pick up the change.  I don't think this problem warrants an updated
package.

Re: [PATCH] Win32/Mingw build

Dave Page wrote:

>The attached patch (in addition to my earlier patch) configures the
>build properly for Win32/Mingw. The following points should be noted.
>  
>
I have added the two patches, and the emails, as README files, to the
Win32 directory.

If that's helpful to Win32 folk, that's great.

It is NOT the time and place now to try to integrate this into the build
proper, however easy that might prove to be.  (There are enough
challenges in handling the release already .)

Once we get 1.1 out, please feel free to come back and pester as needed
to get it put into the main build.  It looks as though it's not overly
frightening.  The main challenge would be that it's not clear that there
are people with suitable configuration to test it for win32 .

I'll see about adding it to the feature request list so that it isn't
forgotten.