[liblzma] Build error on x64-osx about vcpkg

[hsowschultz]

The main issue for liblzma failing to be downloaded due to github having disabled the repository

THIS IS WORKAROUND Not smart but works .

The trick is to put the file tukaani-project-xz-v5.4.4.tar.gz in the vcpkg download folder, then vcpkg will not try to download it.

First download: v5.4.4.tar.gz from

https://github.com/bminor/xz/archive/refs/tags/v5.4.4.tar.gz [does not longer work)

rename v5.4.4.tar.gz to tukaani-project-xz-v5.4.4.tar.gz

The version for liblzma in the vcpkg json in your own ProjectSourceCode Folder has to be pinned to version 5.4.4 until there is a clean version available. (fixed Versions are defined in the "overrides" section in your vcpkg json for your project)

"overrides": [
{
"name": "liblzma",
"version": "5.4.4"
}
]

NOTE: This is to prevent a higher version from being installed by mistake if there is still one in the vcpkg download folder. Alternatively, search your vcpkg download folder and remove all versions > 5.4.4.

Then it should work.

-- Using cached tukaani-project-xz-v5.4.4.tar.gz.

-- Extracting source D:/vcpkg/downloads/tukaani-project-xz-v5.4.4.tar.gz

[redcode]

I encountered the same problem because https://github.com/tukaani-project/xz/archive/v5.4.4.tar.gz Unavailability caused installation and construction of cgal to fail. How to solve this problem?

XZ Utils has fallen victim to a malicious maintainer, who tried to introduce a backdoor into liblzma. As soon as it was discovered, GitHub shut down its repo to prevent users from downloading dangerous software. This obviously breaks package managers that download the source code tarball of xz from GitHub.

[redcode]

Same here. It also fails in my CI:

Building liblzma:[email protected]...
C:\Users\runneradmin\AppData\Local\vcpkg\registries\git-trees\f285b7c4ffa2cc065c7c6fec4b61006f7fa2714e: info: installing overlay port from here
-- Downloading https://github.com/tukaani-project/xz/archive/v5.4.4.tar.gz -> tukaani-project-xz-v5.4.4.tar.gz...
[DEBUG] To include the environment variables in debug output, pass --debug-env
[DEBUG] Trying to load bundleconfig from C:\vcpkg\vcpkg-bundle.json
[DEBUG] Failed to open: C:\vcpkg\vcpkg-bundle.json
[DEBUG] Bundle config: readonly=false, usegitregistry=false, embeddedsha=nullopt, deployment=Git, vsversion=nullopt
[DEBUG] Metrics enabled.
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] Feature flag 'dependencygraph' unset
Downloading https://github.com/tukaani-project/xz/archive/v5.4.4.tar.gz
[DEBUG] Trying to hash C:\vcpkg\downloads\tukaani-project-xz-v5.4.4.tar.gz.1552.part
[DEBUG] C:\vcpkg\downloads\tukaani-project-xz-v5.4.4.tar.gz.1552.part has hash fd415aaf330420ad2fe4c34df3b95bacaaaaeecca61a3a61d96c73cead76b6a75f1efc500913d89cea660d29ecc692559562c149c4b893006d67e0ee404f8009
error: Failed to download from mirror set
error: File does not have the expected hash:
url: https://github.com/tukaani-project/xz/archive/v5.4.4.tar.gz
File: C:\vcpkg\downloads\tukaani-project-xz-v5.4.4.tar.gz.1552.part
Expected hash: c28461123562564e030f3f733f078bc4c840e87598d9f4b718d4bca639120d8133f969c45d7bdc62f33f081d789ec0f14a1791fb7da18515682bfe3c0c7362e0
Actual hash: fd415aaf330420ad2fe4c34df3b95bacaaaaeecca61a3a61d96c73cead76b6a75f1efc500913d89cea660d29ecc692559562c149c4b893006d67e0ee404f8009
[DEBUG] D:\a\_work\1\s\src\vcpkg\base\downloads.cpp(1031): 
[DEBUG] Time in subprocesses: 0us
[DEBUG] Time in parsing JSON: 5us
[DEBUG] Time in JSON reader: 0us
[DEBUG] Time in filesystem: 706us
[DEBUG] Time in loading ports: 0us
[DEBUG] Exiting after 141 ms (133052us)

CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:32 (message):
      
      Failed to download file with error: 1
      If you are using 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. If you are using Windows, vcpkg will automatically use your Windows IE Proxy Settings
         set by your proxy software. See https://github.com/microsoft/vcpkg-tool/pull/77
         The value set by your proxy might be wrong, or have same `https://` prefix issue.
      
      3. Your proxy's remote server is out of service.
      
      If you've tried directly download the link, and believe this is not a temporary
      download server failure, please submit an issue at https://github.com/Microsoft/vcpkg/issues
      to report this upstream download server failure.
      

Call Stack (most recent call first):
  scripts/cmake/vcpkg_download_distfile.cmake:270 (z_vcpkg_download_distfile_show_proxy_and_fail)
  scripts/cmake/vcpkg_from_github.cmake:106 (vcpkg_download_distfile)
  C:/Users/runneradmin/AppData/Local/vcpkg/registries/git-trees/f285b7c4ffa2cc065c7c6fec4b61006f7fa2714e/portfile.cmake:1 (vcpkg_from_github)
  scripts/ports.cmake:175 (include)


error: building liblzma:x64-windows failed with: BUILD_FAILED

[rongguangyiii]

I encountered the same problem because https://github.com/tukaani-project/xz/archive/v5.4.4.tar.gz Unavailability caused installation and construction of cgal to fail. How to solve this problem?

[hsowschultz]

Here an example vcpkg.json NOTE: Pinning to fixed Version is the part in the "overrides" section

`{
"$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
"name": "Example",
"version": "2.0.0",
"dependencies": [
{
"name": "armadillo"
}
],
"builtin-baseline": "11ed79186fe850bd3a98cfbf1854514d2b3070a2"

}"overrides": [
{
"name": "armadillo",
"version": "12.6.6"
},
{
"name": "liblzma",
"version": "5.4.4"
}
]
}`

[nidhinsoni]

The trick is to put the file tukaani-project-xz-v5.4.4.tar.gz in the vcpkg download folder, then it will not try to download it. https://github.com/bminor/xz/archive/refs/tags/v5.4.4.tar.gz

v5.4.4.tar.gz rename to tukaani-project-xz-v5.4.4.tar.gz

And the version in the json.has to be pinned in CMake to 5.4.4.

{ "name": "liblzma", "version": "5.4.4" }

Then it should work.

-- Using cached tukaani-project-xz-v5.4.4.tar.gz.

-- Extracting source D:/vcpkg/downloads/tukaani-project-xz-v5.4.4.tar.gz

" And the version in the json.has to be pinned in CMake to 5.4.4." can you please explain this part again. Where exactly can i find this file?

[hsowschultz]

" And the version in the json.has to be pinned in CMake to 5.4.4." can you please explain this part again. Where exactly can i find this file?

This is the vcpkg.json which should be in your ProjectSourceCode Folder..see also:
https://learn.microsoft.com/de-de/vcpkg/reference/vcpkg-json

[nidhinsoni]

" And the version in the json.has to be pinned in CMake to 5.4.4." can you please explain this part again. Where exactly can i find this file?

This is the vcpkg.json which should be in your ProjectSourceCode Folder..see also: https://learn.microsoft.com/de-de/vcpkg/reference/vcpkg-json

By ProjectSourceCode folder, do you mean the vcpkg>ports>liblzma>vcpkg.json? Because that is already set to { "name": "liblzma", "version": "5.4.4" }

[hsowschultz]

This is the vcpkg.json which should be in your ProjectSourceCode Folder..see also: https://learn.microsoft.com/de-de/vcpkg/reference/vcpkg-json

By ProjectSourceCode folder, do you mean the vcpkg>ports>liblzma>vcpkg.json? Because that is already set to { "name": "liblzma", "version": "5.4.4" }

ProjectSourceCode means here NOT the vcpkg Folder..
I mean the folder where your own code is located (assume you use manifest mode)

Look here at min 4.06

[SchaichAlonso]

What's the point of hard-pinning liblzma to version 5.4.4 if vcpkg master, as well as the hard-coded 11ed791 both have version 5.4.4 anyways?

The version hardcoding stuff is to preserve an API / ABI in case your project is not forward compatible to updates of lzma, not to workaround mirroring issues. If the vcpkg port was to be upgraded, it will have to pass the continuous integration to get merged into vcpkg master, which means the CI agents will have to be able to download the distfiles, which right now, they can't, so the mirror issue is addressed by the next commit to lzma, or the commit won't get merged.

[yhyu13]

What's the point of hard-pinning liblzma to version 5.4.4 if vcpkg master, as well as the hard-coded 11ed791 both have version 5.4.4 anyways?

The version hardcoding stuff is to preserve an API / ABI in case your project is not forward compatible to updates of lzma, not to workaround mirroring issues. If the vcpkg port was to be upgraded, it will have to pass the continuous integration to get merged into vcpkg master, which means the CI agents will have to be able to download the distfiles, which right now, they can't, so the mirror issue is addressed by the next commit to lzma, or the commit won't get merged.

That's just a workaround for unlucky dudes to put the fire off. I am lucky enough bc there is a fall back version of builtin baseline vcpkg json in my project that does not need to upgrade lzma to this version or above.

I hope some one smarter could figure out how to fix this dependency becuase the mentioned workaround breaks CI/CD totally.

[SchaichAlonso]

What's the point of hard-pinning liblzma to version 5.4.4 if vcpkg master, as well as the hard-coded 11ed791 both have version 5.4.4 anyways?
The version hardcoding stuff is to preserve an API / ABI in case your project is not forward compatible to updates of lzma, not to workaround mirroring issues. If the vcpkg port was to be upgraded, it will have to pass the continuous integration to get merged into vcpkg master, which means the CI agents will have to be able to download the distfiles, which right now, they can't, so the mirror issue is addressed by the next commit to lzma, or the commit won't get merged.

That's just a workaround for unlucky dudes to put the fire off. I am lucky enough bc there is a fall back version of builtin baseline vcpkg json in my project that does not need to upgrade lzma to this version or above.

I hope some one smarter could figure out how to fix this dependency becuase the mentioned workaround breaks CI/CD totally.

If it's just a workaround that you're looking for, rather then a fix, then, for this specific issue, namely libheif failing to deploy, the liblzma dependency originates in the gdk-pixbuf dependency of libheif, which implies a tiff dependency, which implies a liblzma dependency.

The liblzma dependency in tiff is optional, but enabled by default. You can disable the dependency by asking vcpkg to deploy tiff w/o the lzma feature, either by adding an explicit tiff dependency to the top level project (i.e. the OP's project), which asks for tiff w/o tiff's default features, and as gdk-pixbuf doesn't explicitly require the lzma feature, it'll (hopefully) be usable with a tiff that lacks lzma support, or by manually vcpkg install-ing tiff w/o lzma support before install-ing libheiff.

In manifest mode, replace the libheif dependency line by something like

   "libheif",
    {
      "name": "tiff",
      "default-features": false
    }

In monolithic mode, instead of vcpkg install libheif, use

vcpkg install 'tiff[core]' libheif

[SchaichAlonso]

The main issue for liblzma failing to be downloaded due to github having disabled the repository, btw, is #37893 .

[jminhano]

Te problem continue? im trying to use with vcpkg, but i get the same error.

[LilyWangLL]

Duplicate of #37893.