[vcpkg-acquire-msys] Update pacman before any other package.#11443
[vcpkg-acquire-msys] Update pacman before any other package.#11443BillyONeal merged 2 commits intomicrosoft:masterfrom
Conversation
|
try checking the port to see if there will be an error |
|
I tested it with |
|
Waiting for merge #11459. |
|
so it works locally for you, but in Ci ? |
|
Could you please direct me to the said error message in CI? (afaict the logs of failed checks in this PR contain only some unrelated protobuf errors) |
JackBoosY
left a comment
JackBoosY
left a comment
There was a problem hiding this comment.
Could you please update the vesion info in ports/ffmpeg/CONTROL to test the changes?
See documentation.
|
Looks like |
|
Waiting for upstream to provide a solution... |
|
There are two possibilities:
|
|
wait for to removed symbolic links |
emptyVoid
force-pushed
the
fix-issue-11438
branch
from
a7311bd to
5f4ebf9
Compare
|
Should probably go with #11471 as a member of MSYS2 confirms persistence of GitHub releases (msys2/MSYS2-packages#1962 (comment)). |
Doesn't appear to have fixed the issue. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
It looks like the current msys breakage causes our builders to become wedged afterwards so we need to accept this or #11471 after we've explicitly removed all the builders to get a clean pass. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I browsed though failing logs after the force-push and it looked like as if CI continued from the state CI's new Windows runs have completed too quickly (apparently |
|
@emptyVoid Given how everything related to msys is bricking builders right now I think we should choose whether we take this one or the other one before doing further investigation |
|
Looks like this PR is working while the other one leaves ffmpeg broken: |
JackBoosY
added
the
info:needs-maintainer-attention
|
Given that this fixes CI I'm going to merge this one, that does not mean we aren't necessarily interested in the more complete updates in the other one. |
|
Thanks for your contribution! |
|
Hi @emptyVoid, it seems broken again: Could you please check that? Thanks, |
|
Hi @JackBoosY, could you elaborate, please, on how to reproduce the issue? I've just tested If I had to guess I'd say the issue manifests on some non-clean install where I think this could be fixed by updating And it looks like the workaround this PR added is no longer needed: |
|
@emptyVoid I can repro this issue by installing If these changes are not needed, please open a new PR to remove them. Thanks. |
|
After remove downloads/tools/msys2 and rebuild If the old msys files may cause errors after upgrade, we should install msys in a directory named after the version number. |
|
The version number of In my opinion the troublesome part of vcpkg/scripts/cmake/vcpkg_acquire_msys.cmake Line 168 in e792d1c the -Sy key instructs pacman to update its package database before installing requested packages. Because of it an old pacman then tries to install a package with an unsupported compression.
I see a few ways how to deal with it:
Approaches (1) and (3) guarantee all the |
JackBoosY
added
the
category:tool-update
5 participants
Describe the pull request
Adjusts
vcpkg_acquire_msysfunction to updateMSYS2package manager (pacman) before updating any other package to work around package manager's issues (e.g. msys2/MSYS2-packages#1962).What does your PR fix?
Fixes [icu[core]:x64-windows] build failure #11438
Which triplets are supported/not supported? Have you updated the CI baseline?
Not applicable.
Does your PR follow the maintainer guide?
Yes.