cygport expects package autoconf version integers but can have suffixes

[Jon Turney]

On 11/01/2026 06:38, Brian Inglis via Cygwin-apps wrote:
> On 2026-01-10 15:25, Brian Inglis wrote:
>> On 2026-01-10 15:04, Jon Turney wrote:
>>> On 10/01/2026 17:01, Brian Inglis via Cygwin-apps wrote:
[...]
>>
>>>> some mitigation appears required as under mingw package build, 
>>>> stdout is closed, and the rest of the compile log and subsequent 
>>>> logs do not appear: see GH Scallywag job 10992 rerunning as 10994!
>>>
>>> Yeah, that seems like a secondary effect.
>>>
>>> Uh, I'm unclear what's happening there to make it hang there with no 
>>> output, and can't immediately reproduce it locally.
>>>
>>> Do you have some more information which leads to the "stdout is 
>>> closed" theory, or is that just speculation?
> 
>> Only happens so far on mingw...gettext build and both times had same 
>> effect but different amount of output in log (buffering amount) 
>> nearing end of config, as also under GH Scallywag; I also run my own 
>> build log time stamper so I can spot hangs during builds.
> 
> A major difference between gettext and mingw builds is mingw does not 
> run autoreconf, so the upstream scripts are used as is.
> 
> On my local system, my timestamped package build process log stopped 
> progressing, but .../log/...compile.log and other logs continued to be 
> appended, so I could follow with xtail.
> 
> Even defining AUTOCONF_VERSION=2.72 on GH Scallwag the process log still 
> stops after creating config.status!

Yeah, this seems like something else is going on.

When I started a run using 'cygport --debug', there's nothing output by 
cygport itself after the configure run is started.

So this makes me think that maybe configure is somehow getting into a 
spin and never finishing? (Maybe you could confirm that by looking at 
what processes are active when it hangs?)

I've tried a few adjustments to my environment, but I still can't 
reproduce this locally.