search

microsoft / vcpkg

C++ Library Manager for Windows, Linux, and MacOS
MIT License
23.27k stars 6.42k forks source link

[bzip2] build failure on vcpkg from 2022.01.01 #23863

Closed ghost closed 2 years ago

ghost commented 2 years ago

Host Environment

To Reproduce Steps to reproduce the behavior: ./vcpkg install bzip2:x64-windows

Failure logs

Building package bzip2[core]:x64-windows...
-- Downloading https://sourceware.org/pub/bzip2/bzip2-1.0.8.tar.gz -> bzip2-1.0.8.tar.gz...
-- Extracting source C:/agents/2.200.2/vcpkg/downloads/bzip2-1.0.8.tar.gz
-- Applying patch fix-import-export-macros.patch
Error: Failed to download from mirror set:
https://repo.msys2.org/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: failed: status code 404
https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: failed: status code 404
https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: failed: status code 404
https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: failed: status code 404
https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: failed: status code 404
https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12007
https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12007
https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12007
https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12007
https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12175
https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12175
https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12175
https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: WinHttpSendRequest() failed: 12175
https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-8.0.0.5906.c9a21571-1-any.pkg.tar.zst: failed: status code 404

CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:84 (message):

      Failed to download file with error: 1
      If you use a proxy, please check your proxy setting. Possible causes are:

      1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
         to `https://address:port`. This is not correct, because `https://` prefix
         claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
         , etc..) is an HTTP proxy. Try setting `http://address:port` to both
         HTTP_PROXY and HTTPS_PROXY instead.

      2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
         will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
         Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
         Change `http=address:port;https=address:port` to `address`, and fill the port number.

      3. You proxy's remote server is out of service.

      In future vcpkg releases, if you are using Windows, you no longer need to set
      HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
      Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)

Error: Building package bzip2:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `git pull` and `.\vcpkg update`.

Additional context This seems to be caused by MSYS dropping older packages after a few years (see e.g. https://github.com/msys2/MINGW-packages/issues/10710#issuecomment-1032834320).

I'm using vcpkg 2022.01.01. Strangely, tags such as 2021.06.31 do work. I noticed that a bunch of these tags were created on feb. 25, but the commit log doesn't explain much, other than them being "backfill" releases. What's the difference between e.g. 2021.06.31 and 2021.06.01?

EDIT: Fixed tag names.

FrankXie05 commented 2 years ago

I believe this was fixed in the master branch. Please update vcpkg and try again. :)

ghost commented 2 years ago

I believe this was fixed in the master branch. Please update vcpkg and try again. :)

Yes, I mentioned this in the "Additional context" section; just switching to one of the tags released on Feb. 25 seems to work. I still don't understand what these "backfill" releases are, etc.

FrankXie05 commented 2 years ago

cc @BillyONeal Could you help take a look this issue? Thanks in advance.

BillyONeal commented 2 years ago

I'm using vcpkg 2022.01.01. Strangely, tags such as 2022.06.31 do work.

msys deletes packages aggressively, breaking older ports. I don't believe there are workarounds other than upgrading the versions of dependencies in use.

ghost commented 2 years ago

I'm using vcpkg 2022.01.01. Strangely, tags such as 2022.06.31 do work.

msys deletes packages aggressively, breaking older ports. I don't believe there are workarounds other than upgrading the versions of dependencies in use.

Yes, I had a discussion with the MSYS maintainers regarding this, and they seem pretty adamant in their position (see e.g. https://github.com/msys2/MINGW-packages/issues/10710#issuecomment-1082734275)

In any case, I'm aware that the issue was originally caused by them deleting old versions of the binaries. The thing is, I still do't know what these "backfill" releases are, nor where it was announced that people should stop using the older tags because they're broken because of MSYS, etc. It would be nice to have some more information about this.

dg0yt commented 2 years ago

The MSYS2 position is reasonable IMO. I would like to add that MSYS2 removes binary artifacts, not build recipes. vpckg simply doesn't publish binary artifacts (and therefore doesn't need to deal with obligations like providing the corresponding sources).

See also the parallel discussion in https://github.com/microsoft/vcpkg/issues/23828:

However, you should be able to use your desired versions of vcpkg ports with the latest HEAD of vcpkg: with manifest mode.

BillyONeal commented 2 years ago

The MSYS2 position is reasonable IMO.

I disagree: people need to be able to go back to older copies of their own sources, build them, and get the exact same output with the exact same tools.

However, I understand that msys may not care about this scenario, no matter how important we think it is. Unfortunately, it does mean that any port that transitively depends on msys will break, and there is very little vcpkg can do to avoid the situation.

Maybe if we used pacman we could avoid this situation but as long as pacman is going to randomly hang on us (which is what forced us to drop that dependency in the first place) I don't think we can go back to doing that.

ghost commented 2 years ago

@BillyONeal regardless of what MSYS2 does, I believe it would be good to have an explanation about what these "backfill" releases are, ideally with a public announcement that everyone using older tags may hit this issue and should update. I take it these "backfill" releases were made precisely to work around this issue?

BillyONeal commented 2 years ago

I don't even know what you mean by "backfill" releases.

ghost commented 2 years ago

I don't even know what you mean by "backfill" releases.

I mean tags like https://github.com/microsoft/vcpkg/releases/tag/2021.06.31, which were made by you on Feb. 25. You use the term "backfill" release in there.

BillyONeal commented 2 years ago

I mean tags like https://github.com/microsoft/vcpkg/releases/tag/2021.06.31, which were made by you on Feb. 25. You use the term "backfill" release in there.

Ah, I just meant that those releases were being made as a one time thing for each month far after the fact. "releases" in this repo are meaningless and will continue to be meaningless, but enough people look to that as evidence of liveness that we've started creating them each month again.

That a vcpkg version refers to something in msys doesn't change anything about msys's corresponding support for that stuff

FrankXie05 commented 2 years ago

@martingalvan-nordic does the issue still occur?

ghost commented 2 years ago

@FrankXie05 as I mentioned in the "Additional context" section, this happens with several tags such as 2022.01.01, while others such as 2021.06.31 work fine. You can take a look at the discussion here for more details.

FrankXie05 commented 2 years ago

@martingalvan-nordic I think Billy has already answered you. :) https://github.com/microsoft/vcpkg/issues/23863#issuecomment-1092323251

ghost commented 2 years ago

@martingalvan-nordic I think Billy has already answered you. :) #23863 (comment)

He did, yes. I still think it would've been good to have an annoucement that anyone using the older tags will have their vcpkg install broken because of this, and that this might happen again at any time in the future due to MSYS's policies; in any case, since there's no other action that can be taken from the vcpkg side, I guess this can be closed.

FrankXie05 commented 2 years ago

@martingalvan-nordic I think the idea is great and I will bring it up and discuss it at next week's meeting. :)

3417725275 commented 2 years ago

So,is the problem been solved ? I meet the same problem

FrankXie05 commented 2 years ago

@3417725275 Make sure you are using the latest vcpkg, run git pull and try again.

foragerDev commented 2 years ago

I am using the latest master, but still getting the same issue. I am on MacOS 12.1.

foragerDev commented 2 years ago

@sfhacker right. What's wrong mentioning the same issue same? Was there something unclear?

FrankXie05 commented 2 years ago

@foragerDev Due to msys2 rolling release policy, currently we can only use the latest msys2 version. Extract file msys-mingw-w64-i686-libwinpthread-git-9.0.0.6373.5be8fcd83-1-any.pkg.tar.zip to directory {VCPKG_ROOT_DIR}/downloads.

dg0yt commented 2 years ago

@foragerDev This issue is already mixing multiple problems, and it was closed. If you say you have the same problem, it is not really clear which particular sub-issue you are refering to. And if you say you are using the latest master, it doesn't help, This issue is not about the latest master, and the latest master builds at least three times a week in vcpkg CI. If you need help, open an issue with an exact description of your particular problem.