For the past couple of years, there has continued to be problems with having the PureScript compiler on nixpkgs building from Haskell packages it is not built against in its actual development and release. We have seen this issue come up multiple times here on nixpkgs, but this also causes numerous issues to be filed against the PureScript compiler repository. One example of an exchange that has occurred multiple times in the past: https://github.com/NixOS/nixpkgs/issues/53597https://github.com/purescript/purescript/issues/3571. As noted, the PureScript compiler is not on Stackage because it is not meant to be used as a library, and it does not update itself to the latest LTS and cut releases to match LTS releases.
Instead, I have begun maintaining my own derivation for the PureScript compiler (among other tools) in a small project here: https://github.com/justinwoo/easy-purescript-nix. Within are other reference and derivations for other tools commonly used in the PureScript ecosystem, updated to their respective newest releases. These derivations use the same releases that other Linux and OSX users use, along with the standard application of patchELF to provide for runtime dependencies such as zlib, gmp, and ncurses5. These derivations are now used by a variety of NixOS, non-NixOS Linux, and OSX users.
This commit then consumes the easy-purescript-nix derivation for the PureScript compiler and provides it in all-packages for consumption.
I no longer use nor do I maintain this package upstream and with the
current version of pylast moving to Python 3, this package is hereby
obsolete as I'm not willing to port this to Python 3.
Signed-off-by: aszlig <aszlig@nix.build>
In Linux 4.19 there has been a major rework of the overlayfs
implementation and it now opens files in lowerdir with O_NOATIME, which
in turn caused issues in our VM tests because the process owner of QEMU
doesn't match the file owner of the lowerdir.
The crux here is that 9p propagates the O_NOATIME flag to the host and
the guest kernel has no way of verifying whether that flag will lead to
any problems beforehand.
There is ongoing work to possibly fix this in the kernel, but it will
take a while until there is a working patch and consensus.
So in order to bring our default kernel back to 4.19 and of course make
it possible to run newer kernels in VM tests, I'm merging a small QEMU
patch as an interim solution, which we can drop once we have a working
fix in the next round of stable kernels.
Now we already had Linux 4.19 set as the default kernel, but that was
subsequently reverted in 048c36ccaa
because the patch we have used was the revert of the commit I bisected a
while ago.
This patch broke overlayfs in other ways, so I'm also merging in a VM
test by @bachp, which only tests whether overlayfs is working, just to
be on the safe side that something like this won't happen in the future.
Even though this change could be considered a moderate mass-rebuild at
least for GNU/Linux, I'm merging this to master, mainly to give us some
time to get it into the current 19.03 release branch (and subsequent
testing window) once we got no new breaking builds from Hydra.
Cc: @samueldr, @lheckemann
Fixes: https://github.com/NixOS/nixpkgs/issues/54509
Fixes: https://github.com/NixOS/nixpkgs/issues/48828
Merges: https://github.com/NixOS/nixpkgs/pull/57641
Merges: https://github.com/NixOS/nixpkgs/pull/54508
This reverts commit 048c36ccaa.
With the patch applied for fixing the overlayfs bug in QEMU, there
really shouldn't stand anything in our way to use 4.19 as the default
kernel.
Signed-off-by: aszlig <aszlig@nix.build>
Back in 2017 I removed the `activator` package (see 25a3563102)
as it reached its end of life. Almost 2 years later everyone
shouldn't reference to this (not evaluating) path anymore
and hence can be removed.
