They aren't meant to be critical (uncatchable) errors.
Tested with nix-env + checkMeta:
[ "x86_64-linux" "i686-linux" "x86_64-darwin" "aarch64-linux" ]
dwarf-therapist: 37.0.0-Hello71 -> 39.0.0
dfhack: 0.43.05-r1 -> 0.44.02-alpha1
cla-theme: 43.05-v23 -> 44.01-v24
phoebus-theme: 43.05c -> 44.02a
There is a new maintained repository for
dwarf-therapist: http://www.bay12forums.com/smf/index.php?topic=168411
dfhack is still in alpha, so make backups, if you use it.
cc @the-kenny @abbradar
To use stonesense, build dwarf-fortress with `enableDFHack=true` and
`enableStoneSense=true`, then type `ssense` into the dfhack console.
This partially reverts commit 85056ee698
Searching the web for the base-16 encoded hash of the one we have in the
Nix expression didn't give any results and I also couldn't find the
older tarball anywhere (even the mirrors I've checked don't have it).
So checking the updated hash I've found that other distros use this, so
I'd bet it's safe to do this.
I've tested building the package but I didn't do any runtime test.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @the-kenny
I've bisected the introduction of the build failure to be the glibc 2.26
upgrade with commit 9bb67d5c1e.
At first I was somewhat stumped why an glibc update could cause
undeclared identifiers, but after looking at the changes of glibc and
the source code of The Ur-Quan Masters the problem quickly turned out to
be this very change:
https://sourceware.org/git/?p=glibc.git;a=commit;h=7b037c095e31c2396d0a9b0e6356bc566ee4812f
So string.h now in turn includes strings.h, which in theory wouldn't be
a problem.
However, both strings.h and the strings.h in the uqm source code use
constant _STRINGS_H, which causes the glibc strings.h to be included but
the one from uqm basically includes an empty file.
Signed-off-by: aszlig <aszlig@nix.build>
The only functional change here is that I've dropped unzip, because that
dependency doesn't seem to be necessary at all. Despite the broken build
state I've tried building and running The Ur-Quan Masters with an older
nixpkgs revision and it works fine.
Other than that there are no references in the source code for unzip
except in the binary installer and some of the INSTALL files.
The reason why I'm removing the "with pkgs.lib;" is that it makes it
easier to quickly check for errors with "nix-instantiate --parse".
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jcumming
