Package Details: dfhack 0.47.05-7

Git Clone URL: https://aur.archlinux.org/dfhack.git (read-only, click to copy)
Package Base: dfhack
Description: memory hacking library for Dwarf Fortress and a set of tools that use it
Upstream URL: https://dfhack.readthedocs.io/en/stable/
Keywords: dwarffortress
Licenses: custom
Conflicts: dfhack-bin, dfhack-git
Submitter: unknown
Maintainer: wookietreiber (albron, Ziusudra)
Last Packager: Ziusudra
Votes: 36
Popularity: 0.000503
First Submitted: 2011-08-07 11:03 (UTC)
Last Updated: 2022-05-05 06:18 (UTC)

Latest Comments

dcunningham commented on 2022-04-15 18:58 (UTC) (edited on 2022-04-15 19:46 (UTC) by dcunningham)

Getting an error that says 'Main index file missing/corrupted. The file "index" must be in the "data" folder. Make sure DF decompressed into its folders properly.'

I installed dwarffortress separately/normally from the official repos - looks like it's version 0.47.05-2. It works fine if I run it with dwarffortress, only fails when I start with dfhack.

There's an index file in both /opt/data/ and ~/.dwarffortress/data/ - do I need to do something special to make sure dfhack is looking in the right place?

AFAIK, I have the same situation on another machine, dfhack 0.47.05-4 on top of dwarfortress from the official repos and haven't had a problem there.

Nevermind, for some reason, this machine had dfhack aliased to /opt/dwarffortress/dfhack. Removed that and all is well.

wookietreiber commented on 2021-12-13 09:21 (UTC)

@brknrobot Can this be done on your end with:

CC=gcc CXX=g++ makepkg

I'm not sure what the package guidelines are on overriding compilers and/or other settings.

brknrobot commented on 2021-12-10 22:05 (UTC) (edited on 2021-12-10 22:06 (UTC) by brknrobot)

dfhack only compiles with gcc. Perhaps you could add

export CC=gcc
export CXX=g++

for those of us who have switched our default compiler to clang :)

Ziusudra commented on 2021-02-12 19:56 (UTC)

So, why hide the DFHack version in the PKGBUILD other than to hide the fact that you're pushing betas in a so called stable package? The upstream URL even has the word "stable" in it.

Sleedy, the operative word in your quote is "built". DFHack does not require a version of DF to build, only to run.

It is trivially easy for users that want to use the betas to do so. By pushing betas in a package that doesn't make it obvious that they're betas, you make it harder for those that don't want to use betas to avoid them.

sleedy commented on 2021-02-12 18:42 (UTC) (edited on 2021-02-12 18:43 (UTC) by sleedy)

@Ziusudra The link you refer to states the following:

Stable packages package stable releases: Release candidates (i.e. 1.0.0-rc1), alpha (e.g. 1.0.0-alpha1) and beta (e.g. 1.0.0-beta1) releases are not allowed and are only to be used under the following circumstances:

  • [...]

  • The non-stable release allows for the package to be built (e.g. problems introduced due to updated dependencies) and those changes can not otherwise be backported easily.

wookietreiber commented on 2021-02-12 13:15 (UTC)

Pushed the new version a few hours ago. I've been making AUR releases for the beta's in the past as well, so I'll keep on doing that.

Ziusudra commented on 2021-02-12 08:52 (UTC)

It having been done in the past does not make it ok, in my opinion.

It currently builds just fine, and runs fine with the matching DF version, it just doesn't run with the updated DF, which is what holding a package in pacman.conf is for.

The -git package conflict is there in case anyone does make that package, which anyone is welcome to do.

henkm commented on 2021-02-12 08:24 (UTC)

If you check the version history, you can see that in the past beta packages were released and even alpha packages. In my opinion,it is correct to do so because the current package can not be built due to upgraded dependencies (DF itself). But it's your call. Please also note that though a dfhack-git package is mentioned in conflicts, such a package does not actually exist.

Ziusudra commented on 2021-02-12 06:18 (UTC)

https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning

So that page specifies that "Stable packages package stable releases" and the current beta release does not qualify for any of the exceptions.

Ziusudra commented on 2021-01-31 21:36 (UTC)

FYI, 0.47.04-7 is a new release for the previous version of DF, a new release for the current version is coming. The impatient can install DF manually and install an unstable DFHack build on that. See https://dwarffortresswiki.org/index.php/DF2014:Installation#Manual_or_multiple_installations and https://dfhack.org/builds/

Ziusudra commented on 2020-11-13 05:15 (UTC)

The issues with DFHack being unable to write files has been fixed upstream¹ and a new release should be available soon. The impatient could install DF+DFHack manually: https://dwarffortresswiki.org/index.php/DF2014:Installation#Manual_or_multiple_installations

¹ https://github.com/DFHack/dfhack/issues/1671

psychowico commented on 2020-10-28 21:51 (UTC)

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 ;)

psychowico commented on 2020-10-28 12:03 (UTC)

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.

Ziusudra commented on 2020-10-28 11:52 (UTC)

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.

psychowico commented on 2020-10-28 11:23 (UTC)

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

Ziusudra commented on 2020-10-28 10:46 (UTC)

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

psychowico commented on 2020-10-28 09:35 (UTC)

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}"

Ziusudra commented on 2020-10-28 09:19 (UTC)

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"

psychowico commented on 2020-10-28 08:05 (UTC)

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?

psychowico commented on 2020-10-28 08:04 (UTC)

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?

Ziusudra commented on 2020-10-18 21:24 (UTC) (edited on 2020-10-18 21:28 (UTC) by Ziusudra)

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.

psychowico commented on 2020-10-18 12:42 (UTC)

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.

psychowico commented on 2020-10-18 09:56 (UTC)

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.

Ziusudra commented on 2020-10-17 21:48 (UTC) (edited on 2020-10-17 21:56 (UTC) by Ziusudra)

@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.

psychowico commented on 2020-10-16 06:58 (UTC)

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)

Ziusudra commented on 2020-10-13 03:57 (UTC)

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.

thuban commented on 2020-09-21 04:16 (UTC)

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.

seylerius commented on 2020-03-10 07:06 (UTC)

The DFHack devs have not finished the updates yet. AUR updates are obviously delayed until the DFHack team has finished their work, which is proceeding with daily commits to the repository. I think getting this package updated within about a day of the 47.03 DFHack release is pretty impressive of our AUR maintainers already.

TL;DR: You're asking the wrong people, and the right people are already working diligently. Be patient.

waseem commented on 2020-03-09 20:26 (UTC)

Can this please be update for dwarffortress 47.04?

c4v4 commented on 2019-07-14 17:10 (UTC)

after installing this package some strange things happened to my system: if i try to play left 4 dead 2 it freezes the entire system after some short time. also some youtube videos started to be "not secure" according to firefox. (using manjaro)

albron commented on 2018-06-30 09:55 (UTC) (edited on 2018-07-04 05:28 (UTC) by albron)

Regarding out of date: at the time of writing, there is a bug in the arch dwarffortress package; there are problems with the bundled libgraphics.so . I compiled successfully dfhack 0.44.11-alpha1 but it's no use at the moment. I'll update the repo as soon as the bug is resolved.

See http://www.bay12games.com/dwarves/mantisbt/view.php?id=10799 and https://bugs.archlinux.org/task/59149

EDIT: now resolved, apparently.

wookietreiber commented on 2018-01-01 12:55 (UTC)

@albron: Thanks for wanting to get involved.

I've just created a repository at GitHub I would like to use for discussion about the build, so we can keep the comments here at AUR free of this and focused on other things.

https://github.com/wookietreiber/aur-dfhack

Take a look at the commit history to see what usually needs to be changed. When there is a new version, feel free to make a pull request, which I will then review / merge.

albron commented on 2017-12-31 11:14 (UTC)

Hi wookietreiber. I would like to help maintaining dfhack, but I need some hand-holding at the beginning since it's my first experience with AUR. Let me know if you're interested.

wookietreiber commented on 2017-12-17 19:11 (UTC)

If anyone wants to co-maintain, let me know.

marsoft commented on 2017-12-17 19:06 (UTC)

[ 16%] Built target dfhack-tinythread Scanning dependencies of target generate_headers [ 16%] Generating ../../library/include/df/codegen.out.xml Can't locate XML/LibXSLT.pm in @INC (you may need to install the XML::LibXSLT module) (@INC contains: xml /usr/lib/perl5/5.26/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.26/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.26/core_perl /usr/share/perl5/core_perl) at xml/codegen.pl line 15. BEGIN failed--compilation aborted at xml/codegen.pl line 15. make[2]: [library/CMakeFiles/generate_headers.dir/build.make:121: ../library/include/df/codegen.out.xml] Error 2 make[1]: [CMakeFiles/Makefile2:729: library/CMakeFiles/generate_headers.dir/all] Ошибка 2 make[1]: *** Ожидание завершения заданий…

marsoft commented on 2017-12-17 19:04 (UTC)

Should depend on perl-xml-xslt, at least for v0.44.02-alpha1

Moxon commented on 2017-10-23 10:48 (UTC) (edited on 2017-10-23 11:30 (UTC) by Moxon)

Hi, some proposed changes: * upstream URL should probably be the github page https://github.com/DFHack/dfhack * On July 13th, the last version (r2) has been released, current PKGINFO refers to beta1

Moxon commented on 2016-12-17 00:05 (UTC) (edited on 2016-12-18 19:30 (UTC) by Moxon)

Darn, I am getting: ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. when I start dfhack. I do have community/dwarffortress 0.43.05-4 installed as well. Any ideas? It works when I download the binary distribution from https://github.com/DFHack/dfhack/releases and unpack it into my .dwarffortress folder.

mkaito commented on 2016-08-23 14:40 (UTC)

If you find yourself unable to run dwarffortress 42.03 due to a missing library libGLEW 1.13, you can work around that by: sudo ln -s /usr/lib32/libGLEW.so.2.0.0 /usr/lib32/libGLEW.so.1.13 Just remember to remove that once you upgrade to a newer version of DF that can use GLEW 2.0

wookietreiber commented on 2016-07-02 11:46 (UTC)

Done. I made it so it depends on the exact same version number as dwarffortress. You have to install one from the Arch Linux Archives, because there is no dfhack yet for the most recent version of dwarffortress.

mkaito commented on 2016-07-02 01:50 (UTC)

As I've been busy with work lately, and will continue to be busy for the foreseeable future, I'm in fact okay with passing the package along. I'll orphan it right away. Please take care of it :)

wookietreiber commented on 2016-06-30 23:20 (UTC)

I took it upon myself to create a dfhack-bin AUR package: https://aur.archlinux.org/packages/dfhack-bin/ I also already started on creating a true source code based, compiled dfhack package. If you would orphan this package, I gladly would take over.

seylerius commented on 2016-05-03 06:39 (UTC)

Actually, that becomes an interesting question. Is there a valid purpose to having a package based on the source tarball, separate from a git package? If so, that would likely be the straight-up `dfhack`, while this would be `dfhack-bin` and the rolling git package would be `dfhack-git`. That tarball package is what I was referring to when I mentioned creating a `dfhack` source package.

mkaito commented on 2016-05-01 01:58 (UTC)

Actually, the source package should be dfhack-git, as per AUR naming conventions. If you're going to migrate to -bin, just delete this package. Poke me when you want to take over, Sey!

seylerius commented on 2016-04-30 21:16 (UTC)

Okay, finally got the laptop mostly straight. I think I'll be ready to take back over starting next weekend. You've been a serious help, mkaito. I agree with wookietreiber regarding renaming it dfhack-bin. Towards that end, I'll upload a new dfhack-bin AUR package that provides and conflicts dfhack. This should perhaps be reuploaded as a source package sometime shortly after. What do y'all think about using dependencies to migrate everyone over to dfhack-bin, then turning this into a source package in a month or so?

wookietreiber commented on 2016-04-25 10:23 (UTC)

this package should be named dfhack-bin

seylerius commented on 2016-04-10 22:48 (UTC)

Thanks, mkaito. I'm just getting my laptop straightened out, so it'll be a little bit longer before I'm on top of things again. I appreciate the help.

mkaito commented on 2016-04-05 12:08 (UTC)

0.42.06-alpha2 is a pre-release. I'll continue tracking stable releases with this package. I haven't gotten around to looking into resurrecting dfhack-git yet.

mkaito commented on 2016-03-01 16:07 (UTC)

Hey, I've picked up the package for the time being. If seylerius wants it back, I'll disown it ASAP. In the meantime, I'll update the package to 40.24_r5 until the newer versions get out of alpha.

seylerius commented on 2016-01-31 22:54 (UTC)

Two updates, folks: 1. DFHack is still on an alpha release at the moment. If y'all want me packaging alpha versions, speak up, but I'm of a beta-or-better mindset for this. DFHack-git follows their development faster. 2. My laptop (where I do development and packaging) is out of commission until after Friday, because I need to get paid (on Friday) and order a part. Nothing is happening until that's fixed. I'll be happy to package an alpha version if y'all want one at that point.

seylerius commented on 2015-12-18 03:47 (UTC)

Nope. The DFHack team is working to update the mapping of DF's memory structures to the new version, and I'll update our distribution of DFHack as soon as they release a compatible version.

rudregues commented on 2015-12-18 00:59 (UTC)

Is there a way to edit this package to target the new version of dwarf fortress? (version 0.42.03)

pheerai commented on 2015-11-01 16:18 (UTC)

Currently, this doesn't build on x86-46: It seems as if lib32-libjpeg6 has been removed during the aur4-update, maybe lib32-libjpeg6-turbo works. Additionaly, please consider using 'depends_x86_64' and 'depends_i686' instead of dpends and then checking for $CARCH, this will also repair the dependency-listing on the AUR-Page

emhs commented on 2015-03-25 04:41 (UTC)

Yeah, I think we need a master tileset tool, and individual tilesets would depend on it. The tileset tool would then set the tileset config in the user directory. Some variant of union directories might be helpful, since most of the ~/.dwarffortress (and most importantly for our purposes the folder where the tileset lives) is symlinked from /opt/dwarffortress.

ewtoombs commented on 2015-03-25 01:40 (UTC)

Man, that's brutal. Archers everywhere should make an effort toward some kind of tileset swapping convention so the mayday tileset or any other tileset can be downloaded as a separate package.

emhs commented on 2015-01-11 23:39 (UTC)

Not directly. It requires adding files to the DF installation directory, and so is customized for the default DF location. A hypothetical aur/dfhack-mayday would install DFHack to the location where dwarffortress-mayday is installed. And, if the mayday package is also using a form of the arch dwarffortress script, you'd need to update the dwarffortress-hacked script and dfhack-run script included here to use that location as well.

ewtoombs commented on 2015-01-11 23:36 (UTC)

Is this compatible with the mayday version?

emhs commented on 2014-12-27 20:46 (UTC)

Thanks, Ketsuban. Finally got around to this.

Ketsuban commented on 2014-12-08 06:05 (UTC)

I have constructed a PKGBUILD for the new 0.40.19 release. https://bpaste.net/show/1b184bd77dc2

emhs commented on 2014-12-02 22:46 (UTC)

Still waiting on DFHack 0.40.18. Anyone stuck in between should use the ARM link.

emhs commented on 2014-11-13 20:24 (UTC)

More helpful link: http://seblu.net/a/arm/packages/d/dwarffortress/

emhs commented on 2014-11-13 20:23 (UTC)

Arch Rollback Machine has dwarffortress=0.40.15. http://seblu.net/a/arm/2014/11/12/multilib/os/x86_64/ and http://seblu.net/a/arm/2014/11/12/community/os/i686/

emhs commented on 2014-09-24 12:57 (UTC)

Changed the executables to use install -Dm755. The rest involves _far_ too many nested directories for me to bother with. If you submit a PKGBUILD, or at least a diff, I'll think about doing more. Also, 0.40.13-r1.

kagebe commented on 2014-09-23 21:23 (UTC)

Could you please replace 'cp' by appropriate 'install -m XYZ' invocations? cp might have unintended consequences with permissions (e.g. if the user has a umask set). Look at https://aur.archlinux.org/packages/df/dfhack-git for an example. In addition 0.40.13-r1 has been released: http://www.bay12forums.com/smf/index.php?topic=139553.0

emhs commented on 2014-09-17 06:49 (UTC)

Another version bump: I've properly integrated dfhack-run now.

emhs commented on 2014-09-17 06:21 (UTC)

Back up to date. Release bump was because I forgot to appropriately bump the DF version in the first upload.

wengole commented on 2014-09-16 15:31 (UTC)

dwarfortress in multilib is now at 0.40.12

stradian commented on 2014-07-01 00:22 (UTC)

Pkgbuild needs updating, as dfhack is now at r5.

dpflug commented on 2014-06-19 23:45 (UTC)

This doesn't work with the community dwarffortress package because libgraphics.so is stripped. I've emailed the maintainer to see if he wants to do anything with it.

unknown commented on 2013-07-03 18:57 (UTC)

disowned due to lack of interest in dwarffortress.

Flaeme commented on 2013-04-15 20:12 (UTC)

As mentioned, the download location has changed, the version is outdated, and as far as I can tell, there are a few missing dependencies for stomesense; using ldd, with the LD_LIBRARY_PATH dfhack uses, on the stonesense.plugin.so, I was able to find my missing libs - namely lib32-libpng12 and a symlink from /usr/lib32/libjpeg.so.62 to /usr/lib32/libjpeg.so (as lib32-jpeg-turbo has different version numbers, but seems to be compatible - YMMV). lib32-allegro and the mentioned edit to dfhack might work, but I did not try it. Either way, this is definitely out of date.

crazedpsyc commented on 2013-03-20 15:09 (UTC)

New releases have been moved, since github's download feature was deprecated. They are now http://dethware.org/dfhack/download/dfhack-${pkgver}-r${pkgrel}-Linux.tar.gz $pkgrel is up to 3 now, too.

commented on 2013-02-02 12:38 (UTC)

To get stonesense to work install allegro and lib32-allegro, then change the dfhack script to set the ld lookup dir to this, and make sure /opt/df_linux is owned by root:games export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"./hack

cheesinglee commented on 2012-07-07 15:29 (UTC)

New PKGBUILD for 0.34.11-r1. Replaced dwarffortress-mayday dependency with plain dwarffortress. http://pastebin.com/d4fM3zjr