[flakes] git cannot resolve host when running during build

Help
1

I want to use flakes for the dependency management of my personal projects, which are written in D and built with meson. Until I have derivations for all dependencies, I need/want to rely on meson subprojects to fetch some dependencies for me. However when meson invokes git to clone the resp. repositories, git fails to lookup github.com:

nix-flakes-meson-git$ nix build
error: builder for '/nix/store/a7hj42jz1ic9gs5mnz85yaanfi83iixc-test-0.0.1.drv' failed with exit code 1;
       last 10 log lines:
       > Did not find CMake 'cmake'
       > Found CMake: NO
       > Run-time dependency zmqd found: NO (tried pkgconfig and cmake)
       > Looking for a fallback subproject for the dependency zmqd
       > Cloning into 'zmqd'...
       > fatal: unable to access 'https://github.com/kyllingstad/zmqd.git/': Could not resolve host: github.com
       >
       > meson.build:3:0: ERROR: Git command failed: ['/nix/store/0c7k0znjz1j67vyh7rkas655daxh0dd5-git-2.33.1/bin/git', 'clone', 'https://github.com/kyllingstad/zmqd.git', 'zmqd']
       >
       > A full log can be found at /build/68fdcmb12zb4j221j21znn85f8s6algp-source/build/meson-logs/meson-log.txt
       For full logs, run 'nix log /nix/store/a7hj42jz1ic9gs5mnz85yaanfi83iixc-test-0.0.1.drv'.

I put up an minimal example project that reproduces the error for me. Interestingly, prior to this, git failed because no certificates were available, which I tried to fix by having GIT_SSL_CERT pointing to nixpkgs.cacert, but I cannot reproduce that error anymore. I guess it will show up again once I have the DNS lookup work.

I know meson’s subprojects are not the epitome of reproducible builds, but it’s a practical choice right now, to gradually convert everything to nix/flakes.

How do I get this working? All pointers are appreciated!

2

You do not have network access in a derivation, unless you make it a “fixed output derivation” by providing a content hash in advance.

3

So it’s impossible? I could retrieve the dependencies with fetchGit and make meson subprojects point to the store, but that would break it for everyone not using nix. Alternatively, I could write a small tool that parses the wrap files, creates derivations for the contents and patch them up during a pre build phase, but than it’s prolly easier to write derivations for the few deps I have.

4

I do not know anything about meson, but I know there are a lot of sub ecosystems, that use additional FODs to download external sourcecode and link/copy it in place such that the build system can find it.

5

I’d probably take that approach; On the other hand, if you’d like to help the next person running into this, a tool to make wrap files just work would probably be a good addition to the ecosystem; don’t think one exists yet.

Note that when using wrap files the way you do in your example project you’re not controlling your inputs at all. Someone cloning and building your repository may get a completely different revision of your dependency, which would break their build; if you’re going to write nix derivations, I’d recommend sticking a fixed sha in there somewhere, so your nix and normal builds don’t drift apart.

6

Note that when using wrap files the way you do in your example project you’re not controlling your inputs at all. Someone cloning and building your repository may get a completely different revision of your dependency, which would break their build; if you’re going to write nix derivations, I’d recommend sticking a fixed sha in there somewhere, so your nix and normal builds don’t drift apart.

Once I have it working, I’ll fix the versions.

1 Like
7

It gives the wrong error on rebuild as well

   > Warning: Problem : timeout. Will retry in 4 seconds. 1 retries left.
   >   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (6) Could not resolve host: github.com

maybe if someone is googling this the solution is not to set the hash to null, it should be lib.fakeSha256 and then you can replace with the correct one

8

For most cases on modern nixpkgs (anything since 22.11 IIRC) setting hash to null or "" or leaviing it off, should just work for most fetchers.

If you have to do the low level stuff for FODs, then of course then things are slightly different. Though lib.fakeHash is to be prefered today over lib.fakeSha256.

1 Like