Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TC01]

Hi Bay 12,

I've lurked around these forums for years, and have been playing Dwarf Fortress for years also (since the days of 0.31.25), but have never really gotten around to posting much of anything here. Hi!

Anyway, in addition to being a Dwarf Fortress player, I'm also a packager for (and user of) the Fedora Linux distribution. I learned, a few months ago, that Dwarf Fortress is actually packaged in Arch Linux, and said to myself "why not Fedora?" So I started working on making a Fedora package of DF, using the Arch one as a guide. I don't know how many Fedora users there actually are in the DF community, but I figured posting about it here wouldn't be the worst idea.

I'll also slowly start packaging some of the more common utilities and things: I've already packaged dwarftherapist and looked into dfhack.

I'd like to, ideally, get dwarffortress (and friends) into rpmfusion, the officially unofficial collection of software that Fedora itself can't or won't ship. However, rpmfusion has (for about a year now) been in the middle of infrastructure upgrades. Adding new packages doesn't seem to be something that's really possible at the moment, and may not be for a while yet. So instead I've thrown together a small repository of my own for dwarffortress (and related utilities). If you run Fedora (22, 23, or 24) and want to use it, do the following:

Code: [Select]

$ sudo wget -P /etc/yum.repos.d/ https://mars.arosser.com/fedora/dwarffortress/dwarffortress.repo
$ sudo dnf install dwarffortress
$ dwarffortress

If you want some other utility packaged that runs on Linux, let me know! I'll be happy to take a look at packaging it for Fedora. And of course, let me know if you run into problems or anything like that.

EDIT: Dwarf Fortress is now in RPM Fusion! dfhack will hopefully be there soon.

[TC01]

Figured I'd update this thread. I created a web page documenting this repository; packages of dfhack, dwarftherapist, and legendsbrowser are now offered in addition to DF itself.

If anyone is actually using this at the moment, I wasn't able to make the x86_64 version of dwarffortress 0.43.05 update the i686 version of 0.43.04; you'll need to remove DF and then reinstall it in order to switch to the 64-bit version.

[Taffer]

For what it's worth, I'm using this. Thank you: your work is appreciated. It's a much cleaner installation than what I used to have.

It does seem to ignore my init.txt file, as I can't set a new default window size or turn graphics on. Sound also doesn't seem to work for me: I usually have sound turned off anyways, but thought it worth mentioning. It definitely seems to be loading d_init.txt and my custom interface.txt. It isn't spitting out any errors on the command line either.

Keep up the good work!

[TC01]

For what it's worth, I'm using this. Thank you: your work is appreciated. It's a much cleaner installation than what I used to have.

Thanks! I feel validated to know that at least one person other than me is using this.

It does seem to ignore my init.txt file, as I can't set a new default window size or turn graphics on. Sound also doesn't seem to work for me: I usually have sound turned off anyways, but thought it worth mentioning. It definitely seems to be loading d_init.txt and my custom interface.txt. It isn't spitting out any errors on the command line either.

Interesting... which Fedora are you running, on what sort of machine?

I just tested the 64-bit 0.43.05 on my Fedora 24 laptop and confirmed that I could switch sound back on using init.txt. It's possible that, as far as sound is concerned, there is a missing dependency that RPM is not automatically picking up that I happen to already have installed... Not sure why init.txt wouldn't be read though, but I will investigate further (and give this a try on other Fedora installations).

Sorry to ask a probably stupid question, but you're editing ~/.dwarffortress/data/init/init.txt? There's nowhere else it is meant to be read from?

[Taffer]

Sorry to ask a probably stupid question, but you're editing ~/.dwarffortress/data/init/init.txt? There's nowhere else it is meant to be read from?

I was editing /usr/share/dwarffortress/data/init/init.txt, as I was unaware it copied (or symlinked) everything to $HOME. I've got it sorted now, thanks!

[Miuramir]

Figured I'd update this thread. I created a web page documenting this repository; packages of dfhack, dwarftherapist, and legendsbrowser are now offered in addition to DF itself.

If anyone is actually using this at the moment, I wasn't able to make the x86_64 version of dwarffortress 0.43.05 update the i686 version of 0.43.04; you'll need to remove DF and then reinstall it in order to switch to the 64-bit version.

First off, this is a great effort and contribution to the community.  What are the odds that you could also readily package for RHEL and its derivatives (CentOS and Scientific Linux, mostly)? 

[TC01]

Sorry to ask a probably stupid question, but you're editing ~/.dwarffortress/data/init/init.txt? There's nowhere else it is meant to be read from?

I was editing /usr/share/dwarffortress/data/init/init.txt, as I was unaware it copied (or symlinked) everything to $HOME. I've got it sorted now, thanks!

Great! Yeah, the copy in /usr is installed by the package, and is only copied into your home directory once so as to not overwrite any local configuration.

Figured I'd update this thread. I created a web page documenting this repository; packages of dfhack, dwarftherapist, and legendsbrowser are now offered in addition to DF itself.

If anyone is actually using this at the moment, I wasn't able to make the x86_64 version of dwarffortress 0.43.05 update the i686 version of 0.43.04; you'll need to remove DF and then reinstall it in order to switch to the 64-bit version.

First off, this is a great effort and contribution to the community.  What are the odds that you could also readily package for RHEL and its derivatives (CentOS and Scientific Linux, mostly)?

Thanks!

Assuming all, or at least most, dependencies are available, I should be able to build for Extra Packages for Enterprise Linux, which should cover at least RHEL and CentOS. I'm not sure if EPEL is a thing on Scientific Linux as well, but that article implies it can be.

It'd be easiest to just support EL7, though... would you like packages for EL6 too?

[Miuramir]

Assuming all, or at least most, dependencies are available, I should be able to build for Extra Packages for Enterprise Linux, which should cover at least RHEL and CentOS. I'm not sure if EPEL is a thing on Scientific Linux as well, but that article implies it can be.

It'd be easiest to just support EL7, though... would you like packages for EL6 too?

EPEL would be perfect; it's highly respected, and just about everyone I know pulls from it already for one thing or another. 

Anecdotally, we've got a lot of systems still on 6.x around here, and I suspect that's generally the case.  7.x works pretty good on newer hardware, but takes a lot of getting used to; and 6.x is in full support until Q2 2017, and maintenance until late 2020, so there's not a lot of incentive to rush to upgrade existing working systems.  (Somewhat off-topic, but my experience is that for older, BIOS-based (pre-UEFI) systems you're better off with 6.x; for late-model UEFI-only systems you may require 7.x to even boot; and for the mixed-BIOS/UEFI systems from the last few years it depends on other factors.)

That said... packages just for 7 would be awesome.  Packages for 6 as well would be even more awesome, though

[TC01]

EPEL would be perfect; it's highly respected, and just about everyone I know pulls from it already for one thing or another. 

Anecdotally, we've got a lot of systems still on 6.x around here, and I suspect that's generally the case.  7.x works pretty good on newer hardware, but takes a lot of getting used to; and 6.x is in full support until Q2 2017, and maintenance until late 2020, so there's not a lot of incentive to rush to upgrade existing working systems.  (Somewhat off-topic, but my experience is that for older, BIOS-based (pre-UEFI) systems you're better off with 6.x; for late-model UEFI-only systems you may require 7.x to even boot; and for the mixed-BIOS/UEFI systems from the last few years it depends on other factors.)

That said... packages just for 7 would be awesome.  Packages for 6 as well would be even more awesome, though

I've built dwarffortress (nothing else yet) for EPEL7: you can enable it using this repo file, e.g. by running:

Code: [Select]

$ sudo wget -P /etc/yum.repos.d https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/dwarffortress-epel.repo

I don't actually have any CentOS systems around to test this on (although maybe I should set up a VM), so please let me know if there are any issues!

Building for EL6 looks to be a bit dicier because of the lack of C++11 in EPEL; do you happen to know offhand if there's a place people normally pull a newer GCC from in order to get C++11 support on EL6?

EDIT: Also built dwarftherapist, though it seems the PDF manual can't be built on EPEL7 due to a missing tex package, and updated it with the 0.43.02 and 0.43.03 memory layouts from github on both EPEL and Fedora. legendsbrowser is missing at least one Java dependency, unfortunately.

[TC01]

Legends Browser was accepted into Fedora! The package in Fedora should automatically update the one from this repo (and I will, obviously, stop publishing updates to this repo to avoid version conflicts).

When I have a chance, I'll see if I can get the necessary missing Java deps brought into EPEL7 so I can build for it, too.

[Miuramir]

Building for EL6 looks to be a bit dicier because of the lack of C++11 in EPEL; do you happen to know offhand if there's a place people normally pull a newer GCC from in order to get C++11 support on EL6?

It looks like GCC 4.8.1 (May 2013) is the first version to have what they consider feature-complete C++11 support.  GCC 5 is where full C++14 support comes in, for future reference (ie, Toady updates his compiler again). 

SL 6.x is based around GCC 4.4 by default; you need some separate arrangement to get up to 4.8.1.  SL 7.x is based around GCC 4.8; so it should work more or less "out of the box". 

I'm currently looking at SL or CentOS 6 plus the "Developer Toolset", at least version 2.0; this seems to be the "standard" way to get C++11 support on a 6.x version.  Developer Toolset 2 is at least GCC 4.8; Developer Toolset 3 is at least GCC 4.9; Developer Toolset 4 is at least GCC 5.3. 

It looks moderately likely that Developer Toolset 3 should work with 6.x, and a higher likelihood that DT 2 will work.  I'll try and get some test VMs set up to play with it at some point. 

[Taffer]

Just a small note to any users of this package: if the icon isn't cutting it for you, you can always use this icon, which should already be included on a default Fedora installation. It fits into the OS better. Copy it over /usr/share/pixmaps/dwarffortress.png, then log out and in again.

Pointless bikeshedding, but I haven't had any issues with the package so I haven't anything to complain about.

[TC01]

I've updated the dfhack plugin in this repository to include a 'dfhack-devel' subpackage. The -devel subpackage contains all of dfhack's include files, the include files for some of the bundled dependencies (currently just protobuf and lua), and a pkg-config file for dfhack. This means I can now package plugins that aren't in the main dfhack tree, and compile them outside of that tree.

With this, I was able to create a (work-in-progress) dfhack-plugin-twbt package and build it for Fedora 24. I can now add other out-of-tree dfhack plugins that people would like to see made available too.

Of course, this isn't hugely useful now because dfhack is still not compatible with the 64-bit 0.43.05 that I'm shipping, but in the future, hopefully it will be.

[TC01]

I've updated dfhack to the alpha of 0.43.05 with support for 64-bit Dwarf Fortress! If you happen to have the 32-bit dfhack package installed,you'll need to remove it and reinstall it to get the right architecture, and then remove all links to dfhack, hack, stonesense, etc. from ~/.dwarffortress/ (as the location of the 64-bit dfhack directory is now /usr/lib64/dfhack instead of /usr/lib/dfhack, so the symlinks are broken).

Fedora 25 is due to release next week (on Tuesday, 11/22). DF, DT, and DH have all now been built for F25, all for both architectures.

Time permitting I'm still slowly working on improving the dfhack package so that out-of-tree plugins can be built alongside it. I'm also investigating packaging rubble to support easy mod installation, although that will probably mean I'll need to modify the current launcher scripts to be capable of creating multiple installations of dwarffortress too... (as installing mods on top of the auto-updating ~/.dwarffortress/ directory is probably a bad idea).

And I do still need to see if I can't get more things building on EPEL-- now that dfhack supports 64-bit Dwarf Fortress it might be worth investigating that too.

EDIT: dfhack has now been built for EPEL7!

[jecowa]

You don't have Dwarf Therapist working with 64-bit Dwarf Fortress, do you? Or are you including 32-bit Dwarf Fortress alongside the 64-bit version?