-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI failures on macos targets #5159
Comments
I think that's a regression in |
I concur. This seems to be Homebrew having upgraded to cURL v8.10.0; It's hitting git/git's CI, too. While Homebrew did upgrade to v8.10.1 yesterday, the Now, we could update Homebrew every time we run CI, but... that would regress on a work-around git/git specifically introduced to avoid breaking CI builds due to Homebrew changing things around that require So I fear that the only thing we can do is to wait. The good news is that we'll probably not have to wait all that long: From looking at the history of the |
Judging by this announcement which is placed prominently at the top of the current list of included software of the |
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
Turns out that I cannot wait it out: v2.46.2 crashed this party! So I opened #5165 to address this issue so that Git for Windows v2.46.2's CI builds won't show it as broken. |
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
This patch implements a work-around, basically for the sake of Git for Windows v2.46.2's CI build: The `macos-13` runner images still reference libcurl v8.10.0, which has a known flaw that breaks t5559.30. Let's detect this situation and skip that test case in that case. While at it, also backport the work-around for a flaky test case (t5512.40 "helper with refspec capability fails gracefully"). This fixes #5159.
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at git-for-windows#5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
As reported in https://lore.kernel.org/git/[email protected]/, libcurl v8.10.0 had a regression that was picked up by Git's t5559.30 "large fetch-pack requests can be sent using chunked encoding". This bug was fixed in libcurl v8.10.1. Sadly, the macos-13 runner image was updated in the brief window between these two libcurl versions, breaking each and every CI build, as reported at #5159. This would usually not matter, we would just ignore the failing CI builds until the macos-13 runner image is rebuilt in a couple of days, and then the CI builds would succeed again. However. As has become the custom, a surprise Git version was released, and now that Git for Windows wants to follow suit, since Git for Windows has this custom of trying to never release a version with a failing CI build, we _must_ work around it. This patch implements this work-around, basically for the sake of Git for Windows v2.46.2's CI build. Signed-off-by: Johannes Schindelin <[email protected]>
I'm not sure if this is new, but it doesn't seem to be related to my changes in my PR. The PR builds are failing for all macos targets.
Here is one sample error log, though they are all the same:
The text was updated successfully, but these errors were encountered: