On 22.06.25 15:12, Peter Eisentraut wrote:
On 19.06.25 14:24, Andres Freund wrote:
Along the way, I also found that our meson.build always issues a warning
when run on Windows/msvc, which I fixed. (Should probably be
backpatched.)
Agreed. Looks like that came in with bc46104fc9aa
I have com
Re: Tom Lane
> I checked Debian and SUSE and noted that their "extended support"
> windows are a lot shorter than RHEL's, just two or three years.
> So maybe we shouldn't buy into RHEL's five-year window.
Fwiw, what we are doing for apt.postgresql.org and Debian is to
support LTS which extends Deb
On 19.06.25 14:24, Andres Freund wrote:
Along the way, I also found that our meson.build always issues a warning
when run on Windows/msvc, which I fixed. (Should probably be backpatched.)
Agreed. Looks like that came in with bc46104fc9aa
I have committed and backpatched this.
I'll park the r
Hi,
On Thu, 19 Jun 2025 at 09:40, Nazir Bilal Yavuz wrote:
>
> Hi,
>
> On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut wrote:
> >
> > On 17.06.25 19:36, Peter Eisentraut wrote:
> > > meson.build currently says
> > >
> > > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
>
x27;s some LTS distro
using not-the-latest patch version. However, I don't believe that's
an issue for these particular meson versions.
We should, however, document that the minimum meson version is 0.57.2
not just 0.57, if we're aware of issues like this.
regards, tom lane
Hi,
Hi,
On 2025-06-18 10:58:22 +0200, Peter Eisentraut wrote:
> On 17.06.25 19:36, Peter Eisentraut wrote:
> > meson.build currently says
> >
> > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
> > # RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
> >
On 19.06.25 08:40, Nazir Bilal Yavuz wrote:
Thanks for the patches! I didn't check them yet but I encountered some
errors while using meson 0.57.0 and 0.57.1 but 0.56.2, 0.57.2 and
0.58.0 worked successfully. These errors seem to be related to these
specific minor versions,
I think it's okay to
Hi,
On Wed, 18 Jun 2025 at 11:58, Peter Eisentraut wrote:
>
> On 17.06.25 19:36, Peter Eisentraut wrote:
> > meson.build currently says
> >
> > # We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
> > # RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
> > #
Peter Eisentraut writes:
> On 18.06.25 19:53, Andres Freund wrote:
>> 1) We don't remove support for OS versions unless they block something
> Maybe it's worth clarifying the interpretation of this.
> For example, for the purpose of this thread, I wouldn't consider RHEL8
> to be blocking anythi
On 18.06.25 19:53, Andres Freund wrote:
1) We don't remove support for OS versions unless they block something
Maybe it's worth clarifying the interpretation of this.
For example, for the purpose of this thread, I wouldn't consider RHEL8
to be blocking anything at the moment. It's technicall
I wrote:
> In the context of RHEL, it says here [1] that RHEL8 maintenance
> support runs through May 2029 while extended support runs through
> May 2031. That would still mean we're supporting RHEL8 for another
> four years. I'm not sure what the corresponding dates are for
> other LTS vendors.
Hi,
On Wed, 2025-06-18 at 13:27 -0400, Andres Freund wrote:
> On 2025-06-18 13:20:54 -0400, Jesper Pedersen wrote:
> > On 6/18/25 1:07 PM, Robert Haas wrote:
> > > Since any policy
> > > that anyone is likely to actually propose falls somewhere between
> > > those two extremes, half of us are then
Hi,
On Wed, 2025-06-18 at 09:35 +0200, Jelte Fennema-Nio wrote:
> Okay, so maybe pip install is not what they want. But they could still
> create a recent ninja & meson RPM themselves right.
It could be doable if we were talking about just two packages and then
there are a lot of dependencies an
Andres Freund writes:
> I think we should have a policy roughly along these lines:
> 1) We don't remove support for OS versions unless they block something
> 2) We don't remove support for OS versions in minor releases
> 3) If support for an old OS version makes something harder, it can be remo
Hi,
On 2025-06-18 19:07:32 +0200, Robert Haas wrote:
> On Wed, Jun 18, 2025 at 6:27 PM Tom Lane wrote:
> But it seems impossible to have rational discussions about this,
> because - if I may exaggerate slightly for effect - some of us think
> everyone with half a brain should upgrade within a wee
Hi,
On 2025-06-18 13:20:54 -0400, Jesper Pedersen wrote:
> On 6/18/25 1:07 PM, Robert Haas wrote:
> > Since any policy
> > that anyone is likely to actually propose falls somewhere between
> > those two extremes, half of us are then bitterly unhappy with it.
> >
>
> Which is why I tried to add D
On Wed, Jun 18, 2025 at 3:35 AM Jelte Fennema-Nio
wrote:
> And what I just don't understand about this whole discussion: We're
> talking about people who want to be frozen in time for 5 years
> straight during this "maintenance support" window by the vendor (whom they
> are paying), with only acc
Hi
On 6/18/25 1:07 PM, Robert Haas wrote:
Since any policy
that anyone is likely to actually propose falls somewhere between
those two extremes, half of us are then bitterly unhappy with it.
Which is why I tried to add Devrim to the thread.
What builds on yum.postgresql.org are using meson ?
On Wed, Jun 18, 2025 at 6:27 PM Tom Lane wrote:
> Indeed. I think the compromise we've usually settled on is "we'll
> support release X as long as there's somebody willing to do the work".
> If it's not costing you personally any effort, why object to someone
> else wanting to spend effort on suc
Hi,
On 2025-06-18 12:27:44 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio
> > wrote:
> >> And what I just don't understand about this whole discussion:
>
> > What I just don't understand about this discussion is a bunch of smart
> > people th
Robert Haas writes:
> On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio wrote:
>> And what I just don't understand about this whole discussion:
> What I just don't understand about this discussion is a bunch of smart
> people thinking that a bunch of other smart people have completely
> lost the
On Wed, Jun 18, 2025 at 9:35 AM Jelte Fennema-Nio wrote:
> And what I just don't understand about this whole discussion:
What I just don't understand about this discussion is a bunch of smart
people thinking that a bunch of other smart people have completely
lost their minds, while the second gro
On 17.06.25 19:36, Peter Eisentraut wrote:
meson.build currently says
# We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
# RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
# module, < 0.53 all uses of fs. So far there's no need to go to >=0.56.
meson_vers
On Wed, 18 Jun 2025 at 07:38, Peter Eisentraut wrote:
> That's probably ok for developers, but then again, probably no one
> develops PostgreSQL master on RHEL 8. But production RPM builds need to
> be done "in system", with the build tools being provided by
> vendor-supplied RPMs themselves, wit
On 17.06.25 23:10, Jelte Fennema-Nio wrote:
I'm not saying we shouldn't support compiling Postgres on these
systems. But having Postgres compile with just the default system
packages seems an unreasonably high bar. People running ancient
systems like this should be comfortable enough with getting
On Tue, 17 Jun 2025 at 22:19, Andres Freund wrote:
> Please do note that I was not suggesting removing support for it from minor
> versions and that the earliest we, IMO, would conceivably remove autoconf
> support would be PG 20.
>
> I'm sure there will be some folks desperate to run PG 20 on RHE
Hi,
On 2025-06-17 16:09:19 -0400, Greg Sabino Mullane wrote:
> On Tue, Jun 17, 2025 at 2:23 PM Andres Freund wrote:
>
> > From my POV, which I am sure is not uniformly shared, we don't need to
> > support
> > new major PG versions on things like RHEL 8.
>
>
> Ha ha ha ha! (wipes tears from eye
On Tue, Jun 17, 2025 at 2:23 PM Andres Freund wrote:
> From my POV, which I am sure is not uniformly shared, we don't need to
> support
> new major PG versions on things like RHEL 8.
Ha ha ha ha! (wipes tears from eyes). RHEL 8 is still cutting edge / very
active for many companies out there. A
Hi,
On 2025-06-17 14:33:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-06-17 13:48:33 -0400, Tom Lane wrote:
> >> RHEL 8 does include meson 0.58.2. However, it also ships ninja 1.8.2
> >> which is too old:
>
> > IIRC we discussed this before, in some other thread. We could make
Hi,
On 6/17/25 2:23 PM, Andres Freund wrote:
After all full support for RHEL 8 has ended a year ago.
Yes, full support ended May 31, 2024 - but extended support ends May 31,
2029.
Devrim, feedback ?
Best regards,
Jesper
Andres Freund writes:
> On 2025-06-17 13:48:33 -0400, Tom Lane wrote:
>> RHEL 8 does include meson 0.58.2. However, it also ships ninja 1.8.2
>> which is too old:
> IIRC we discussed this before, in some other thread. We could make that work,
> but at the time we didn't consider it worth working
Hi,
On 2025-06-17 13:48:33 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
> > good target to aim for. (I don't know if that carried over from RHEL 8
> > or is their own doing.) But there aren't any compelling feat
Peter Eisentraut writes:
> I see that Rocky Linux 8 ships with Meson 0.58.2 [0], so maybe that is a
> good target to aim for. (I don't know if that carried over from RHEL 8
> or is their own doing.) But there aren't any compelling features new in
> 0.58 (format strings seem nice but are prett
meson.build currently says
# We want < 0.56 for python 3.5 compatibility on old platforms. EPEL for
# RHEL 7 has 0.55. < 0.54 would require replacing some uses of the fs
# module, < 0.53 all uses of fs. So far there's no need to go to >=0.56.
meson_version: '>=0.54',
Since the current minimum su
34 matches
Mail list logo
