Print

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

[TC01]

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?

Unfortunately not, no.

You can use the packaged Therapist from the 64-bit repository with a 32-bit copy of Dwarf Fortress, but it's not currently possible to install the 32-bit DF package alongside the 64-bit one. Alternatively if you change the repository file to look like this:

Code: [Select]

[dwarffortress]
name=Dwarf Fortress for Fedora $releasever
#baseurl=https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/$releasever/$basearch/
baseurl=https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/$releasever/i686/
gpgkey=https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/df_gpg_key
enabled=1

You can install the 32-bit versions of everything instead.

In theory I suppose the 32-bit packages could be made to coexist with their 64-bit counterparts (by creating dwarffortress32, dfhack32, etc. packages for 64-bit Fedora). Would this be useful? I suppose even after Therapist is ported to work with 64-bit DF, it'd might occasionally be useful to be able to run the 32-bit version of DF instead.

[TC01]

After some delay, I've finally gotten around to updating dfhack to the latest 0.43.05-compatible release (alpha 4).

I've also been working on some hopefully reasonably sane way to install mods and tilesets on top of this installation. I just posted about stockpile over in the utilities forum, and have been working on packages of the Rubble modding suite to potentially go along with it.

The idea behind stockpile is to turn ~/.dwarffortress/ into a git repository, where you can create branches that are decoupled from the system install of DF on top of which mods (or tools that want to control your raw files, like Rubble) can be installed. Then, toggling between installations is as easy as changing the branch-- there's no need to modify the launcher script or anything else. It's not completely polished as of yet, but a working version of this is now available as a package from this repository, alongside a rubble package (and its Go dependencies, which I'm working to get into Fedora proper).

I should emphasize that none of this stuff would become necessary to use DF from this repository-- the main DF package will continue to function as it currently does. stockpile is just something that can be installed on top of it, should you be interested.

[legolegs]

Hey! www.acm.jhu.edu is not responding and therefore the repository is not available. If you need hosting I can give you access to my http://repos.legolegs.me/

I know that the game itself got into rpmfusion-nonfree but tools like dwarftherapist didn't.

[TC01]

Hey! www.acm.jhu.edu is not responding and therefore the repository is not available. If you need hosting I can give you access to my http://repos.legolegs.me/

I know that the game itself got into rpmfusion-nonfree but tools like dwarftherapist didn't.

Yes, unfortunately the cluster that was powering www.acm.jhu.edu is offline until further notice (it appears that the A/C in the room it was in failed! So it might be a while until it's restored...).

For the mean time, I have a mirror up at https://rubble.brosser.net/fedora/dwarffortress/. You should be able to change /etc/yum.repos.d/dwarffortress.repo appropriately and it should still work. I'll pursue a more permanent solution over the coming weeks.

And indeed, as you noted, dwarffortress itself is now in RPM Fusion's nonfree repo! I hope to get dfhack in there soon as well.

[legolegs]

Thank you!

[TC01]

Okay, I've moved the repository over to new hosting. You can grab the new dwarffortress.repo file here (there is also a dwarffortress-epel.repo in the same directory). I've also built dfhack for Fedora 27, which is likely going to release in a week or two. (I'd like to provide some mirrors, but I need to set something up to generate Fedora-esque mirrorlists, I think). I'll update the wiki accordingly.

Something that I need to figure out is how to handle save compatibility breaking updates, now that the packages are making their way into RPM Fusion. I don't think I should build them right away... as any dependent packages, like dfhack, will just break. Fedora update policy would likely suggest not building them at all for the latest stable release ("Fedora n"), and only providing them on Fedora n+1, but that seems too slow. So I think what I'll probably do is not build them for Fedora n until there's a corresponding dfhack update available.

Does this seem reasonable?

[legolegs]

I am not exactly sure, but AFAIR RPM works that way:

• if user has both df and dfhack installed and
• if dfhack has dependencies set as "Requires df=43" - not "greater or equal 43"
• and when new df comes out in the repo while new dfhack does not yet

then df does not gets upgraded. Also package manager may not remove dfhack unless told so.

[Miuramir]

Not a RPM expert, but given the way things like Python are usually handled (e.g. systems with both a python2 and a python3), and how infrequently we get major releases of DF, I think there's a good case to make each major DF release its own RPM.  Probably at the middle digits level; ie, DF 0.40.x is one install, 0.42 another, and so on.  So, folks could continue to have 0.43.05 installed, and have appropriate packages to match, where in a different clump we have the new 0.5x or whatever DFlate17early18 ends up being called.

At least on the RHEL / SL / CentOS side, there is a yum-plugin-versionlock that allows you to fix things the way they are currently; setting up stuff the way you want it, doing a version lock while you play the fort, and then unlocking it to update between forts would seem to be a workable, if not optimal, plan. 

I personally wouldn't want to delay a new version of DF just for DFhack, but I actually play on Windows more often these days and tend to stick fairly close to stock so I'm probably not a typical user of this. 

[Taffer]

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.

Looks like this happened, and you're now the official maintainer in rpmfusion. Thank you! I thought I'd report a bug with the package here:

The .desktop file should include StartupWMClass=Dwarf_Fortress, or else the game loses its icon after startup.

[TC01]

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.

Looks like this happened, and you're now the official maintainer in rpmfusion. Thank you! I thought I'd report a bug with the package here:

The .desktop file should include StartupWMClass=Dwarf_Fortress, or else the game loses its icon after startup.

Hey, sorry I missed this until now. (I've set notifications up to email me when there's a post in this thread-- something I should have done long ago.) I'm currently building 0.44.10 with the desktop file fixed.

Indeed; dwarffortress, dfhack, and dwarftherapist are now all in the nonfree RPM Fusion repository! I haven't had as much time for Fedora lately as I'd like, but I've been trying to keep the packages mostly up to date.

I would still like to come up with a better way to install mods and tilesets on the packaged versions without writing my own mod management system. It hasn't been a high priority for me because I don't actually play with tilesets (and to be honest, I haven't played much DF lately), but... it'd be nice to work something out.

[Miuramir]

Indeed; dwarffortress, dfhack, and dwarftherapist are now all in the nonfree RPM Fusion repository! I haven't had as much time for Fedora lately as I'd like, but I've been trying to keep the packages mostly up to date.

I would still like to come up with a better way to install mods and tilesets on the packaged versions without writing my own mod management system. It hasn't been a high priority for me because I don't actually play with tilesets (and to be honest, I haven't played much DF lately), but... it'd be nice to work something out.

Good going; I don't have as much chance to play DF on the Linux side as I'd like, but it's great to know that it's readily available.  Hmm.  Now wondering whether a minimal setup designed for a simple Docker install would be useful to enough people to make it worth doing. 

The "normal" tilesets are pretty small; you could probably reasonably package up everything on the DF wiki's Tileset repository into one rpm, like a collection of vim themes or the like would be handled.