Joshua D. Drake wrote:
> I don't know about that because I am hoping to start provided .debs as
> well and
> .debs are going to be at a minimum /linux/debs/ubuntu
and /linux/debs/debian
But Debian packages are not only available on Linux. (The same is
reportedly true of RPM, but I don't know o
Peter Eisentraut wrote:
Joshua D. Drake wrote:
/pub/mirrors/postgresql/binary/v8.1.1/linux/rpms
227 Entering Passive Mode (128,111,24,43,254,97).
150 Opening ASCII mode data connection for file list
drwxr-xr-x 7 ftp ftp 512 Dec 13 15:35 fedora
drwxr-xr-x 8 ftp ftp
Joshua D. Drake wrote:
> /pub/mirrors/postgresql/binary/v8.1.1/linux/rpms
>
> 227 Entering Passive Mode (128,111,24,43,254,97).
> 150 Opening ASCII mode data connection for file list
> drwxr-xr-x 7 ftp ftp 512 Dec 13 15:35 fedora
> drwxr-xr-x 8 ftp ftp 512 Dec 17
Hi,
On Mon, 19 Dec 2005, Peter Eisentraut wrote:
1. Adjust the description of the pgfoundry project pgsqlrpms to
something like "This project aims to build PostgreSQL RPMS for Red Hat
and Fedora and maintain them."
Done.
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
Postgr
Hi,
On Mon, 19 Dec 2005, Joshua D. Drake wrote:
Devrim perhaps we should talk with the OpenSuSE guy about getting his RPMS up
there as well?
We once did that; but SuSE could not keep up2date with the new versions. I
don't know the current status, though. We'd be happy to mirror them in
our
1. Adjust the description of the pgfoundry project pgsqlrpms to
something like "This project aims to build PostgreSQL RPMS for Red Hat
and Fedora and maintain them."
2. When you put them on the FTP server, put them in a subdirectory
"redhat" (instead of or below "linux") to avoid that users
Devrim GUNDUZ wrote:
> Well... PGDG RPM Building Project only aims to build RPMs for Red Hat
> and Fedora Core. This has been so before, and personally *I* intend to
> continue with the same policy.
I specifically recall that this was once exactly not the policy, but of
course you are free to do
Hi,
On Sat, 2005-12-17 at 09:19 -0800, Joshua D. Drake wrote:
> >This patch should be sent to SuSE, not PostgreSQL.
> Actually, I think this should be incoporated into a spec file
> specifically for suse within the PGDG rpms.
Well... PGDG RPM Building Project only aims to build RPMs for Red Hat
Yes, I think the only official PGDG stuff is source. The binaries are
done by port-specific teams. PGDG doesn't deal with MSI installer
issues, or RPM issues, only the port-specific teams do. I know I don't
read any RPM emails and any MSI issues are dealt with by the Win32
people.
Bruce us
Joshua D. Drake wrote:
>
> >The distinction is that RPMs and pginstaller are port-specific, binary
> >distributions.
> >
> >
> So they can't be considered official port releases for the PGDG? They
> are not "forks".
> Or, are you saying that the only official PGDG release is the source?
Yes, I
The distinction is that RPMs and pginstaller are port-specific, binary
distributions.
So they can't be considered official port releases for the PGDG? They
are not "forks".
Or, are you saying that the only official PGDG release is the source?
Sincerely,
Joshua D. Drake
--
The PostgreSQ
Joshua D. Drake wrote:
>
> >>Well they are kept on PostgreSQL.Org servers, they are called PGDG
> >>rpms... I don't
> >>think you can get much more official then that.
> >>
> >>
> >
> >I think they are official like pginstaller/Win32 is official. It is
> >endorsed by our project, but sort of
Well they are kept on PostgreSQL.Org servers, they are called PGDG
rpms... I don't
think you can get much more official then that.
I think they are official like pginstaller/Win32 is official. It is
endorsed by our project, but sort of separate too.
O.k. well now I am confused... Wh
Joshua D. Drake wrote:
>
> >>>
> >>>
> >>Actually, I think this should be incoporated into a spec file
> >>specifically for suse within the PGDG rpms.
> >>
> >>
> >
> >The PostgreSQL Global Development Group has official RPMs? I didn't
> >know. When Lamar did it it was always unoffici
Actually, I think this should be incoporated into a spec file
specifically for suse within the PGDG rpms.
The PostgreSQL Global Development Group has official RPMs? I didn't
know. When Lamar did it it was always unofficial.
Well they are kept on PostgreSQL.Org servers, they ar
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>
> >This patch should be sent to SuSE, not PostgreSQL.
> >
> >
>
> Actually, I think this should be incoporated into a spec file
> specifically for suse within the PGDG rpms.
The PostgreSQL Global Development Group has official RPMs? I didn't
kn
Bruce Momjian wrote:
This patch should be sent to SuSE, not PostgreSQL.
Actually, I think this should be incoporated into a spec file
specifically for suse within the PGDG rpms.
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replic
This patch should be sent to SuSE, not PostgreSQL.
---
Weberhofer GmbH wrote:
> Dear Steve,
>
> I have had the same problem related SuSE 8.2. A thing that additionally can
> be wrong is the LC_CTYPE setting in the environm
Dear Steve,
I have had the same problem related SuSE 8.2. A thing that additionally can be wrong is
the LC_CTYPE setting in the environment. Running a SuSE system this can be set in
/etc/sysconfig/language. I am using RC_LANG="de_DE.UTF-8", but other valid
values should be fine, too.
For SuSE
Tom Lane wrote:
Steve Crawford <[EMAIL PROTECTED]> writes:
Summary:
I installed glibc-locale and initdb now works fine.
Interesting. I had just come to the conclusion that you were missing
some files...
>
the other four files all exist and are in
the glibc-common RPM, which means that i
Steve Crawford <[EMAIL PROTECTED]> writes:
> Summary:
> I installed glibc-locale and initdb now works fine.
Interesting. I had just come to the conclusion that you were missing
some files from this part of your strace:
[pid 5240] open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1
Tom Lane wrote:
Steve Crawford <[EMAIL PROTECTED]> writes:
creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL:
XX000: failed to initialize lc_messages to ""
We've seen this reported occasionally before, but none of the PG
developers have ever been able to reproduce it
Steve Crawford <[EMAIL PROTECTED]> writes:
>> creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL:
>> XX000: failed to initialize lc_messages to ""
We've seen this reported occasionally before, but none of the PG
developers have ever been able to reproduce it. Do you have any
LC
Steve Crawford wrote:
On Monday 31 October 2005 13:00, Tom Lane wrote:
Steve Crawford <[EMAIL PROTECTED]> writes:
if I try to ensure the C locale I
keep running up against:
FATAL: XX000: failed to initialize lc_messages to ""
We've seen a few reports of this before, but never been able to
ide
On Monday 31 October 2005 13:00, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > if I try to ensure the C locale I
> > keep running up against:
> > FATAL: XX000: failed to initialize lc_messages to ""
>
> We've seen a few reports of this before, but never been able to
> identify t
Steve Crawford <[EMAIL PROTECTED]> writes:
> if I try to ensure the C locale I
> keep running up against:
> FATAL: XX000: failed to initialize lc_messages to ""
We've seen a few reports of this before, but never been able to identify
the cause. What platform are you running on, exactly? Did yo
On Monday 31 October 2005 08:00, Steve Crawford wrote:
>>... believe symlinking the executables will work fine though (ie, we
> > look through the symlink before doing the relative-path
> > calculation).
>
> Yes, the symlinking did appear to work fine. Thanks for the
> confirmation that it is an ac
On Saturday 29 October 2005 22:33, Tom Lane wrote:
> Steve Crawford <[EMAIL PROTECTED]> writes:
> > Is postgresql (or some parts thereof) now using relative pathing
> > and has that behavior changed?
>
> As of 8.0 we attempt to determine the libdir, sharedir etc as
> relative to the location of the
Steve Crawford <[EMAIL PROTECTED]> writes:
> Is postgresql (or some parts thereof) now using relative pathing and
> has that behavior changed?
As of 8.0 we attempt to determine the libdir, sharedir etc as relative
to the location of the executable. So you can't just "cp" the PG
executables to so
On Friday 28 October 2005 19:18, you wrote:
> Try:
>
> /usr/local/pgsql/bin/initdb --no-locale -D /var/lib/pgsql/data
OK. That works (even without the --no-locale). Which makes me puzzled
and worried.The initdb I used and the one I used earlier are
identical (as verified by the fact that I copi
Steve Crawford wrote:
I'm having difficulty installing 8.0.4. Server is SuSE 8.2 without PG
installed. However some client libraries are Yast installed due to
dependency reconciliation.
I'm doing the standard install (./configure, make, make install) and
have created the postgres user and ap
Steve Crawford wrote:
I'm having difficulty installing 8.0.4. Server is SuSE 8.2 without PG
installed. However some client libraries are Yast installed due to
dependency reconciliation.
I'm doing the standard install (./configure, make, make install) and
have created the postgres user and ap
Steve Crawford <[EMAIL PROTECTED]> writes:
> Note, the directories shown for libdir, bindir, includedir and such
> are not where the files were actually installed.
>
> Now I could just start shuffling files around till things work but
> since I've installed/upgraded many PG installations without
I'm having difficulty installing 8.0.4. Server is SuSE 8.2 without PG
installed. However some client libraries are Yast installed due to
dependency reconciliation.
I'm doing the standard install (./configure, make, make install) and
have created the postgres user and appropriate data directory
34 matches
Mail list logo
