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
