Arch Linux User Repository

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.

fsck found no errors in the partition. I removed again entire /home/psychowico/.cache/yay/dfhack. The problem is still here, exactly the same error log.

I tried removing the entire /home/psychowico/.cache before I posted the message, but it did not help. I will check fsck approach, but it looks strange - I have no problems with any other package (and I had no problem with the older version of dfhack package). I will let you know about the results here.

@psychowico, you appear to have some corrupted downloads. I don't know if Yay has some way to clear the cache or if you should just delete /home/psychowico/.cache/yay/dfhack/src/ to make it download them again. If you continue to have issues with incorrect hashes you might want to run an fsck on that partition.

Hi. When I am trying to update the package, I got following errors:

...
* Downloading linux64-allegro5010.tar.gz
CMake Error at CMake/DownloadFile.cmake:39 (file):
  file DOWNLOAD HASH mismatch

    for file: [/home/psychowico/.cache/yay/dfhack/src/dfhack/plugins/stonesense/allegro/linux64/linux64-allegro5010.tar.gz]
      expected hash: [343f44224ee61508b89b11adb35a4dd9]
        actual hash: [d41d8cd98f00b204e9800998ecf8427e]
             status: [1;"Unsupported protocol"]

Call Stack (most recent call first):
  plugins/stonesense/CMakeLists.txt:125 (download_file)


tar: This does not look like a tar archive

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
* Downloading linux64-libruby187.so.gz
CMake Error at CMake/DownloadFile.cmake:39 (file):
  file DOWNLOAD HASH mismatch

    for file: [/home/psychowico/.cache/yay/dfhack/src/dfhack/plugins/ruby/linux64/libruby.so.gz]
      expected hash: [8eb757bb9ada08608914d8ca8906c427]
        actual hash: [d41d8cd98f00b204e9800998ecf8427e]
             status: [1;"Unsupported protocol"]

Call Stack (most recent call first):
  CMake/DownloadFile.cmake:50 (download_file)
  plugins/ruby/CMakeLists.txt:23 (download_file_unzip)


* Decompressing linux64-libruby187.so.gz
CMake Error at CMake/DownloadFile.cmake:66 (message):
  MD5 mismatch:
  /home/psychowico/.cache/yay/dfhack/src/dfhack/plugins/ruby/linux64/libruby.so:
  expected e8c36a06f031cfbf02def28169bb5f1f, got
  d41d8cd98f00b204e9800998ecf8427e
Call Stack (most recent call first):
  plugins/ruby/CMakeLists.txt:23 (download_file_unzip)

Sorry, didn't see this - assumed as a co-maintainer I'd get notifications automatically. (I hav now manually enabled them.)

As a work around, you can specify a folder that you hav permission to create with an absolute path. For example exportlegends info /home/ziusudra/export-test worked for me. (dfhack docs say all but the last folder hav to already exist.)

I will confer with the dfhack devs to see if we can get a proper fix.

At some point since 0.47.01, there seems to be a problem with the exportlegends script in this AUR version because of a change upstream. The script appears (since this commit, as far as I can tell) to change directory to the location dfhack is installed, which is apparently assumed to be somewhere in the user's home directory. Because this package, however, installs within /opt/ the script fails because the user does not have write permissions.