Arch Linux User Repository

I think I found the root of the issue. I had an old version of cmake in the system. Indeed I have the newest version installed by pacman, but the system, for some reason, still has an old binary file (cmake version 3.4.1) of cmake in /usr/local/bin directory. I just moved it to /usr/local/bin/cmake.bak, reinstalled the cmake, and all worked.

I am not sure how it happens, but I suspect the Antergos linux. Just before the Antergos died, I installed it on the machine as an experiment. After it falls, I did not reinstall the system - I just migrated to a clean arch. It looks like there are still some leftovers.

Sorry for the confusion, and thanks for your fantastic support. I am amazed at how helpful and responsive the dwarf-fortress related community is ;)

Thanks. I will try to dig deeper later, maybe I will figure out something. The interesting part is that no other applications give me problems with installation/update on this OS.

The second interesting part is that I have installed DFHack before using yay -, but I can not update it to the newer version.

Thanks for your support.

Well, the URL is correct and curl claims to support https, so I'm at a loss. We appear to have the same plugins/stonesense/CMakeLists.txt file and curl. Something on your computer is making curl give the 1;"Unsupported protocol" error and I don't know how to find out what.

Your options at this point are: ask on the Arch forums and/or submit an issue at the DFHack github. As a temporary work around you could you could change that plugins/stonesense/CMakeLists.txt file to use http, download the files manually, or switch to the dfhack-bin AUR package.

I gotta get some sleep, etc so I'll be offline for at least 10 hours.

Output of curl -V:

curl 7.73.0 (x86_64-pc-linux-gnu) libcurl/7.73.0 OpenSSL/1.1.1h zlib/1.2.11 zstd/1.4.5 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
Release-Date: 2020-10-14
Protocols: dict file ftp ftps gopher http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

OK, what's the output of curl -V?

The output of: grep -A 6 -B 3 linux64-allegro5010.tar.gz ".../CMakeLists.txt"

        IF(STONESENSE_INTERNAL_SO)
            set(ALLEGRO_DOWNLOAD_DIR ${stonesense_SOURCE_DIR}/allegro/linux${DFHACK_BUILD_ARCH})
            if("${DFHACK_BUILD_ARCH}" STREQUAL "64")
                set(ALLEGRO_DOWNLOAD_FILE "linux64-allegro5010.tar.gz")
                download_file("https://github.com/DFHack/dfhack-bin/releases/download/0.44.09/linux64-allegro5010.tar.gz"
                    "${ALLEGRO_DOWNLOAD_DIR}/${ALLEGRO_DOWNLOAD_FILE}"
                    "343f44224ee61508b89b11adb35a4dd9")
            else()
                set(ALLEGRO_DOWNLOAD_FILE "linux32-allegro509b.tar.bz2")
                download_file("https://github.com/DFHack/dfhack-bin/releases/download/0.44.09/linux32-allegro509b.tar.bz2"
                    "${ALLEGRO_DOWNLOAD_DIR}/${ALLEGRO_DOWNLOAD_FILE}"

cURL is saying status: [1;"Unsupported protocol"] which explains the empty files. But I don't know why it would do that.

After getting the error, what is the output of grep linux64-allegro5010.tar.gz "/home/psychowico/.cache/yay/dfhack/src/dfhack/plugins/stonesense/CMakeLists.txt"

And do the downloaded files have the same incorrect hash as before? Yes. It's the same incorrect hash like in my comment before.

I think it's not caching the files anywhere. On the beginning it ask me if it should use cache:

  1 dfhack                                   (Installed) (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 1
:: Deleting (1/1): /home/psychowico/.cache/yay/dfhack

I see the entire process when the yay download the files first (it takes some time) and the got error on verification step.

I checked all files: "linux64-allegro5010.tar.gz", "libruby.so.gz" and "libruby.so" and they have 0 bytes. Any idea what could going on?

And do the downloaded files have the same incorrect hash as before? Yes. It's the same incorrect hash like in my comment before.

I think it's not caching the files anywhere. On the beginning it ask me if it should use cache:

  1 dfhack                                   (Installed) (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 1
:: Deleting (1/1): /home/psychowico/.cache/yay/dfhack

I see the entire process when the yay download the files first (it takes some time) and the got error on verification step.

I checked all files: "linux64-allegro5010.tar.gz", "libruby.so.gz" and "libruby.so" and they have 0 bytes. Any idea what could going on?

And do the downloaded files have the same incorrect hash as before?

I just deleted my src/ and rebuilt the package and it downloaded those same files with the correct hash.

Maybe Yay has another place where it caches files. At this point I'd try asking in the Arch forums to get more help trying to figure out why you're getting corrupt files.

I'd also try manually using gzip to verify the downloaded files. Um, --test is what gzip calls it.