On Tue, Oct 19, 2021 at 01:09:28PM +0200, Daniel Gustafsson wrote:
> The other proposal, making sure that we don't see a version 2.x.x creep in (in
> case a packager decides to play cute like how has happened in other OS's) seem
> sane to me, but I'm also not very well versed in Windows so you be t
> On 19 Oct 2021, at 12:52, Michael Paquier wrote:
>
> On Tue, Oct 19, 2021 at 10:34:10AM +0200, Daniel Gustafsson wrote:
>> I think we can tighten the check for GetOpenSSLVersion() a bit since we now
>> now
>> the range of version in the 1.x.x series. For these checks we know we want
>> 1.1.x
On Tue, Oct 19, 2021 at 10:34:10AM +0200, Daniel Gustafsson wrote:
> I think we can tighten the check for GetOpenSSLVersion() a bit since we now
> now
> the range of version in the 1.x.x series. For these checks we know we want
> 1.1.x or 3.x.x, but never 2.x.x etc.
>
> How about the (untested)
> On 19 Oct 2021, at 07:27, Michael Paquier wrote:
> Looking at the MSIs of OpenSSL for Win64 and Win32, there are no
> changes in the deliverable names or paths, meaning that something as
> simple as the attached patch is enough to make the build pass.
Makes sense.
> Any opinions?
I think we
Hi all,
$subject has been noticed on github here:
https://github.com/postgres/postgres/pull/70/commits
Looking at the MSIs of OpenSSL for Win64 and Win32, there are no
changes in the deliverable names or paths, meaning that something as
simple as the attached patch is enough to make the build pas
