If you output HTML with MathJax content Pandoc might uses a JS library
provided by cdn.polyfill.io which is now considered to be a bad actor.
https://sansec.io/research/polyfill-supply-chain-attack
Pandoc does not use this domain in recent versions but upgrading it
seems more complex right now especially if we consider backports to
the stable releases.
(cherry picked from commit 08c21134cd)
It is somewhat curious that it behaves differently exclusively here, but
I don't think it is necessary to stop shipping a package due to floating
point arithmetic error—it would be unreasonable to assume there were
none…
See https://github.com/ekmett/ad/issues/113.
(cherry picked from commit d90232565e)
Those flags were not actually passed to GHC before, but to Setup.hs.
They were introduced in #86948. The related twitch live stream uses the
build of git-annex as a measurement. I get the following numbers when
building git-annex with doCheck = false:
- for current master: 1:40 wall clock / 340s user
- without any -A64M argument: 1:40 wall clock / 340s user
- with this fix: 1:13 wall clock / 280s user
The idea was good, but the settings were never active.
More testing revealed that this seems to work on darwin just as well, so
we're removing the isLinux condition, too.
(cherry picked from commit 32863001bb)
The following sequence of operations loses ghc-options:
Setup.hs configure --ghc-options
Setup.hs build --with-ghc=...
This is described in [1].
The fix is simple: Don't pass --with-ghc in the build phase. The values
are taken from the configure step anyway. This seems to have been
introduced all the way back in 64ec4dd87b
about 8 years ago for unknown reasons.
Resolves#286285
[1]: https://github.com/haskell/cabal/issues/10069
(cherry picked from commit 5dbf665089)
It is somewhat curious that it behaves differently exclusively here, but
I don't think it is necessary to stop shipping a package due to floating
point arithmetic error—it would be unreasonable to assume there were
none…
See https://github.com/ekmett/ad/issues/113.
(cherry picked from commit d90232565e)
After 120f24202b, GHC_PACKAGE_PATH isn't
set implicitly in installPhase anymore. Instead we achieve the same by
telling the Makefile the exact ghc command line to use.
As a benefit, we can now cleanly separate build and host in this case:
We used to (implicitly) reuse the host package db. Now we can explicitly
request the package db also used for building Setup.hs.
(cherry picked from commit 482ab92066)
Previously, we would set GHC_PACKAGE_PATH after configure, the reasons
being that
1. Setup.hs configure forbids this from being set since it can make a
build fail that would otherwise succeed (since it influences how
GHC behaves when invoked by Cabal).
2. Setting GHC_PACKAGE_PATH being set is sound in our case, since
we set it precisely to the packages available to Cabal at configure
time, so there should be no room for a mismatch.
3. Some test suites require GHC_PACKAGE_PATH or GHC_ENVIRONMENT to be
set, so they can invoke GHC(i) with build dependencies available.
Cabal >= 3.12 forbids GHC_PACKAGE_PATH from being set after
<https://github.com/haskell/cabal/commit/d6e38041a7c778fadf8f416>.
Setting GHC_ENVIRONMENT would be possible, but is cumbersome without
cabal-install (which has the handy cabal exec command which takes
care of that). Additionally, it is not clear if it'll remain possible
to do that: <https://github.com/haskell/cabal/issues/7792>.
Our solution to Cabal 3.12's change is to be more targeted about setting
GHC_PACKAGE_PATH: We _just_ set it for the actual test suite executable.
This can be achieved by using --test-wrapper which when given is invoked
by Cabal to run the test suite. Here we can set any environment
variables after Cabal has already done its environment checks. As long
as we don't do anything stupid, this should be unproblematic.
Users can also arbitrarily influence what GHC_PACKAGE_PATH will contain
using the NIX_GHC_PACKAGE_PATH_FOR_TEST environment variable. This is
un(der)documented for now, since I want to keep some wiggle room for
changing stuff in the coming weeks. Also it's rarely necessary to
actually touch this variable.
(cherry picked from commit 120f24202b)
Make sure all relevant info is in the user manual and avoid duplication
of efforts, or things going out of sync.
(cherry picked from commit ce81cf0ee1)
This change ensures that packages won't be rebuild compared to before
the introduction of disallowedRequisites/disallowGhcReference unless
they use one of those arguments.
It may be nice to revert this in the future (via staging) for greater
simplicity, but will help with initial regression testing.
(cherry picked from commit 0454f7b8ee)
This makes `justStaticExecutables` error if the produced store path
contains references to GHC. This is almost always erroneous and due to
the generated `Paths_*` module being imported. This helps prevent
`justStaticExecutables` from producing binaries with closure sizes in
the gigabytes.
See: https://github.com/NixOS/nixpkgs/issues/164630
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
(cherry picked from commit d2618822ab)
(minus release note)
I suspect that we'll be able to upgrade to 9.10.* for all three packages
after the next haskell-language-server update. I'll leave that to
maralorn.
(cherry picked from commit b30eb6f3db)
One of the tests is flaky and fails sometimes on darwin, linux builds
don't seem to be affected. This change removes the failing assert on
darwin.
(cherry picked from commit 42ade6365d)
Without the change the eval fails as:
$ nix build --no-link -f. haskell.packages.ghcjs.exceptions
error:
… in the left operand of the update (//) operator
at pkgs/development/haskell-modules/lib/compose.nix:40:7:
39| mkDerivation = drv: (args.mkDerivation drv).override f;
40| })) // {
| ^
41| overrideScope = scope: overrideCabal f (drv.overrideScope scope);
error: attribute 'exceptions_0_10_7' missing
at pkgs/development/haskell-modules/configuration-ghcjs.nix:30:26:
29| stm = doJailbreak self.stm_2_5_3_1;
30| exceptions = dontCheck self.exceptions_0_10_7;
| ^
31|
Did you mean exceptions_0_10_8?
(cherry picked from commit b1f5c64b80)
Without the change the eval fails as:
$ nix build --no-link -f. haskell.packages.ghc865Binary.exceptions
error: attribute 'exceptions_0_10_7' missing
at pkgs/development/haskell-modules/configuration-ghc-8.6.x.nix:98:16:
97| # This became a core library in ghc 8.10., so we don’t have an "exception" attribute anymore.
98| exceptions = self.exceptions_0_10_7;
| ^
99|
Did you mean exceptions_0_10_8?
(cherry picked from commit 8b65aca289)
