nix/sources.json: upgrade nixpkgs to the latest master

[basvandijk]

This upgrades nixpkgs to DFINITY's fork of nixpkgs which tracks the
master branch. There're only two patches on top of master:

commit a4e23f32f8d7006e217125a9123b53597b9c0c24 (HEAD -> dfinity-motoko, dfinity-lab/dfinity-motoko)
Author: Bas van Dijk <v.dijk.bas@gmail.com>
Date:   Wed Feb 12 16:08:05 2020 +0100

    expect: remove autoreconfHook since that causes a wrong path to stty

    See: https://github.com/NixOS/nixpkgs/issues/79863

commit f359aea057db81c51e55d7250283a0b2201bd6b6
Author: Bas van Dijk <v.dijk.bas@gmail.com>
Date:	Thu Feb 6 19:14:09 2020 +0100

    libuv: 1.34.1 -> 1.34.2

    (cherry picked from commit 21ad5c123b8e76ab241b89acbc8db24925244d63)

We need these patches in order to build motoko without using the
upstream cache.nixos.org. It would be good not to use an external
cache to decrease the chance an attacker can infect the cache with a
trojan and to ensure DFINITY can always build their own code without
depending on an external cache.

[nomeata]

Would we track upstream master again once they merge the cherry-pickes patch?

[basvandijk]

Would we track upstream master again once they merge the cherry-pickes patch?

Yes we can. The patch is currently in staging because it causes a mass-rebuild.

I won't merge this yet because I'm still testing this out on https://zh-hydra-int.dfinity.systems which has the upstream cache.nixos.org disabled.

[basvandijk]

This is currently blocked on the pkgsMusl.libffi failure: NixOS/nixpkgs#79863.

EDIT: this has been worked around.

[basvandijk]

@nomeata @ggreif I probably need a bit of help fixing the last remaining 2 bugs in the test suite:

• tests.ld failing with:

--- representative.linked.wat (expected)
+++ representative.linked.wat (actual)
@@ -28,4 +28,4 @@
   (table (;0;) 0 0 funcref)
   (memory (;0;) 2)
   (global (;0;) i32 (i32.const 65536))
-  (start 8))
+  (start $link_start))

• tests.run-drun failing with:

--- caller.drun-run (expected)
+++ caller.drun-run (actual)
@@ -4,7 +4,7 @@
 ingress Completed: Canister: Payload: 0x4449444c0000
 ingress Completed: Canister: Payload: 0x4449444c0000
 Ok: Payload: 0x4449444c0000
-ingress Completed: Canister: Payload: 0x4449444c016d7b010021000000000000000000000000000000000000000000000000000000000000000000
-Ok: Payload: 0x4449444c0001798d3a7c7a
-Ok: Payload: 0x4449444c00017d21
-Ok: Payload: 0x4449444c016e7b01000100
+ingress Completed: Canister: Payload: 0x4449444c016d7b0100020101
+Ok: Payload: 0x4449444c0001792813c52f
+Ok: Payload: 0x4449444c00017d02
+Ok: Payload: 0x4449444c016e7b01000101

I guess these are due to the dfinity v0.5.0 upgrade.

[ggreif]

• tests.ld failing with:

@basvandijk This is a benign change due to a new wasm2wat version? I have seen (and accepted) the same thing on my DWARF branch.

I'll leave the second for @nomeata.

[ggreif]

@basvandijk branch gabor/dwarf also has a Nixpkgs bump (though I am referencing my fork). I am happy with this change. Just asking, will 20.03 contain all of this or is that branch curated?

[nomeata]

Indeed, changes look benign. Just run make accept in tests within a nix-shell to update them (after running make in src and rts – we can do it if you don’t want to get into the pecularities of this build and test system).

[basvandijk]

@ggreif

will 20.03 contain all of this or is that branch curated?

Yes 20.03 will contain these fixes on our fork of nixpkgs.

@nomeata

Just run make accept

Done.

I'll open it up for review after CI is green.

[ggreif]

Haskell-related stuff looks good.

[nomeata]

Hmm, it seems it now wants to build

building '/nix/store/b0sd8xvaxvbpivf9v574pjs70wlmx1rr-ghc-8.8.1.drv'...

here, which is not found in any cache. I assume this might be because we use cabal2nix, which requires haskell at evaluation phase, but the Hydra setup doesn’t ensure that evaluation-time dependencies are in our nix cache (at the moment, rumors are that the “new” hydra setup will fix this), but we also now pull in a version of nixpkgs that isn’t necessarily on the “official” nix cache? @basvandijk could that be?

[nomeata]

Maybe we should simply commit the output of cabal2nix to the repo, it’s only four files (see nix/haskell-packages.nix).