haskellPackages: mark some broken packages as not broken

[prsteele]

Description of changes

This PR marks the glpk-headers, math-programming, math-programming-glpk, and math-programming-tests packages as not broken.

Existing versions of these packages were indeed broken. I recently released version 0.5.0 of each of these, and they all build on the current release-22.11 branch of nixpkgs.

Note that this PR has not updated the versions of these packages in the hackage-packages.nix file; I suspect that this PR will need to be merged after this file is regenerated in the next few weeks and picks up the newly-released packages above.

Testing done

I created a small Haskell project that relies on the new packages, and nixpkgs branch release-22.11. The resulting project builds. I used the following as shell.nix,

{ sources ? import ./nix/sources.nix
, pkgsF ? import sources.nixpkgs
}:
let
  config = {
    packageOverrides = pkgs: rec {
      haskellPackages = pkgs.haskellPackages.override {
        overrides = self: super: rec {
          test-nixpkgs = self.callCabal2nix "test-nixpkgs" ./. {};
          math-programming = self.callPackage ./math-programming.nix {};
          math-programming-tests = self.callPackage ./math-programming-tests.nix {};
          math-programming-glpk = self.callPackage ./math-programming-glpk.nix {};
          glpk-headers = self.callPackage ./glpk-headers.nix {};
        };
      };
    };
  };

  pkgs = pkgsF { inherit config; };
in
pkgs.haskellPackages.shellFor {
  packages = p: [ pkgs.haskellPackages.test-nixpkgs
                ];
  buildInputs = [ pkgs.cabal-install
                  pkgs.cabal2nix
                  pkgs.haskell-language-server
                ];
  withHoogle = true;
}

where I generated the files glpk-headers.nix, math-programming.nix, math-programming-tests.nix, and math-programming-glpk.nix via

nix-shell --packages cabal2nix --run 'cabal2nix cabal://math-programming-0.5.0' > math-programming.nix
nix-shell --packages cabal2nix --run 'cabal2nix cabal://math-programming-glpk-0.5.0' > math-programming-glpk.nix
nix-shell --packages cabal2nix --run 'cabal2nix cabal://math-programming-tests-0.5.0' > math-programming-tests.nix
nix-shell --packages cabal2nix --run 'cabal2nix cabal://glpk-headers-0.5.0' > glpk-headers.nix

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[prsteele]

Sorry for the massive set of pings on the previous PR; I had started from master, and I swapped the target to haskell-updates late without realizing what that would imply for automation.

[prsteele]

I do have the question of "is this the right approach?" If the broken.yaml file is made from scratch each time the Hackage package set is regenerated, then I suspect this PR is unnecessary.

[maralorn]

This is the right approach. PRs like that are very welcome. Hydra does not create the file from scratch. It doesn’t build packages marked as broken at all. So it wouldn’t know which packages to remove. We only add packages to this list semi-manually when packages break and remove them in PRs like this, when someone notices that they work.

[hugosenari]

I suspect that this PR will need to be merged after this file is regenerated in the next few weeks and picks up the newly-released packages above.

Are we there yet? :-D
Should we change this to draft?

[cdepillabout]

@prsteele I just updated the hackage pin on haskell-updates and opened #213089.

I tried compiling glpk-headers, but I got an error about the required version for the hspec dependency. Could you take a look at that? (I didn't check the other packages you've unbroken in this PR)

[prsteele]

Looking into this. I'll note that I ran into (what seems like) a bug on the current haskell-updates branch. In configuration-common.nix, line 1376, we have

  hls-hlint-plugin = super.hls-hlint-plugin.override {
    # For "ghc-lib" flag see https://github.com/haskell/haskell-language-server/issues/3185#issuecomment-1250264515
    hlint = enableCabalFlag "ghc-lib" super.hlint;
    apply-refact = self.apply-refact_0_11_0_0;
  };

It seems like self.apply-refact_0_11_0_0 doesn't exist.

[prsteele]

Okay, I can reproduce the failure you observed. It looks like hspec got a new version, and glpk-headers depends on versions that aren't included any more.

I'll get a 0.5.1 version out for these packages that works with the current haskell-updates branch.

[prsteele]

@cdepillabout I've added 0.5.1 versions of each package to Hackage with relaxed bounds on hspec, and I'm able to build each of the packages against this commit. I manually patched hackage-packages.nix, and left that as a standalone commit unless it's better to just regenerate the whole file.

[cdepillabout]

@prsteele Thanks!

I updated the Hackage pin on haskell-updates and cherry-picked d1f0d4c as c4d4608. You can follow along on #213089.