You can do hardeningDisable = [ "format" ] or NIX_CFLAGS_COMPILE = "-Wno-error=format-security".

More generally, having unstable after the date seems inappropriate; unstable is more akin to a namespace than a part of the version string.

Thanks for the review. I'll try that autotools thing. First autotools nixpkg I've worked on. As for the name, that semantic comes straight from the manual: https://nixos.org/nixpkgs/manual/#sec-package-naming. I'm contributing bug fixes and stuff upstream as well, so hopefully we can get a stable version tagged that builds on nixos soon.

Note that the manual recommends adding -unstable to the package name, not the version.

My suggestion of simply disabling the error flag obviates the need for pointing to your own fork, if that's the only reason to not use upstream.

My commit was just merged, so I switched to their repo. It's using fetchFromGithub now as well. I still can't build off a stable release because both previous stable releases (3.1.0 and 3.1.0) fail to compile on gcc because of conflicting function definitions (already fixed in upstream).

One thing to consider is that if you intend to drop the unstable suffix once upstream makes a new release, somebody who installed the unstable package would not receive the update via ordinary package upgrade, because they'll be considered different packages. It's probably more appropriate to use the pre-release naming pattern here. I think the intent behind unstable really is for situations where you'd carry both a stable and an unstable variant over time.

I'm hoping an upstream release will be soon and I can use that.

@disassembler How about versioning it as "3.1.1.20181013" ?

@disassembler any motivation to continue this PR?

I actually wanted to try this program out anyways... so I updated the PR to be a more recent unstable version.