Re: help needed: Windows CI broken

[Joe Orton]

Many thanks to everybody who contributed here! I merged Vladimir's PR 
combining various backports to 2.4.x which should get us back to green, 
fingers crossed :)

https://github.com/apache/httpd/commit/f8ff26ab026b8f358894e0c433cafc72e3a88ac9

Re: help needed: Windows CI broken

[Jeff McKenna]

No problem.

- MSVC 2022
- run CMake always from commandline (CMake 4.3.3)
- always using CMake installed from cmake.org (never from Visual Studio 
IDE / I remove their old CMake from the MSVC install always, as it 
causes problems, so it is never on my system)


If you are using CMake 4.3.0, you will notice that CMake will throw a 
hard error (full stop) when compiling the GitHub branch 2.4.x without my 
(minimum required version) change mentioned in this thread.


Regarding the error: Unexpected enablement value "i" for mod_authnz_ldap :

- it is definitely intermittent (difficult to replicate, but when you 
get it you'll know ha), this is why I did not include it in my original 
pull request to trunk last month ( 
https://github.com/apache/httpd/pull/640/changes/574ab1e79d01fae79562bb34ffcef2b6f582f0b6 
)


- I only mentioned publicly here my ugly 'unset(i)' workaround because 
Joe posted here on this mailing list that he hit that exact error in a 
CI run with branch 2.4.x and he wanted it fixed asap


I do regret mentioning my workaround for the "i" error (I did not 
mention it last month for my pull request, as I knew it would cause 
pushback).


My point is: as a packager on Windows, compiling HTTPD from source by 
hand (I realize I am one of the few), if you do hit that 'unexpected 
enablement value i" error, don't stress, there is a known workaround 
(see my [now closed] pull request).


And, as you said, you have hit that error before (I am not surprised / 
this is my not surprised face ha).


Sorry for all of this, I was only trying to help.

Now, "back to regular programming" ha.

-jeff







On 2026-06-02 4:42 p.m., Paul Lodge wrote:

I apologize Jeff if I caused offense, that wasn't my intent.


please could you let us know a little more about the environment you're 
using for example


what VS version are you using? and

how are you running cmake, from the commandline too or from within the 
Visual Studio IDE?


Windows versions etc


I'd like to try and replicate it


P.

I'm running cmake version 4.3.0 (I haven't tried with 4.3.2 or 4.3.3 
yet) on a WIndows 11 machine Windows build SDK 2022 and DDK 2022(IIRC), 
and I dont't get the Unexpected enablement value "i" for mod_authnz_ldap 
issue, I did get it though, when I used an older cmake 3.29.2, which is 
bundled with strawberry perl. I'm running the cmake and the pyhttpd test 
suite directly from the commandline.



On 02/06/2026 18:02, Jeff McKenna wrote:

I use CMake 4.3.3 (no custom settings).

I had CMake 4.3.2 a month ago when I submitted the CMake minimum 
version required change to trunk, to avoid that hard error (and was 
hitting the same error locally:


 Unexpected enablement value "i" for mod_authnz_ldap.

that was also shown in the CI for branch 2.4.x

At that time, I chose not to submit the 'unset' workaround, even 
though it popped back up here in the CI runs again.




-jeff





On 2026-06-02 12:42 p.m., Vladimir Chlup wrote:
I agree that there seems to be a bit of a mixup, however, I don't 
think either of these two changes is necessarily required.


See this: https://github.com/jajik/httpd/actions/runs/26829154521/ 
. It's 
2.4.x running with VS 2022.*


Is it possible you have a CMake setting that treats warnings as 
errors? (like https://cmake.org/cmake/help/latest/variable/ 
CMAKE_ERROR_DEPRECATED.html ) Which version of CMake do you 
have? We might be missing something else...


Best,
Vlad

* The reason it works without the trunk fix is that in my fork 
`windows- latest` is still the old container with VS 2022 while 
apache/httpd was already moved to the new image with VS 2026.



On Tue, Jun 2, 2026 at 4:46 PM Jeff McKenna 
> wrote:


    On 2026-06-02 10:45 a.m., Paul Lodge wrote:
 > Hi All,
 >
 > It might be in the best interest to move forward with Vlads
    suggestion
 > for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave 
the 'i'

 > variable unset, as it's not an optimal solution it's ok as a
    quick fix
 > but could potentially cause headaches in the future.
 >
 > I think that the Windows side of things in general (CMake, tests
    etc)
 > need a little TLC, I don't mind looking into and taking on the 
task.

 >
 > Best
 >
 > Paul

    Joe seemed stressed about needing a workaround to get that branch 
2.4.x

    running, and I provided the workaround.

    I actually agree not to commit the 'unset(i)', notice that I 
submitted

    the CMAKE_MINIMUM_REQUIRED change a month ago to trunk, as I figured
    that my unset(i) change was not optimal.  (however, to this day, 
I need

    that unset(i) to get branch 2.4.x to compile, as mentioned by Joe in
    his
    GitHub run).

    /me just trying to help

    Sorry all,

    -jeff




 >
 >
 > On 02/06/2026 09:19, 

Re: help needed: Windows CI broken

[Paul Lodge]

I apologize Jeff if I caused offense, that wasn't my intent.


please could you let us know a little more about the environment you're 
using for example


what VS version are you using? and

how are you running cmake, from the commandline too or from within the 
Visual Studio IDE?


Windows versions etc


I'd like to try and replicate it


P.

I'm running cmake version 4.3.0 (I haven't tried with 4.3.2 or 4.3.3 
yet) on a WIndows 11 machine Windows build SDK 2022 and DDK 2022(IIRC), 
and I dont't get the Unexpected enablement value "i" for mod_authnz_ldap 
issue, I did get it though, when I used an older cmake 3.29.2, which is 
bundled with strawberry perl. I'm running the cmake and the pyhttpd test 
suite directly from the commandline.



On 02/06/2026 18:02, Jeff McKenna wrote:

I use CMake 4.3.3 (no custom settings).

I had CMake 4.3.2 a month ago when I submitted the CMake minimum 
version required change to trunk, to avoid that hard error (and was 
hitting the same error locally:


 Unexpected enablement value "i" for mod_authnz_ldap.

that was also shown in the CI for branch 2.4.x

At that time, I chose not to submit the 'unset' workaround, even 
though it popped back up here in the CI runs again.




-jeff





On 2026-06-02 12:42 p.m., Vladimir Chlup wrote:
I agree that there seems to be a bit of a mixup, however, I don't 
think either of these two changes is necessarily required.


See this: https://github.com/jajik/httpd/actions/runs/26829154521/ 
. It's 
2.4.x running with VS 2022.*


Is it possible you have a CMake setting that treats warnings as 
errors? (like https://cmake.org/cmake/help/latest/variable/ 
CMAKE_ERROR_DEPRECATED.html ) Which version of CMake do you 
have? We might be missing something else...


Best,
Vlad

* The reason it works without the trunk fix is that in my fork 
`windows- latest` is still the old container with VS 2022 while 
apache/httpd was already moved to the new image with VS 2026.



On Tue, Jun 2, 2026 at 4:46 PM Jeff McKenna 
> wrote:


    On 2026-06-02 10:45 a.m., Paul Lodge wrote:
 > Hi All,
 >
 > It might be in the best interest to move forward with Vlads
    suggestion
 > for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave 
the 'i'

 > variable unset, as it's not an optimal solution it's ok as a
    quick fix
 > but could potentially cause headaches in the future.
 >
 > I think that the Windows side of things in general (CMake, tests
    etc)
 > need a little TLC, I don't mind looking into and taking on the 
task.

 >
 > Best
 >
 > Paul

    Joe seemed stressed about needing a workaround to get that branch 
2.4.x

    running, and I provided the workaround.

    I actually agree not to commit the 'unset(i)', notice that I 
submitted

    the CMAKE_MINIMUM_REQUIRED change a month ago to trunk, as I figured
    that my unset(i) change was not optimal.  (however, to this day, 
I need

    that unset(i) to get branch 2.4.x to compile, as mentioned by Joe in
    his
    GitHub run).

    /me just trying to help

    Sorry all,

    -jeff




 >
 >
 > On 02/06/2026 09:19, Vladimir Chlup wrote:
 >> Hello,
 >>
 >> The issue is most likely caused by the change of the default GH
 >> Actions Windows image. See https://github.com/actions/runner-
    images/ 
 >> issues/14017 You can try using `windows-2022` instead of the
    current
 >> `windows-latest`. It should behave as before.
 >>
 >> Alternatively, I have prepared a PR with a fix here: https://
 >> github.com/apache/httpd/pull/659 
 >>
 >> Regards,
 >> Vladimír Chlup
 >>
 >>
 >> On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna
 >> mailto:jmcke...@gatewaygeomatics.com>> wrote:
 >>
 >>     On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
 >>     > On 2026-06-01 12:39 p.m., Joe Orton wrote:
 >>     >> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna 
wrote:

 >>     >>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
 >>      Windows builds have been failing in CI for a while, 
I think

 >>     because of
 >>      some changes in the GHA images.
 >>     
 >>      I burnt some Claude tokens trying to fix the trunk 
to no

 >>     avail [1], but
 >>      I have zero interest in this. It will be ... 
frustrating...

 >>     if people
 >>      start voting against future 2.4.x rcs because Windows
    builds
 >>     are broken
 >>      in some way which was trivial to catch in CI and fix
    ahead of
 >>     time.
 >>     
 >>      Example trunk failure: https://github.com/apache/httpd/
    actions/ 

Re: help needed: Windows CI broken

[Jeff McKenna]

I use CMake 4.3.3 (no custom settings).

I had CMake 4.3.2 a month ago when I submitted the CMake minimum version 
required change to trunk, to avoid that hard error (and was hitting the 
same error locally:


 Unexpected enablement value "i" for mod_authnz_ldap.

that was also shown in the CI for branch 2.4.x

At that time, I chose not to submit the 'unset' workaround, even though 
it popped back up here in the CI runs again.




-jeff





On 2026-06-02 12:42 p.m., Vladimir Chlup wrote:
I agree that there seems to be a bit of a mixup, however, I don't think 
either of these two changes is necessarily required.


See this: https://github.com/jajik/httpd/actions/runs/26829154521/ 
. It's 
2.4.x running with VS 2022.*


Is it possible you have a CMake setting that treats warnings as errors? 
(like https://cmake.org/cmake/help/latest/variable/ 
CMAKE_ERROR_DEPRECATED.html ) Which version of CMake do you 
have? We might be missing something else...


Best,
Vlad

* The reason it works without the trunk fix is that in my fork `windows- 
latest` is still the old container with VS 2022 while apache/httpd was 
already moved to the new image with VS 2026.



On Tue, Jun 2, 2026 at 4:46 PM Jeff McKenna 
mailto:jmcke...@gatewaygeomatics.com>> 
wrote:


On 2026-06-02 10:45 a.m., Paul Lodge wrote:
 > Hi All,
 >
 > It might be in the best interest to move forward with Vlads
suggestion
 > for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave the 'i'
 > variable unset, as it's not an optimal solution it's ok as a
quick fix
 > but could potentially cause headaches in the future.
 >
 > I think that the Windows side of things in general (CMake, tests
etc)
 > need a little TLC, I don't mind looking into and taking on the task.
 >
 > Best
 >
 > Paul

Joe seemed stressed about needing a workaround to get that branch 2.4.x
running, and I provided the workaround.

I actually agree not to commit the 'unset(i)', notice that I submitted
the CMAKE_MINIMUM_REQUIRED change a month ago to trunk, as I figured
that my unset(i) change was not optimal.  (however, to this day, I need
that unset(i) to get branch 2.4.x to compile, as mentioned by Joe in
his
GitHub run).

/me just trying to help

Sorry all,

-jeff




 >
 >
 > On 02/06/2026 09:19, Vladimir Chlup wrote:
 >> Hello,
 >>
 >> The issue is most likely caused by the change of the default GH
 >> Actions Windows image. See https://github.com/actions/runner-
images/ 
 >> issues/14017 You can try using `windows-2022` instead of the
current
 >> `windows-latest`. It should behave as before.
 >>
 >> Alternatively, I have prepared a PR with a fix here: https://
 >> github.com/apache/httpd/pull/659 
 >>
 >> Regards,
 >> Vladimír Chlup
 >>
 >>
 >> On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna
 >> mailto:jmcke...@gatewaygeomatics.com>> wrote:
 >>
 >>     On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
 >>     > On 2026-06-01 12:39 p.m., Joe Orton wrote:
 >>     >> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
 >>     >>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
 >>      Windows builds have been failing in CI for a while, I think
 >>     because of
 >>      some changes in the GHA images.
 >>     
 >>      I burnt some Claude tokens trying to fix the trunk to no
 >>     avail [1], but
 >>      I have zero interest in this. It will be ... frustrating...
 >>     if people
 >>      start voting against future 2.4.x rcs because Windows
builds
 >>     are broken
 >>      in some way which was trivial to catch in CI and fix
ahead of
 >>     time.
 >>     
 >>      Example trunk failure: https://github.com/apache/httpd/
actions/ 
 >>      runs/25912053842/job/76159381743
 >>     
 >>      2.4.x failure is "simpler" because of the cmake version
mismatch:
 >>      https://github.com/apache/httpd/actions/
runs/25488877019/ 
 >>      job/74791446628
 >>      but working around that as suggested did not help.
 >>     
 >>      Regards, Joe
 >>     
 >>      [1] https://github.com/notroj/httpd/tree/refs/heads/
maybe-fix- 
 >>      windows-ci
 >>     >>>
 >>     >>> Branch 2.4.x needs this change to be backported: https://
 >> github.com/ 
 >>     >>> 

Re: help needed: Windows CI broken

[Vladimir Chlup]

I agree that there seems to be a bit of a mixup, however, I don't think
either of these two changes is necessarily required.

See this: https://github.com/jajik/httpd/actions/runs/26829154521/. It's
2.4.x running with VS 2022.*

Is it possible you have a CMake setting that treats warnings as errors?
(like
https://cmake.org/cmake/help/latest/variable/CMAKE_ERROR_DEPRECATED.html)
Which version of CMake do you have? We might be missing something else...

Best,
Vlad

* The reason it works without the trunk fix is that in my fork
`windows-latest` is still the old container with VS 2022 while apache/httpd
was already moved to the new image with VS 2026.


On Tue, Jun 2, 2026 at 4:46 PM Jeff McKenna 
wrote:

> On 2026-06-02 10:45 a.m., Paul Lodge wrote:
> > Hi All,
> >
> > It might be in the best interest to move forward with Vlads suggestion
> > for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave the 'i'
> > variable unset, as it's not an optimal solution it's ok as a quick fix
> > but could potentially cause headaches in the future.
> >
> > I think that the Windows side of things in general (CMake, tests etc)
> > need a little TLC, I don't mind looking into and taking on the task.
> >
> > Best
> >
> > Paul
>
> Joe seemed stressed about needing a workaround to get that branch 2.4.x
> running, and I provided the workaround.
>
> I actually agree not to commit the 'unset(i)', notice that I submitted
> the CMAKE_MINIMUM_REQUIRED change a month ago to trunk, as I figured
> that my unset(i) change was not optimal.  (however, to this day, I need
> that unset(i) to get branch 2.4.x to compile, as mentioned by Joe in his
> GitHub run).
>
> /me just trying to help
>
> Sorry all,
>
> -jeff
>
>
>
>
> >
> >
> > On 02/06/2026 09:19, Vladimir Chlup wrote:
> >> Hello,
> >>
> >> The issue is most likely caused by the change of the default GH
> >> Actions Windows image. See https://github.com/actions/runner-images/
> >> issues/14017 You can try using `windows-2022` instead of the current
> >> `windows-latest`. It should behave as before.
> >>
> >> Alternatively, I have prepared a PR with a fix here: https://
> >> github.com/apache/httpd/pull/659
> >>
> >> Regards,
> >> Vladimír Chlup
> >>
> >>
> >> On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna
> >>  wrote:
> >>
> >> On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
> >> > On 2026-06-01 12:39 p.m., Joe Orton wrote:
> >> >> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
> >> >>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
> >>  Windows builds have been failing in CI for a while, I think
> >> because of
> >>  some changes in the GHA images.
> >> 
> >>  I burnt some Claude tokens trying to fix the trunk to no
> >> avail [1], but
> >>  I have zero interest in this. It will be ... frustrating...
> >> if people
> >>  start voting against future 2.4.x rcs because Windows builds
> >> are broken
> >>  in some way which was trivial to catch in CI and fix ahead of
> >> time.
> >> 
> >>  Example trunk failure:
> https://github.com/apache/httpd/actions/
> >>  runs/25912053842/job/76159381743
> >> 
> >>  2.4.x failure is "simpler" because of the cmake version
> mismatch:
> >>  https://github.com/apache/httpd/actions/runs/25488877019/
> >>  job/74791446628
> >>  but working around that as suggested did not help.
> >> 
> >>  Regards, Joe
> >> 
> >>  [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-
> >>  windows-ci
> >> >>>
> >> >>> Branch 2.4.x needs this change to be backported: https://
> >> github.com/
> >> >>> apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24
> >> >>
> >> >> Does that definitely work? I tried -
> >> DCMAKE_POLICY_VERSION_MINIMUM=3.5
> >> >> and it failed:
> >> >> https://github.com/apache/httpd/actions/runs/26754488163/
> >> job/78850661003
> >> >
> >> > Ah!  I didn't notice that attempt.  To answer your question: yes
> >> that
> >> > CMake change that I made works.  The run that you pointed to you
> >> here
> >> > makes it past that (thanks to that fix) and now breaks on a
> >> different
> >> > issue.
> >> >
> >> > I had made a change locally to avoid that error: Unexpected
> >> enablement
> >> > value "i" for mod_authnz_ldap
> >> >
> >> > But I wasn't proud of my workaround, and now I realize that I
> >> should
> >> > create a pull request for my workaround for that "i" error (if I
> >> > remember, I had to "unset(i)" outside of a for loop, to avoid that
> >> > error.  Will file a new pull request now (to the 2.4.x branch,
> >> if you
> >> > already applied the other fix that I mentioned).
> >> >
> >> >>
> >> >>> PS. Suggest to use the Backport action in the httpd repo (we
> >> use this
> >> >>> and it
> 

Re: help needed: Windows CI broken

[Jeff McKenna]

On 2026-06-02 10:45 a.m., Paul Lodge wrote:

Hi All,

It might be in the best interest to move forward with Vlads suggestion 
for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave the 'i' 
variable unset, as it's not an optimal solution it's ok as a quick fix 
but could potentially cause headaches in the future.


I think that the Windows side of things in general (CMake, tests etc) 
need a little TLC, I don't mind looking into and taking on the task.


Best

Paul


Joe seemed stressed about needing a workaround to get that branch 2.4.x 
running, and I provided the workaround.


I actually agree not to commit the 'unset(i)', notice that I submitted 
the CMAKE_MINIMUM_REQUIRED change a month ago to trunk, as I figured 
that my unset(i) change was not optimal.  (however, to this day, I need 
that unset(i) to get branch 2.4.x to compile, as mentioned by Joe in his 
GitHub run).


/me just trying to help

Sorry all,

-jeff







On 02/06/2026 09:19, Vladimir Chlup wrote:

Hello,

The issue is most likely caused by the change of the default GH 
Actions Windows image. See https://github.com/actions/runner-images/ 
issues/14017 You can try using `windows-2022` instead of the current 
`windows-latest`. It should behave as before.


Alternatively, I have prepared a PR with a fix here: https:// 
github.com/apache/httpd/pull/659


Regards,
Vladimír Chlup


On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna 
 wrote:


On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
> On 2026-06-01 12:39 p.m., Joe Orton wrote:
>> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
>>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
 Windows builds have been failing in CI for a while, I think
because of
 some changes in the GHA images.

 I burnt some Claude tokens trying to fix the trunk to no
avail [1], but
 I have zero interest in this. It will be ... frustrating...
if people
 start voting against future 2.4.x rcs because Windows builds
are broken
 in some way which was trivial to catch in CI and fix ahead of
time.

 Example trunk failure: https://github.com/apache/httpd/actions/
 runs/25912053842/job/76159381743

 2.4.x failure is "simpler" because of the cmake version mismatch:
 https://github.com/apache/httpd/actions/runs/25488877019/
 job/74791446628
 but working around that as suggested did not help.

 Regards, Joe

 [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-
 windows-ci
>>>
>>> Branch 2.4.x needs this change to be backported: https://
github.com/
>>> apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24
>>
>> Does that definitely work? I tried -
DCMAKE_POLICY_VERSION_MINIMUM=3.5
>> and it failed:
>> https://github.com/apache/httpd/actions/runs/26754488163/
job/78850661003
>
> Ah!  I didn't notice that attempt.  To answer your question: yes
that
> CMake change that I made works.  The run that you pointed to you
here
> makes it past that (thanks to that fix) and now breaks on a
different
> issue.
>
> I had made a change locally to avoid that error: Unexpected
enablement
> value "i" for mod_authnz_ldap
>
> But I wasn't proud of my workaround, and now I realize that I
should
> create a pull request for my workaround for that "i" error (if I
> remember, I had to "unset(i)" outside of a for loop, to avoid that
> error.  Will file a new pull request now (to the 2.4.x branch,
if you
> already applied the other fix that I mentioned).
>
>>
>>> PS. Suggest to use the Backport action in the httpd repo (we
use this
>>> and it
>>> works beautifully https://github.com/MapServer/MapServer/blob/
>>> main/.github/workflows/backport.yml
>>> )
>>
>> Sounds useful with writeable git ;)
>>
>>> Regarding trunk, there seems to be many changes in trunk that
break the
>>> Windows MSVC compiler, it would take me a while to go through
all of
>>> those
>>> changes (hmm I wonder why those changes made it through your CI
>>> tests / why
>>> they were merged before fixing the tests in Windows - as now
it seems
>>> like a
>>> mountain of fixes are needed)
>>
>> I don't know or care about either cmake or Windows, so I don't
have much
>> invested in this. The Windows CI started failing in early May
and I'm
>> pretty sure it was not the relevant commit to trunk which triggered
>> that, but an image change:
>>
>> https://github.com/apache/httpd/actions/workflows/windows.yml?
>> query=branch%3Atrunk
>>
>> Regards, Joe
>>

New pull request (into branch 2.4.x) :
https://github.com/apache/httpd/pull/657

(backports earlier change, and also tackles the error :
     

Re: help needed: Windows CI broken

[Jeff McKenna]

On 2026-06-02 10:45 a.m., Paul Lodge wrote:

Hi All,

It might be in the best interest to move forward with Vlads suggestion 
for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave the 'i' 
variable unset, as it's not an optimal solution it's ok as a quick fix 
but could potentially cause headaches in the future.


I think that the Windows side of things in general (CMake, tests etc) 
need a little TLC, I don't mind looking into and taking on the task.


Best

Paul


The CMAKE_MINIMUM_REQUIRED and the unset(i) are required to compile 
branch 2.4.x with MSVC (I do this manually, nothing to do with 
Docker/GitHub runner images etc).  I think there is a mixup in 
discussions here, as initially Joe was pointing to a branch 2.4.x run 
that was failing (and gave an error regarding to that "i"), and I 
provided the workaround for that branch, with the 
CMAKE_MINIMUM_REQUIRED, and unset(i).


Trunk is a different story (as I mentioned earlier, there are missing 
file errors/compile errors when compiling on Windows with MSVC now).


-jeff







On 02/06/2026 09:19, Vladimir Chlup wrote:

Hello,

The issue is most likely caused by the change of the default GH 
Actions Windows image. See https://github.com/actions/runner-images/ 
issues/14017 You can try using `windows-2022` instead of the current 
`windows-latest`. It should behave as before.


Alternatively, I have prepared a PR with a fix here: https:// 
github.com/apache/httpd/pull/659


Regards,
Vladimír Chlup


On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna 
 wrote:


On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
> On 2026-06-01 12:39 p.m., Joe Orton wrote:
>> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
>>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
 Windows builds have been failing in CI for a while, I think
because of
 some changes in the GHA images.

 I burnt some Claude tokens trying to fix the trunk to no
avail [1], but
 I have zero interest in this. It will be ... frustrating...
if people
 start voting against future 2.4.x rcs because Windows builds
are broken
 in some way which was trivial to catch in CI and fix ahead of
time.

 Example trunk failure: https://github.com/apache/httpd/actions/
 runs/25912053842/job/76159381743

 2.4.x failure is "simpler" because of the cmake version mismatch:
 https://github.com/apache/httpd/actions/runs/25488877019/
 job/74791446628
 but working around that as suggested did not help.

 Regards, Joe

 [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-
 windows-ci
>>>
>>> Branch 2.4.x needs this change to be backported: https://
github.com/
>>> apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24
>>
>> Does that definitely work? I tried -
DCMAKE_POLICY_VERSION_MINIMUM=3.5
>> and it failed:
>> https://github.com/apache/httpd/actions/runs/26754488163/
job/78850661003
>
> Ah!  I didn't notice that attempt.  To answer your question: yes
that
> CMake change that I made works.  The run that you pointed to you
here
> makes it past that (thanks to that fix) and now breaks on a
different
> issue.
>
> I had made a change locally to avoid that error: Unexpected
enablement
> value "i" for mod_authnz_ldap
>
> But I wasn't proud of my workaround, and now I realize that I
should
> create a pull request for my workaround for that "i" error (if I
> remember, I had to "unset(i)" outside of a for loop, to avoid that
> error.  Will file a new pull request now (to the 2.4.x branch,
if you
> already applied the other fix that I mentioned).
>
>>
>>> PS. Suggest to use the Backport action in the httpd repo (we
use this
>>> and it
>>> works beautifully https://github.com/MapServer/MapServer/blob/
>>> main/.github/workflows/backport.yml
>>> )
>>
>> Sounds useful with writeable git ;)
>>
>>> Regarding trunk, there seems to be many changes in trunk that
break the
>>> Windows MSVC compiler, it would take me a while to go through
all of
>>> those
>>> changes (hmm I wonder why those changes made it through your CI
>>> tests / why
>>> they were merged before fixing the tests in Windows - as now
it seems
>>> like a
>>> mountain of fixes are needed)
>>
>> I don't know or care about either cmake or Windows, so I don't
have much
>> invested in this. The Windows CI started failing in early May
and I'm
>> pretty sure it was not the relevant commit to trunk which triggered
>> that, but an image change:
>>
>> https://github.com/apache/httpd/actions/workflows/windows.yml?
>> query=branch%3Atrunk
>>
>> Regards, Joe
>>

New pull request (into branch 2.4.x) :

Re: help needed: Windows CI broken

[Paul Lodge]

Hi All,

It might be in the best interest to move forward with Vlads suggestion 
for now and update the CMAKE_MINIMUM_REQUIRED but I'd leave the 'i' 
variable unset, as it's not an optimal solution it's ok as a quick fix 
but could potentially cause headaches in the future.


I think that the Windows side of things in general (CMake, tests etc) 
need a little TLC, I don't mind looking into and taking on the task.


Best

Paul


On 02/06/2026 09:19, Vladimir Chlup wrote:

Hello,

The issue is most likely caused by the change of the default GH 
Actions Windows image. See 
https://github.com/actions/runner-images/issues/14017 You can try 
using `windows-2022` instead of the current `windows-latest`. It 
should behave as before.


Alternatively, I have prepared a PR with a fix here: 
https://github.com/apache/httpd/pull/659


Regards,
Vladimír Chlup


On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna 
 wrote:


On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
> On 2026-06-01 12:39 p.m., Joe Orton wrote:
>> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
>>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
 Windows builds have been failing in CI for a while, I think
because of
 some changes in the GHA images.

 I burnt some Claude tokens trying to fix the trunk to no
avail [1], but
 I have zero interest in this. It will be ... frustrating...
if people
 start voting against future 2.4.x rcs because Windows builds
are broken
 in some way which was trivial to catch in CI and fix ahead of
time.

 Example trunk failure: https://github.com/apache/httpd/actions/
 runs/25912053842/job/76159381743

 2.4.x failure is "simpler" because of the cmake version mismatch:
 https://github.com/apache/httpd/actions/runs/25488877019/
 job/74791446628
 but working around that as suggested did not help.

 Regards, Joe

 [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-
 windows-ci
>>>
>>> Branch 2.4.x needs this change to be backported:
https://github.com/
>>> apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24
>>
>> Does that definitely work? I tried
-DCMAKE_POLICY_VERSION_MINIMUM=3.5
>> and it failed:
>>
https://github.com/apache/httpd/actions/runs/26754488163/job/78850661003
>
> Ah!  I didn't notice that attempt.  To answer your question: yes
that
> CMake change that I made works.  The run that you pointed to you
here
> makes it past that (thanks to that fix) and now breaks on a
different
> issue.
>
> I had made a change locally to avoid that error: Unexpected
enablement
> value "i" for mod_authnz_ldap
>
> But I wasn't proud of my workaround, and now I realize that I
should
> create a pull request for my workaround for that "i" error (if I
> remember, I had to "unset(i)" outside of a for loop, to avoid that
> error.  Will file a new pull request now (to the 2.4.x branch,
if you
> already applied the other fix that I mentioned).
>
>>
>>> PS. Suggest to use the Backport action in the httpd repo (we
use this
>>> and it
>>> works beautifully https://github.com/MapServer/MapServer/blob/
>>> main/.github/workflows/backport.yml
>>> )
>>
>> Sounds useful with writeable git ;)
>>
>>> Regarding trunk, there seems to be many changes in trunk that
break the
>>> Windows MSVC compiler, it would take me a while to go through
all of
>>> those
>>> changes (hmm I wonder why those changes made it through your CI
>>> tests / why
>>> they were merged before fixing the tests in Windows - as now
it seems
>>> like a
>>> mountain of fixes are needed)
>>
>> I don't know or care about either cmake or Windows, so I don't
have much
>> invested in this. The Windows CI started failing in early May
and I'm
>> pretty sure it was not the relevant commit to trunk which triggered
>> that, but an image change:
>>
>> https://github.com/apache/httpd/actions/workflows/windows.yml?
>> query=branch%3Atrunk
>>
>> Regards, Joe
>>

New pull request (into branch 2.4.x) :
https://github.com/apache/httpd/pull/657

(backports earlier change, and also tackles the error :
     Unexpected enablement value "i" for mod_authnz_ldap


thanks,

-jeff



-- 
Jeff McKenna

GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/

Re: help needed: Windows CI broken

[Ivan Zhakov]

On Mon, 1 Jun 2026 at 14:55, Joe Orton  wrote:

> Windows builds have been failing in CI for a while, I think because of
> some changes in the GHA images.
>
> I burnt some Claude tokens trying to fix the trunk to no avail [1], but
> I have zero interest in this. It will be ... frustrating... if people
> start voting against future 2.4.x rcs because Windows builds are broken
> in some way which was trivial to catch in CI and fix ahead of time.
>
> Example trunk failure:
> https://github.com/apache/httpd/actions/runs/25912053842/job/76159381743
>
> 2.4.x failure is "simpler" because of the cmake version mismatch:
> https://github.com/apache/httpd/actions/runs/25488877019/job/74791446628
> but working around that as suggested did not help.
>
> Regards, Joe
>
> [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-windows-ci
>
> I have fixed GHA configuration in r1934871.

-- 
Ivan Zhakov

Re: help needed: Windows CI broken

[Vladimir Chlup]

Hello,

The issue is most likely caused by the change of the default GH Actions
Windows image. See https://github.com/actions/runner-images/issues/14017
You can try using `windows-2022` instead of the current `windows-latest`.
It should behave as before.

Alternatively, I have prepared a PR with a fix here:
https://github.com/apache/httpd/pull/659

Regards,
Vladimír Chlup


On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna 
wrote:

> On 2026-06-01 12:53 p.m., Jeff McKenna wrote:
> > On 2026-06-01 12:39 p.m., Joe Orton wrote:
> >> On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
> >>> On 2026-06-01 9:54 a.m., Joe Orton wrote:
>  Windows builds have been failing in CI for a while, I think because of
>  some changes in the GHA images.
> 
>  I burnt some Claude tokens trying to fix the trunk to no avail [1],
> but
>  I have zero interest in this. It will be ... frustrating... if people
>  start voting against future 2.4.x rcs because Windows builds are
> broken
>  in some way which was trivial to catch in CI and fix ahead of time.
> 
>  Example trunk failure: https://github.com/apache/httpd/actions/
>  runs/25912053842/job/76159381743
> 
>  2.4.x failure is "simpler" because of the cmake version mismatch:
>  https://github.com/apache/httpd/actions/runs/25488877019/
>  job/74791446628
>  but working around that as suggested did not help.
> 
>  Regards, Joe
> 
>  [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-
>  windows-ci
> >>>
> >>> Branch 2.4.x needs this change to be backported: https://github.com/
> >>> apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24
> >>
> >> Does that definitely work? I tried -DCMAKE_POLICY_VERSION_MINIMUM=3.5
> >> and it failed:
> >>
> https://github.com/apache/httpd/actions/runs/26754488163/job/78850661003
> >
> > Ah!  I didn't notice that attempt.  To answer your question: yes that
> > CMake change that I made works.  The run that you pointed to you here
> > makes it past that (thanks to that fix) and now breaks on a different
> > issue.
> >
> > I had made a change locally to avoid that error: Unexpected enablement
> > value "i" for mod_authnz_ldap
> >
> > But I wasn't proud of my workaround, and now I realize that I should
> > create a pull request for my workaround for that "i" error (if I
> > remember, I had to "unset(i)" outside of a for loop, to avoid that
> > error.  Will file a new pull request now (to the 2.4.x branch, if you
> > already applied the other fix that I mentioned).
> >
> >>
> >>> PS. Suggest to use the Backport action in the httpd repo (we use this
> >>> and it
> >>> works beautifully https://github.com/MapServer/MapServer/blob/
> >>> main/.github/workflows/backport.yml
> >>> )
> >>
> >> Sounds useful with writeable git ;)
> >>
> >>> Regarding trunk, there seems to be many changes in trunk that break the
> >>> Windows MSVC compiler, it would take me a while to go through all of
> >>> those
> >>> changes (hmm I wonder why those changes made it through your CI
> >>> tests / why
> >>> they were merged before fixing the tests in Windows - as now it seems
> >>> like a
> >>> mountain of fixes are needed)
> >>
> >> I don't know or care about either cmake or Windows, so I don't have much
> >> invested in this. The Windows CI started failing in early May and I'm
> >> pretty sure it was not the relevant commit to trunk which triggered
> >> that, but an image change:
> >>
> >> https://github.com/apache/httpd/actions/workflows/windows.yml?
> >> query=branch%3Atrunk
> >>
> >> Regards, Joe
> >>
>
> New pull request (into branch 2.4.x) :
> https://github.com/apache/httpd/pull/657
>
> (backports earlier change, and also tackles the error :
>  Unexpected enablement value "i" for mod_authnz_ldap
>
>
> thanks,
>
> -jeff
>
>
>
> --
> Jeff McKenna
> GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
> co-founder of FOSS4G
> http://gatewaygeo.com/
>
>

Re: help needed: Windows CI broken

[Jeff McKenna]

On 2026-06-01 12:53 p.m., Jeff McKenna wrote:

On 2026-06-01 12:39 p.m., Joe Orton wrote:

On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:

On 2026-06-01 9:54 a.m., Joe Orton wrote:

Windows builds have been failing in CI for a while, I think because of
some changes in the GHA images.

I burnt some Claude tokens trying to fix the trunk to no avail [1], but
I have zero interest in this. It will be ... frustrating... if people
start voting against future 2.4.x rcs because Windows builds are broken
in some way which was trivial to catch in CI and fix ahead of time.

Example trunk failure: https://github.com/apache/httpd/actions/ 
runs/25912053842/job/76159381743


2.4.x failure is "simpler" because of the cmake version mismatch:
https://github.com/apache/httpd/actions/runs/25488877019/ 
job/74791446628

but working around that as suggested did not help.

Regards, Joe

[1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix- 
windows-ci


Branch 2.4.x needs this change to be backported: https://github.com/ 
apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24


Does that definitely work? I tried -DCMAKE_POLICY_VERSION_MINIMUM=3.5
and it failed:
https://github.com/apache/httpd/actions/runs/26754488163/job/78850661003


Ah!  I didn't notice that attempt.  To answer your question: yes that 
CMake change that I made works.  The run that you pointed to you here 
makes it past that (thanks to that fix) and now breaks on a different 
issue.


I had made a change locally to avoid that error: Unexpected enablement 
value "i" for mod_authnz_ldap


But I wasn't proud of my workaround, and now I realize that I should 
create a pull request for my workaround for that "i" error (if I 
remember, I had to "unset(i)" outside of a for loop, to avoid that 
error.  Will file a new pull request now (to the 2.4.x branch, if you 
already applied the other fix that I mentioned).




PS. Suggest to use the Backport action in the httpd repo (we use this 
and it
works beautifully https://github.com/MapServer/MapServer/blob/ 
main/.github/workflows/backport.yml

)


Sounds useful with writeable git ;)


Regarding trunk, there seems to be many changes in trunk that break the
Windows MSVC compiler, it would take me a while to go through all of 
those
changes (hmm I wonder why those changes made it through your CI 
tests / why
they were merged before fixing the tests in Windows - as now it seems 
like a

mountain of fixes are needed)


I don't know or care about either cmake or Windows, so I don't have much
invested in this. The Windows CI started failing in early May and I'm
pretty sure it was not the relevant commit to trunk which triggered
that, but an image change:

https://github.com/apache/httpd/actions/workflows/windows.yml? 
query=branch%3Atrunk


Regards, Joe



New pull request (into branch 2.4.x) : 
https://github.com/apache/httpd/pull/657


(backports earlier change, and also tackles the error :
Unexpected enablement value "i" for mod_authnz_ldap


thanks,

-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/

Re: help needed: Windows CI broken

[Jeff McKenna]

On 2026-06-01 12:39 p.m., Joe Orton wrote:

On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:

On 2026-06-01 9:54 a.m., Joe Orton wrote:

Windows builds have been failing in CI for a while, I think because of
some changes in the GHA images.

I burnt some Claude tokens trying to fix the trunk to no avail [1], but
I have zero interest in this. It will be ... frustrating... if people
start voting against future 2.4.x rcs because Windows builds are broken
in some way which was trivial to catch in CI and fix ahead of time.

Example trunk failure: 
https://github.com/apache/httpd/actions/runs/25912053842/job/76159381743

2.4.x failure is "simpler" because of the cmake version mismatch:
https://github.com/apache/httpd/actions/runs/25488877019/job/74791446628
but working around that as suggested did not help.

Regards, Joe

[1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-windows-ci


Branch 2.4.x needs this change to be backported: 
https://github.com/apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24


Does that definitely work? I tried -DCMAKE_POLICY_VERSION_MINIMUM=3.5
and it failed:
https://github.com/apache/httpd/actions/runs/26754488163/job/78850661003


Ah!  I didn't notice that attempt.  To answer your question: yes that 
CMake change that I made works.  The run that you pointed to you here 
makes it past that (thanks to that fix) and now breaks on a different issue.


I had made a change locally to avoid that error: Unexpected enablement 
value "i" for mod_authnz_ldap


But I wasn't proud of my workaround, and now I realize that I should 
create a pull request for my workaround for that "i" error (if I 
remember, I had to "unset(i)" outside of a for loop, to avoid that 
error.  Will file a new pull request now (to the 2.4.x branch, if you 
already applied the other fix that I mentioned).





PS. Suggest to use the Backport action in the httpd repo (we use this and it
works beautifully 
https://github.com/MapServer/MapServer/blob/main/.github/workflows/backport.yml
)


Sounds useful with writeable git ;)


Regarding trunk, there seems to be many changes in trunk that break the
Windows MSVC compiler, it would take me a while to go through all of those
changes (hmm I wonder why those changes made it through your CI tests / why
they were merged before fixing the tests in Windows - as now it seems like a
mountain of fixes are needed)


I don't know or care about either cmake or Windows, so I don't have much
invested in this. The Windows CI started failing in early May and I'm
pretty sure it was not the relevant commit to trunk which triggered
that, but an image change:

https://github.com/apache/httpd/actions/workflows/windows.yml?query=branch%3Atrunk

Regards, Joe



thanks,

-jeff


--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/

Re: help needed: Windows CI broken

[Joe Orton]

On Mon, Jun 01, 2026 at 12:24:14PM -0300, Jeff McKenna wrote:
> On 2026-06-01 9:54 a.m., Joe Orton wrote:
> > Windows builds have been failing in CI for a while, I think because of
> > some changes in the GHA images.
> > 
> > I burnt some Claude tokens trying to fix the trunk to no avail [1], but
> > I have zero interest in this. It will be ... frustrating... if people
> > start voting against future 2.4.x rcs because Windows builds are broken
> > in some way which was trivial to catch in CI and fix ahead of time.
> > 
> > Example trunk failure: 
> > https://github.com/apache/httpd/actions/runs/25912053842/job/76159381743
> > 
> > 2.4.x failure is "simpler" because of the cmake version mismatch:
> > https://github.com/apache/httpd/actions/runs/25488877019/job/74791446628
> > but working around that as suggested did not help.
> > 
> > Regards, Joe
> > 
> > [1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-windows-ci
> 
> Branch 2.4.x needs this change to be backported: 
> https://github.com/apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24

Does that definitely work? I tried -DCMAKE_POLICY_VERSION_MINIMUM=3.5 
and it failed:
https://github.com/apache/httpd/actions/runs/26754488163/job/78850661003

> PS. Suggest to use the Backport action in the httpd repo (we use this and it
> works beautifully 
> https://github.com/MapServer/MapServer/blob/main/.github/workflows/backport.yml
> )

Sounds useful with writeable git ;)

> Regarding trunk, there seems to be many changes in trunk that break the
> Windows MSVC compiler, it would take me a while to go through all of those
> changes (hmm I wonder why those changes made it through your CI tests / why
> they were merged before fixing the tests in Windows - as now it seems like a
> mountain of fixes are needed)

I don't know or care about either cmake or Windows, so I don't have much 
invested in this. The Windows CI started failing in early May and I'm 
pretty sure it was not the relevant commit to trunk which triggered 
that, but an image change:

https://github.com/apache/httpd/actions/workflows/windows.yml?query=branch%3Atrunk

Regards, Joe

Re: help needed: Windows CI broken

[Jeff McKenna]

On 2026-06-01 12:24 p.m., Jeff McKenna wrote:

On 2026-06-01 9:54 a.m., Joe Orton wrote:

Windows builds have been failing in CI for a while, I think because of
some changes in the GHA images.

I burnt some Claude tokens trying to fix the trunk to no avail [1], but
I have zero interest in this. It will be ... frustrating... if people
start voting against future 2.4.x rcs because Windows builds are broken
in some way which was trivial to catch in CI and fix ahead of time.

Example trunk failure: https://github.com/apache/httpd/actions/ 
runs/25912053842/job/76159381743


2.4.x failure is "simpler" because of the cmake version mismatch:
https://github.com/apache/httpd/actions/runs/25488877019/job/74791446628
but working around that as suggested did not help.

Regards, Joe

[1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-windows-ci




Branch 2.4.x needs this change to be backported: https://github.com/ 
apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24


PS. Suggest to use the Backport action in the httpd repo (we use this 
and it works beautifully https://github.com/MapServer/MapServer/blob/ 
main/.github/workflows/backport.yml )


Regarding trunk, there seems to be many changes in trunk that break the 
Windows MSVC compiler, it would take me a while to go through all of 
those changes (hmm I wonder why those changes made it through your CI 
tests / why they were merged before fixing the tests in Windows - as now 
it seems like a mountain of fixes are needed)


-jeff





If you don't want to use the automated "Backport" action, then the 
equivalent command is "git cherry-pick" to grab that change and apply it 
to the 2.4.x branch (I don't have privileges on that repo to do that 
command).


Or do you want me to do 2 separate pull requests each time (one into 
trunk, and one into 2.4.x)?  But that seems odd.  But let me know, thanks,


-jeff



-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/

Re: help needed: Windows CI broken

[Jeff McKenna]

On 2026-06-01 9:54 a.m., Joe Orton wrote:

Windows builds have been failing in CI for a while, I think because of
some changes in the GHA images.

I burnt some Claude tokens trying to fix the trunk to no avail [1], but
I have zero interest in this. It will be ... frustrating... if people
start voting against future 2.4.x rcs because Windows builds are broken
in some way which was trivial to catch in CI and fix ahead of time.

Example trunk failure: 
https://github.com/apache/httpd/actions/runs/25912053842/job/76159381743

2.4.x failure is "simpler" because of the cmake version mismatch:
https://github.com/apache/httpd/actions/runs/25488877019/job/74791446628
but working around that as suggested did not help.

Regards, Joe

[1] https://github.com/notroj/httpd/tree/refs/heads/maybe-fix-windows-ci




Branch 2.4.x needs this change to be backported: 
https://github.com/apache/httpd/commit/08138ac986851217ff8f03b495d12ceca9051e24


PS. Suggest to use the Backport action in the httpd repo (we use this 
and it works beautifully 
https://github.com/MapServer/MapServer/blob/main/.github/workflows/backport.yml 
)


Regarding trunk, there seems to be many changes in trunk that break the 
Windows MSVC compiler, it would take me a while to go through all of 
those changes (hmm I wonder why those changes made it through your CI 
tests / why they were merged before fixing the tests in Windows - as now 
it seems like a mountain of fixes are needed)


-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/