Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

haskellPackages.{SC,sc}alendar: nullify to fix ofborg eval #33077

Merged
merged 1 commit into from Dec 26, 2017
Merged

haskellPackages.{SC,sc}alendar: nullify to fix ofborg eval #33077

merged 1 commit into from Dec 26, 2017

Conversation

pbogdan
Copy link
Member

@pbogdan pbogdan commented Dec 26, 2017

Motivation for this change

https://gist.github.com/790966e1b3ca91a6dfffd5a7c77912ba

ofborg eval is failing due to an infinite loop formed by these packages. I don't immediately see other way to break the cycle other than just nulling these out.

/cc @peti

Things done

Evaluated haskellPackages with allowBroken set to true.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@pbogdan pbogdan requested a review from peti as a code owner December 26, 2017 17:11
@grahamc
Copy link
Member

grahamc commented Dec 26, 2017

The checks fail because of https://github.com/grahamc/ofborg/issues/25, but doing a review locally with:

$ cp ~/projects/ofborg/ofborg/src/outpaths.nix .; nix-env --file ./outpaths.nix --query --available --json  --arg checkMeta true --show-trace > /dev/null ; echo $?
0

indicates this fixes the eval issue.

@grahamc grahamc merged commit 93829f1 into NixOS:master Dec 26, 2017
@pbogdan
Copy link
Member Author

pbogdan commented Dec 26, 2017

Hmm, a more elegant fix (rather than the null hammer) may consist of:

  scalendar = markBroken (super.scalendar.override { SCalendar = null; });
  SCalendar = markBroken (super.SCalendar.override { scalendar = null; });

(which I initially tried but failed to make it work somehow... sorry :-(). Happy to submit another PR if there is a strong preference for this approach.

@orivej
Copy link
Contributor

orivej commented Dec 26, 2017

Thanks! This is a permanent fix, unlike 6e2df0a

@peti
Copy link
Member

peti commented Dec 26, 2017

Hey, not so fast! I am 👎 on this change. markBroken is the way we've dealt with issues like this one for 3+ years, and I don't see why that should suddenly be illegal. As far as I am concerned, the source of the problem is the fact that the bot evaluates explicitly broken packages!

Neither 6e2df0a nor this change should have made it into the package set!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants