search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.71k stars 13.84k forks source link

Haskell: to-do list of potentially out-dated overrides #86500

Closed peti closed 2 years ago

peti commented 4 years ago

The krank utility found the following references to closed Github issues in our Haskell override files. The fact that those bugs are closed upstream is an indication that we can probably remove the override, but that needs to be checked because upstream closes issues for all kinds of reasons, not all of them meaning that the issue was actually fixed. Furthermore, there appear to be some URLs to bugs that don't exist anymore (see end of this list).

Please, everyone, help fix these issues by checking some entries of that TODO list and, if applicable, create a pull-request to submit the fix. Then also please check the TODO entry here so that it won't be checked again by someone else.

Please submit your changes against the haskell-updates branch, not master. If you feel like it, please ping @peti and @nh2.

peti commented 4 years ago

Overrides with closed issues attached

peti commented 4 years ago

Overrides with Invalid URLs

cdepillabout commented 4 years ago

nixpkgs/pkgs/development/haskell-modules/configuration-nix.nix Line 685 in 4b942e8 https://github.com/spacchetti/spago/issues/510

I'm not sure exactly what to do about this.

The upstream issue was closed because it is meant to work the way they have it working, so it is something we have to workaround in nixpkgs. I think it is nice to have the issue linked there to give some context why we have to do this hacky thing.

Although if you'd like to remove the issue link, I'd be fine with that as well. What we are doing should be explained in our code as well.

I checked this off, given that I think we should keep in the link, but if you want to keep it unchecked, please feel free to uncheck this.

nh2 commented 4 years ago

@cdepillabout I think that is fine. The point of this effort is to find things that need to be done; this linked issue is only informational and nothing needs to be done, so checking it off is right.

In the future we probably want to use some textual marker to exclude this type of link from krank.

Anton-Latukha commented 4 years ago

In that PR there is haddock-library{._1_9_0} here is haddock mentioned.

Other packages from that PR seem not be mentioned here.

Anton-Latukha commented 4 years ago
Anton-Latukha commented 4 years ago

The lot of linked reports and PRs are closed/merged, but Nixpkgs awaits on project release a package on Hackage.

So since those reports/PRs are solved:

  1. they should be deleted, so krank does not false-positive on them
  2. they should be deleted/replaced to not misled contributors to re-re-re-check them.
  3. they should be replaced with relevant info.

So I adopted the message:

# 2020-06-22: NOTE: > 0.4.0 => rm Jailbreak

So the regex and the check against the version is needed.

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

nh2 commented 3 years ago

Probably still relevant given the many recent PRs.

svmhdvn commented 3 years ago

I'm happy to continue gradually working on this, I will be getting a little more time to put into this soon.

Jake-Gillberg commented 3 years ago

It looks like idris 1.3.3 is broken and needs an older version of megaparsec.

The issue referenced above: https://github.com/idris-lang/Idris-dev/issues/4826 is closed as "won't fix".

This override was removed in https://github.com/NixOS/nixpkgs/commit/4b2b6ce65e3894391ee6a42b40fe5b6016f1592f. I believe this broke the package.

Idris is failing to build with the message:

  Setup: Encountered missing or private dependencies:
  aeson >=0.6 && <1.5, haskeline ==0.7.*, megaparsec >=7.0.4 && <9

I tried fixing this package (https://github.com/Jake-Gillberg/nixpkgs/commit/5c63f2499e45bd6e8a0a8186edf6e699b5200484) by re-adding the relevant overrides, but it looks like specified megaparsec versions are not found.

I'd be happy to test and submit a working pull request if I could get some guidance on how to meet the listed megaparsec version.

Anton-Latukha commented 3 years ago

BTW. Stackage currently removed the upper bound on the hnix-store-core that is still unmaintained there. We by the team voted for removal, so it would happen eventually, https://github.com/commercialhaskell/stackage/issues/5872. I do not know their schedules & all procedure of how Nixpkgs inherits with LTS & Nightly presence. But boundary removal means that hnix-store-core hardcode version derivation overrides soon would be out-dated or changed, which this thread is about.

Anton-Latukha commented 3 years ago

https://github.com/NixOS/nixpkgs/issues/86500#issuecomment-749097309

I'm happy to continue gradually working on this, I will be getting a little more time to put into this soon.

You did great work, thank you.

cdepillabout commented 3 years ago

@Jake-Gillberg You can generate megaparsec_8_0_0 by adding a line to the following list:

https://github.com/NixOS/nixpkgs/blob/4dfe07dadac24ae00881b6ab808d8f3627340511/pkgs/development/haskell-modules/configuration-hackage2nix.yaml#L2705-L2726

If you send a PR to the haskell-updates branch adding this line and it is merged in, then the next time the re-generation script runs, it will create a megaparsec_8_0_0 derivation for you.

Please feel free to open up an issue or PR to further discuss this.

Anton-Latukha commented 3 years ago

Stackage: hnix-store-core, which is in Nightly & LTS:

juhp in https://github.com/commercialhaskell/stackage/issues/5872#issuecomment-783303809

I have blocked the package now. If you need action for LTS please open a separate issue for that as mentioned.

So the situation is changed for the package and for the hnix stack. Over time it would go through the proper process of a graceful removal, and hnix infrastructure would scale back to Hackage. So all of our "guilty as charged" overrides would be cleaned over the nearest time.

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

cdepillabout commented 2 years ago

@maralorn @sterfield @expipiplus1 Since none of us is really maintaining this list or this issue, how about just closing it out?

In theory I think something like this issue is a neat idea, but I don't think it makes sense to keep this issue open without anyone actually going through and keeping it up to date.

maralorn commented 2 years ago

I think we should in general strive for more hygiene like that, but it’s not very high priority and I guess we should run krank new and open a new issue anyways.

maralorn commented 2 years ago

Sorry for the noise @sterfield, we meant @sternenseemann.