Re: help needed: Windows CI broken
Jeff McKenna <[email protected]> Tue, 2 Jun 2026 13:02:22 -0300
| Newsgroups | gmane.comp.apache.devel |
|---|---|
| Message-ID | <[email protected]> |
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/ > <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 <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 > <[email protected] <mailto:[email protected]>> > 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/ <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 <http://github.com/apache/ > httpd/pull/659> > >> > >> Regards, > >> Vladimír Chlup > >> > >> > >> On Mon, Jun 1, 2026 at 6:45 PM Jeff McKenna > >> <[email protected] > <mailto:[email protected]>> 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/ <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/ <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- <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/ <http://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/ > <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/ <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 <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 <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/ <http://gatewaygeo.com/> > >> > > > -- > Jeff McKenna > GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev > co-founder of FOSS4G > http://gatewaygeo.com/ <http://gatewaygeo.com/> > -- Jeff McKenna GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev co-founder of FOSS4G http://gatewaygeo.com/