Hi Tom!
Tom Lane [2005-12-23 17:38 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > I'm fine with dropping --bindir, --libdir, --datadir, but at least the
> > arch-independent and arch-dependent prefix should work. I do not want
> > to put all arch-independent data into /usr/lib, it w
Martin Pitt <[EMAIL PROTECTED]> writes:
> I'm fine with dropping --bindir, --libdir, --datadir, but at least the
> arch-independent and arch-dependent prefix should work. I do not want
> to put all arch-independent data into /usr/lib, it would violate the
> FHS and Debian Policy.
> Is it possible
Tom Lane wrote:
> It's not all that uninteresting, because "make check" is essentially an
> instance of exercising the relocatability feature.
That just means that the test suite is testing features that are not of
interest to certain groups of users; it doesn't declare a feature
intesting.
(Cert
Hi!
Stephen Frost [2005-12-21 21:06 -0500]:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > (I'm not sure about Debian's policy, but the RPMs do --disable-rpath for
> > unrelated policy reasons, so there shouldn't be any problem with
> > relocating an RPM-based installation...)
>
> Debian's policy is
* Tom Lane ([EMAIL PROTECTED]) wrote:
> (I'm not sure about Debian's policy, but the RPMs do --disable-rpath for
> unrelated policy reasons, so there shouldn't be any problem with
> relocating an RPM-based installation...)
Debian's policy is to do --disable-rpath also, which I hope Martin is
doing
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 21. Dezember 2005 08:21 schrieb Martin Pitt:
>> However, if --bindir etc. cannot be set, then maybe configure should
>> not offer these options?
> They can be set and support for that will not go away. But if you choose
> unfortunate co
Am Mittwoch, 21. Dezember 2005 08:21 schrieb Martin Pitt:
> However, if --bindir etc. cannot be set, then maybe configure should
> not offer these options?
They can be set and support for that will not go away. But if you choose
unfortunate combinations of locations, the installation becomes
un
Martin Pitt <[EMAIL PROTECTED]> writes:
> Tom Lane [2005-12-20 16:39 -0500]:
>> We could doubtless improve make_relative_path to some extent, but the
>> mess you have above seems impossible to deal with. How is a mere
>> program supposed to deduce where things were moved to, given only
>> knowledg
Hi!
Tom Lane [2005-12-20 17:16 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > ./configure --libdir=3D/usr/lib/postgresql/8.1/lib --bindir=3D/usr/lib/pos=
> > tgresql/8.1/bin
>
> > is enough to reproduce the problem. With only --libdir, it works, and
> > with only --bindir the test suite d
Hi!
Tom Lane [2005-12-20 16:39 -0500]:
> Yeah, the chosen-at-random pathnames ;-).
It's not that random, these are the paths that the FHS and Debian
policy prescribe for this package's structure (multiple versions
installable in parallel). :)
> I quote from the comments for make_relative_path()
Martin Pitt <[EMAIL PROTECTED]> writes:
> ./configure --libdir=3D/usr/lib/postgresql/8.1/lib --bindir=3D/usr/lib/pos=
> tgresql/8.1/bin
> is enough to reproduce the problem. With only --libdir, it works, and
> with only --bindir the test suite does not run at all because the
> postmaster cannot f
Martin Pitt <[EMAIL PROTECTED]> writes:
> Maybe I did something wrong with the configure options. That bug is
> reproducible with the pristine upstream 8.1.1 tarball and doing:
> =2E/configure --prefix=/usr --mandir="\${prefix}/share/man" \
> --sysconfdir=/etc --libdir="\${prefix}/lib/postgre
Hi!
Martin Pitt [2005-12-20 21:23 +0100]:
> Maybe I did something wrong with the configure options. That bug is
> reproducible with the pristine upstream 8.1.1 tarball and doing:
>
> ./configure --prefix=/usr --mandir="\${prefix}/share/man" \
> --sysconfdir=/etc --libdir="\${prefix}/lib/post
Hi Tom!
Tom Lane [2005-12-20 12:49 -0500]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > So it seems that the test suite uses the timezone files from the
> > installed system instead of the files in the temporary installation in
> > the regression test directory.
>
> It's not supposed to, and AFA
Martin Pitt <[EMAIL PROTECTED]> writes:
> So it seems that the test suite uses the timezone files from the
> installed system instead of the files in the temporary installation in
> the regression test directory.
It's not supposed to, and AFAICT it works fine for me (not only on my
personal machin
Hi again!
Martin Pitt [2005-09-29 23:08 +0200]:
> Hi!
>
> On almost all Debian platforms the horology test for 8.0.3 fails.
> Sometimes it works on a platform, sometimes not, I did not yet find a
> pattern, but most often it fails with something like
> [...]
I now think I know what is wrong here
Hi Tom!
Tom Lane [2005-09-29 17:50 -0400]:
> Martin Pitt <[EMAIL PROTECTED]> writes:
> > On almost all Debian platforms the horology test for 8.0.3 fails.
>
> Before PG 8.0, I'd have said you were running with a timezone library
> that didn't understand about DST before 1970. It shouldn't be hap
Martin Pitt <[EMAIL PROTECTED]> writes:
> On almost all Debian platforms the horology test for 8.0.3 fails.
Before PG 8.0, I'd have said you were running with a timezone library
that didn't understand about DST before 1970. It shouldn't be happening
in 8.0 though.
regards
On Thu, Sep 29, 2005 at 11:08:22PM +0200, Martin Pitt wrote:
> On almost all Debian platforms the horology test for 8.0.3 fails.
> Sometimes it works on a platform, sometimes not, I did not yet find a
> pattern, but most often it fails with something like
I think this test is supposed to fail whe
Hi!
On almost all Debian platforms the horology test for 8.0.3 fails.
Sometimes it works on a platform, sometimes not, I did not yet find a
pattern, but most often it fails with something like
*** ./expected/horology.out Sun Jul 11 04:57:20 2004
--- ./results/horology.out Thu Sep 29 20:4
20 matches
Mail list logo
