Before, we'd always use `cc = null`, and check for that. The problem is
this breaks for cross compilation to platforms that don't support a C
compiler.

It's a very subtle issue. One might think there is no problem because we
have `stdenvNoCC`, and presumably one would only build derivations that
use that. The problem is that one still wants to use tools at build-time
that are themselves built with a C compiler, and those are gotten via
"splicing". The runtime version of those deps will explode, but the
build time / `buildPackages` versions of those deps will be fine, and
splicing attempts to work this by using `builtins.tryEval` to filter out
any broken "higher priority" packages (runtime is the default and
highest priority) so that both `foo` and `foo.nativeDrv` works.

However, `tryEval` only catches certain evaluation failures (e.g.
exceptions), and not arbitrary failures (such as `cc.attr` when `cc` is
null). This means `tryEval` fails to let us use our build time deps, and
everything comes apart.

The right solution is, as usually, to get rid of splicing. Or, baring
that, to make it so `foo` never works and one has to explicitly do
`foo.*`. But that is a much larger change, and certaily one unsuitable
to be backported to stable.

Given that, we instead make an exception-throwing `cc` attribute, and
create a `hasCC` attribute for those derivations which wish to
condtionally use a C compiler: instead of doing `stdenv.cc or null ==
null` or something similar, one does `stdenv.hasCC`. This allows quering
without "tripping" the exception, while also allowing `tryEval` to work.

No platform without a C compiler is yet wired up by default. That will
be done in a following commit.

This platform doesn't have a C compiler, and so relies and the changes
in the previous commit to work.

This is GHCJS, and perhaps other obscure targets.

js-ghcjs didn't fit in an existing categor.

js-ghcjs didn't fit in an existing categor.

…oss-without-cc-19.09

Use `buildPackages.stdenv.mkDerivation` because we are making a shell
script to start hoogle on the build platform.

…-cc-19.09

This is a bit dubvious, but the alternative of making nodejs a
nativeBuildInput for node packages is worse. In general the cross story
for interpreted languages is murky, and this fits that pattern.

…-cc-19.09

This makes us a bit more robust to various splicing nastiness. May splicing
someday go so we don't have to resort to such hacks.

…-cc-19.09

(cherry picked from commit 59dbb00)

…-cc-19.09

Otherwise it passes `--with-ghc=ghc`, and we do the wrong thing.

…-cc-19.09

…-cc-19.09

Needed by CrossCode

(cherry picked from commit 21958c0)

… into ghcjs-cross-without-cc-19.09

…-19.09

stdenv, haskell: bonafied GHCJS cross compilation without stdenv.cc  for 19.09

(cherry picked from commit a436604)

(cherry picked from commit 3ab3614)

nix: 2.3 -> 2.3.1

(cherry picked from commit 62100c3)

(cherry picked from commit f9eae42)

(cherry picked from commit aa74012)

Bugfixes; master has 2.9.x already.
https://gitlab.labs.nic.cz/knot/knot-dns/tags/v2.8.5

This reverts commit 2ce54ed.

(cherry picked from commit 3ab3614)

…ssion

In fact, don't create them at all because Nix does that automatically.

Also remove modules/programs/shell.nix because everything it did is
now done automatically by Nix.

(cherry picked from commit 4e0d6a5)

(cherry picked from commit 27d2857)

(cherry picked from commit 9d0de0d)

[19.09] nix: 2.3 -> 2.3.1

Rationale for this backport: not entirely sure why this starts to fail
now, but this change fixes the build on 19.09: https://hydra.nixos.org/build/109120376

(cherry picked from commit 5cc8fdb)

https://github.com/matrix-org/synapse/releases/tag/v1.7.3
(cherry picked from commit a5689a2)

This is what I've suspected a while ago[1]:

> Heads-up everyone: After testing this in a few production instances,
> it seems that some browsers still get cache hits for new store paths
> (and changed contents) for some reason. I highly suspect that it might
> be due to the last-modified header (as mentioned in [2]).
>
> Going to test this with last-modified disabled for a little while and
> if this is the case I think we should improve that patch by disabling
> last-modified if serving from a store path.

Much earlier[2] when I reviewed the patch, I wrote this:

> Other than that, it looks good to me.
>
> However, I'm not sure what we should do with Last-Modified header.
> From RFC 2616, section 13.3.4:
>
> - If both an entity tag and a Last-Modified value have been
>   provided by the origin server, SHOULD use both validators in
>   cache-conditional requests. This allows both HTTP/1.0 and
>   HTTP/1.1 caches to respond appropriately.
>
> I'm a bit nervous about the SHOULD here, as user agents in the wild
> could possibly just use Last-Modified and use the cached content
> instead.

Unfortunately, I didn't pursue this any further back then because
@pbogdan noted[3] the following:

> Hmm, could they (assuming they are conforming):
>
>  * If an entity tag has been provided by the origin server, MUST
>    use that entity tag in any cache-conditional request (using If-
>    Match or If-None-Match).

Since running with this patch in some deployments, I found that both
Firefox and Chrome/Chromium do NOT re-validate against the ETag if the
Last-Modified header is still the same.

So I wrote a small NixOS VM test with Geckodriver to have a test case
which is closer to the real world and I indeed was able to reproduce
this.

Whether this is actually a bug in Chrome or Firefox is an entirely
different issue and even IF it is the fault of the browsers and it is
fixed at some point, we'd still need to handle this for older browser
versions.

Apart from clearing the header, I also recreated the patch by using a
plain "git diff" with a small description on top. This should make it
easier for future authors to work on that patch.

[1]: NixOS/nixpkgs#48337 (comment)
[2]: NixOS/nixpkgs#48337 (comment)
[3]: NixOS/nixpkgs#48337 (comment)

Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit ccf55be)
Reason: The issue breaks setups that serve static content via Nix store
        paths. I've also backported the NixOS VM test from Python to
        Perl.