[New curl version] 8.7.1

[github-actions]

https://github.com/curl/curl/releases/tag/curl-8_7_1

[dscho]

Let's open the PRs just in case, but wait with deploying them for a few seconds 😁

[dscho]

/open pr

The MSYS workflow run was started

The MINGW workflow run was started

[dscho]

Not yet:

 curl: (22) The requested URL returned error: 404
==> ERROR: Failure while downloading https://github.com/curl/curl/releases/download/curl-8_7_1/curl-8.7.1.tar.bz2

[rimrul]

/open pr

The MSYS workflow run was started

The MINGW workflow run was started

[rimrul]

Let's open the PRs just in case, but wait with deploying them for a few seconds 😁

We should probably wait and see what comes of https://lore.kernel.org/git/20240330000212.GA1261238@coredump.intra.peff.net/T/#u (curl/curl#13229)

[rimrul]

I'm not quite sure how best to handle this. Possible options include

• skip curl 8.7.0 and 8.7.1 and wait for a fixed version. This will likely be curl 8.8.0 which is due to release in may. (too late for Git 2.45.0)
• wait until after Git 2.45.0-rc0 and deploy curl 8.7.1 during the RC phase
• backport curl/curl@721941a into our curl 8.7.1
• pick up git@3242311 and https://lore.kernel.org/git/20240405200451.GA3700566@coredump.intra.peff.net/ early to avoid broken snapshot builds before 2.45.0-rc0
• deploy curl 8.7.1 right before 2.45.0-rc0

[dscho]

My preference would be to do both of these:

• backport curl/curl@721941a into our curl 8.7.1
• pick up git@3242311 and https://lore.kernel.org/git/20240405200451.GA3700566@coredump.intra.peff.net/ early to avoid broken snapshot builds before 2.45.0-rc0

FWIW my hesitance to go forward with deploying cURL is solely due to those hangs on the Windows/ARM64 runners. I still have no idea how to fix the MSYS2 runtime (and I lack the time to reduce the rather unwieldy pacman reproducer into a neat and small reproducer).

My current thinking is that we could add a work-around for the time being:

• add a step in the build-and-deploy workflow that
  • only runs on Windows/ARM64
  • spawns a PowerShell script that runs detached while the workflow continues with the next steps of the job,
  • this PowerShell script would basically loop, and in the loop body it would
    • see if there is any new pacman.exe process that has the exact same command-line as its parent,
    • see such a process has been "alive" for more than, say, 30 seconds, and if so, stop it,
    • sleep something like 10 seconds before continuing with the next loop iteration

The PowerShell script would be a variation of what I used when I logged interactively to unstick builds in the past:

$p = (Get-CimInstance Win32_Process |
  Where-Object {$_.CommandLine -like '*pacman*'} |
  Select-Object CommandLine, ParentProcessId, ProcessId |
  Group-Object CommandLine |
  Where-Object {$_.Count -gt 1} |
  Select-Object -ExpandProperty Group)
if ($p.Length -eq 2 -and $p[0].processId -eq $p[1].parentProcessId) {
  Stop-Process -Force -Id $p[1].processId
}

There's still work to do here: Instead of stopping the process immediately, we should check that:

• It has been running for a while (30 seconds should be plenty, if this is indeed just some shim process that is waiting for a gpg process that is long gone).
• Ideally, we would find a way to determine whether the process itself is idle. One option would be to look at (Get-Process -Id $pid).CPU (which stores the total amount of CPU seconds spent on that process) and require it to change only a fraction over the course of half a minute or so.

[dscho]

My preference would be to do both of these:

• backport curl/curl@721941a into our curl 8.7.1

This is prepared via git-for-windows/MINGW-packages@e5725f2

• pick up git@3242311 and https://lore.kernel.org/git/20240405200451.GA3700566@coredump.intra.peff.net/ early to avoid broken snapshot builds before 2.45.0-rc0

And this via #4906.

[dscho]

My current thinking is that we could add a work-around for the time being:

* add a step in the `build-and-deploy` workflow that
  
  * only runs on Windows/ARM64
  * spawns a PowerShell script that runs detached while the workflow continues with the next steps of the job,
  * this PowerShell script would basically loop, and in the loop body it would
    
    * see if there is any new `pacman.exe` process that has the exact same command-line as its parent,
    * see such a process has been "alive" for more than, say, 30 seconds, and if so, stop it,
    * sleep something like 10 seconds before continuing with the next loop iteration

Hmm. This seems not to have worked as well as I hoped.

[dscho]

This will hopefully provide the work-around we need to proceed.