On 28.01.25 14:34, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sepgsql.sql
into th
Peter Eisentraut writes:
> On 27.08.24 10:12, Peter Eisentraut wrote:
>> Here is a new patch version.
>> I simplified the uses of sed and awk inside the Perl script. I also
>> fixed "make installcheck". I noticed that meson installs sepgsql.sql
>> into the wrong directory, so that's fixed also
On 1/26/25 11:36, Andrew Dunstan wrote:
On 2025-01-26 Su 10:29 AM, Joe Conway wrote:
On 1/24/25 09:00, Andrew Dunstan wrote:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside
On 2025-01-26 Su 10:29 AM, Joe Conway wrote:
On 1/24/25 09:00, Andrew Dunstan wrote:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I
also fixed "make i
On 1/24/25 09:00, Andrew Dunstan wrote:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sep
On 25.01.25 22:55, Tom Lane wrote:
Peter Eisentraut writes:
This has been committed. And I understand there is a buildfarm client
update available for the affected buildfarm members.
BTW, shouldn't the CF entry for this get closed now?
done
Peter Eisentraut writes:
> This has been committed. And I understand there is a buildfarm client
> update available for the affected buildfarm members.
BTW, shouldn't the CF entry for this get closed now?
regards, tom lane
On Sat, 25 Jan 2025 at 11:57, Andrew Dunstan wrote:
> On 2025-01-24 Fr 7:50 PM, Andrew Dunstan wrote:
> > Here's the hot fix (which passed my test with a directory with pgsql
> > in its path):
>
> >
> https://github.com/PGBuildFarm/client-code/commit/f6c6dd52d2959814452454890fb9838429c5c3e8
>
>
On 2025-01-24 Fr 7:50 PM, Andrew Dunstan wrote:
Here's the hot fix (which passed my test with a directory with pgsql
in its path):
https://github.com/PGBuildFarm/client-code/commit/f6c6dd52d2959814452454890fb9838429c5c3e8
Oops, wrong address on previous email. Julien, please update
On 2025-01-24 Fr 7:09 PM, Robins Tharakan wrote:
On Sat, 25 Jan 2025 at 10:11, Tom Lane wrote:
Yeah, that's about what I expected. As a workaround until Andrew
updates the BF client, you could do
- $libdir = "$tmp_loc/lib/postgresql";
+ $libdir =
On Sat, 25 Jan 2025 at 10:11, Tom Lane wrote:
> Yeah, that's about what I expected. As a workaround until Andrew
> updates the BF client, you could do
>
> - $libdir = "$tmp_loc/lib/postgresql";
> + $libdir = "$tmp_loc/lib";
>
> at about line 429 of PGBuild/Utils.pm
>
Robins Tharakan writes:
> On Sat, 25 Jan 2025 at 08:59, Tom Lane wrote:
>> alligator and lapwing are not reporting the
>> relevant log file, but what we do see is an install failure that
>> could well be down to a compile failure.
> You're probably right about that.
> This is what I see in the i
On 2025-01-24 Fr 6:08 PM, Tom Lane wrote:
I wrote:
Oh ... wait a second. After further code reading I see that
the BF client sets NO_TEMP_INSTALL if check_install_is_complete
succeeds. So evidently, that is successfully suppressing
"make install" on most animals, but not these two. How come
On Sat, 25 Jan 2025 at 08:59, Tom Lane wrote:
> alligator and lapwing are not reporting the
> relevant log file, but what we do see is an install failure that
> could well be down to a compile failure.
>
You're probably right about that.
This is what I see in the install.log
(/home/postgres/proj
I wrote:
> Oh ... wait a second. After further code reading I see that
> the BF client sets NO_TEMP_INSTALL if check_install_is_complete
> succeeds. So evidently, that is successfully suppressing
> "make install" on most animals, but not these two. How come?
Got it: we can see on alligator that
I wrote:
> Yeah, but to get to that point you have to get past "make install",
Oh ... wait a second. After further code reading I see that
the BF client sets NO_TEMP_INSTALL if check_install_is_complete
succeeds. So evidently, that is successfully suppressing
"make install" on most animals, but
Andrew Dunstan writes:
> On 2025-01-24 Fr 4:07 PM, Tom Lane wrote:
>> Looking at the buildfarm client script, it looks to me like it
>> will unconditionally try to run TAP tests in every contrib directory
>> that has a "t" subdirectory. Up to now, none of those needed to
>> be conditional ... but
On 2025-01-24 Fr 4:07 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
Looks like alligator needs some help here too.
That's an issue with the new TAP test - alligator isn't running the
TestSepgsql module. lapwing has also had a TAP test failure.
Hmm. Ne
Andrew Dunstan writes:
> On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
>> Looks like alligator needs some help here too.
> That's an issue with the new TAP test - alligator isn't running the
> TestSepgsql module. lapwing has also had a TAP test failure.
Hmm. Neither of those animals should be try
On 2025-01-24 Fr 10:57 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
This has been committed. And I understand there is a buildfarm client
update available for the affected buildfarm members.
This should only be rhinoceros. Joe can pull this f
Andrew Dunstan writes:
> On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
>> This has been committed. And I understand there is a buildfarm client
>> update available for the affected buildfarm members.
> This should only be rhinoceros. Joe can pull this fix:
> https://github.com/PGBuildFarm/
On 1/24/25 09:00, Andrew Dunstan wrote:
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sep
On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sepgsql.sql
into the wrong directory, so t
On 27.08.24 10:12, Peter Eisentraut wrote:
Here is a new patch version.
I simplified the uses of sed and awk inside the Perl script. I also
fixed "make installcheck". I noticed that meson installs sepgsql.sql
into the wrong directory, so that's fixed also. (Many of the
complications in thi
On 24.07.24 23:03, Andreas Karlsson wrote:
On 7/24/24 10:35 PM, Tom Lane wrote:
Andreas Karlsson writes:
1) As I said earlier I think we should remove the old code.
I agree that carrying two versions of the test doesn't seem great.
However, a large part of the purpose of test_sepgsql is to h
On 7/24/24 10:35 PM, Tom Lane wrote:
Andreas Karlsson writes:
1) As I said earlier I think we should remove the old code.
I agree that carrying two versions of the test doesn't seem great.
However, a large part of the purpose of test_sepgsql is to help
people debug their sepgsql setup, which
Andreas Karlsson writes:
> 1) As I said earlier I think we should remove the old code.
I agree that carrying two versions of the test doesn't seem great.
However, a large part of the purpose of test_sepgsql is to help
people debug their sepgsql setup, which is why it goes to great
lengths to prin
On 7/24/24 6:33 PM, Peter Eisentraut wrote:
On 24.07.24 16:31, Andreas Karlsson wrote:
I took a quick look at the patch and I like that we standardize things
a bit. But one thing I am not a fan of are all the use of sed and awk
in the Perl script. I would prefer if that logic happened all in Pe
On 7/24/24 12:36, Tom Lane wrote:
Peter Eisentraut writes:
In my experience, the tests (both the old and the proposed new) only
work on Red Hat-like platforms. I had also tried on Debian but decided
that it won't work.
Yeah, Red Hat is pretty much the only vendor that has pushed SELinux
far
Peter Eisentraut writes:
> In my experience, the tests (both the old and the proposed new) only
> work on Red Hat-like platforms. I had also tried on Debian but decided
> that it won't work.
Yeah, Red Hat is pretty much the only vendor that has pushed SELinux
far enough to be usable by non-wiz
On 7/24/24 6:31 PM, Peter Eisentraut wrote:
On 24.07.24 18:29, Andreas Karlsson wrote:
Peter, what did you do to get the tests running? And should we fix
these tests to make them more user friendly?
In my experience, the tests (both the old and the proposed new) only
work on Red Hat-like plat
On 24.07.24 16:31, Andreas Karlsson wrote:
I took a quick look at the patch and I like that we standardize things a
bit. But one thing I am not a fan of are all the use of sed and awk in
the Perl script. I would prefer if that logic happened all in Perl,
especially since we have some of it in P
On 24.07.24 18:29, Andreas Karlsson wrote:
On 7/24/24 4:31 PM, Andreas Karlsson wrote:
I have not yet set up an VM with selinux to try the patch out for real
but will do so later.
I almost got the tests running but it required way too many manual steps
to just get there and I gave up after ju
On 7/24/24 4:31 PM, Andreas Karlsson wrote:
I have not yet set up an VM with selinux to try the patch out for real
but will do so later.
I almost got the tests running but it required way too many manual steps
to just get there and I gave up after just getting segfaults. I had to
edit sepgsql
I took a quick look at the patch and I like that we standardize things a
bit. But one thing I am not a fan of are all the use of sed and awk in
the Perl script. I would prefer if that logic happened all in Perl,
especially since we have some of it in Perl (e.g. chomp). Also I wonder
if we shoul
35 matches
Mail list logo
