Why is this doJailbreak needed? Is this something you could get fixed upstream? (Even if it is just a hackage revision...)

CallStack (from HasCallStack):
  die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:1022:20 in Cabal-3.0.1.0:Distribution.Simple.Configure
  configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:475:12 in Cabal-3.0.1.0:Distribution.Simple.Configure
  configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:625:20 in Cabal-3.0.1.0:Distribution.Simple
  confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:65:5 in Cabal-3.0.1.0:Distribution.Simple.UserHooks
  configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:180:19 in Cabal-3.0.1.0:Distribution.Simple
  defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:116:27 in Cabal-3.0.1.0:Distribution.Simple
  defaultMain, called at Setup.hs:2:8 in main:Main
Setup: Encountered missing or private dependencies:
extra >=1.6.2 && <1.7

builder for '/nix/store/gn395r9sq2ik1v3vfyv96s9qhvf4mcyj-Unique-0.4.7.7.drv' failed with exit code 1

all i know is every time stupid stackage gets updated everything breaks

i think the real question is why do i keep having to add jailbreaks back after people remove them when i'll have to do it again in a few weeks ;_;

@Kiwi I'm sorry that you end up having to keep fixing this.

The nixpkgs haskell packages generally follow Stackage, which has major updates about every 3 to 6 months. For packages that are in stackage, nixpkgs generally has good support, and you don't end up having to fix things too often.

For packages not in Stackage, it needs a lot more work from the nixpkgs maintainers to make sure everything compiles together. You are much more likely to see packages failing that are not in stackage.

Also, users will sometimes go through and remove things like doJailbreak when they are no longer needed. My guess is that at some point Unique was compiling correctly without doJailbreak, so someone removed. Then possibly with a future update of Unique or stackage, version bounds were incorrect again, so it needs to be fixed again.

The easiest solution here is to get Unique (and possibly matterhorn) into Stackage.

If you don't want to do that, then possibly create issues upstream and urge the maintainers to make new releases that fix versioning problems. Many packages have versions that are too strict, and really require frequent updates from their maintainers. For maintainers that don't want to do this, they should use versions that are not as strict.

If upstream is not responsive, then we generally use doJailbreak here in nixpkgs, but it is the nixpkgs users responsibility to be vigilant when the package ends up breaking again.

thank you for the explanation. sorry if i came off a bit curt. can we merge this in the meantime and i'll try to talk to people about getting it fixed upstream? sometime

It's done. Please proceed.
@Kiwi Thanks for help again

awesome! which is good since it seems i screwed up the commits on this one anyway when i tried to update it last... @kapralVV sure thing! glad to help anytime if you need anything let me know

success!

04:05:37 [kiwi@mvp-nixos nixpkgs]$ nix-build --no-out-link -A haskellPackages.Unique --arg config '{ allowBroken = true; }'
/nix/store/i7gsk67a9a4942vjzizkdrs9mjj70ckk-Unique-0.4.7.8

so it builds now on

commit bb8c74439a0e9aca68fee4434b3c5565e2a2a46a (HEAD -> haskell-updates, origin/haskell-updates)
Author: Peter Simons <simons@cryp.to>
Date:   Tue Aug 11 02:30:28 2020 +0200

but is still marked broken. should I change this pr to only remove that it's broken? and fix the rebase...

@Kiwi Yes, if you change this PR to just remove that Unique is broken, I'll go ahead and merge this in.

i'm starting to get the hang of this rebase thing that only took me one try and a few minutes. i think it's fixed now

Can you please add that URL to the Nixpkgs source code in a comment before your override? That's more helpful than "matterhorn needs this". :-)