Network error when cargo-build-system fetches dependency from external repository specified in Cargo.toml

Network error when cargo-build-system fetches dependency from external repository specified in Cargo.toml

[Airi via]

Hello,
I am trying to package a program using the cargo-build-system.
During the build phase, it tries to fetch a dependency specified in the Cargo.toml file, but fails with a network issue. But when built outside of Guix with a hand-typed "cargo build --release", it builds without error. It's almost as though the cargo-build-system has some kind of network sandbox that prevents fetching repos from urls during the build phase...
Error logs during the build:
 
starting phase `build'
    Updating git repository `https://github.com/hearth-rs/msdfgen-rs`
warning: spurious network error (3 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12)
warning: spurious network error (2 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12)
warning: spurious network error (1 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12)
error: failed to get `msdfgen` as a dependency of package `font-mud v0.1.0 (/tmp/guix-build-rust-font-mud-9999.drv-0/source)`
 
The Cargo.toml file with the problematic dependency looks like this:
 
[dependencies.msdfgen]
git = "https://github.com/hearth-rs/msdfgen-rs"
branch = "fix-mac-builds"
default-features = false
features = ["ttf-parser", "png"]
 
I found that the same error occurs regardless of the url it tries to fetch from, so it's not an issue with the website. It is also not an issue with my network, since building works just fine outside of Guix package.
My assumption is that either cargo-build-system disallows connecting to websites during the build phase, or that using "git = <url>" to specify a cargo dependency in Cargo.toml is buggy with cargo-build-system. I'm really hoping that there is a cleaner fix to this than having to modify the Cargo.toml file through the package definition...
I'm wondering if perhaps there's a way clean way to override processing this dependency in Cargo.toml? And then create a separate package definition to replace that dependency? Or maybe there's a keyword for cargo-build-system that fixes this weird network issue? Or maybe the method of defining dependencies with git urls in Cargo.toml is not an appropriate practice?
The program I'm trying to package is here: https://git.disroot.org/hearth/font-mud
And here is my package definition:
 
(define rust-font-mud-9999
  (package
    (name "rust-font-mud")
    (version "9999")
    (source
     (origin
       (method git-fetch)
       (uri (git-reference
             (url "https://git.disroot.org/hearth/font-mud")
             (commit "c1e6b66f459e32ee90de2a1c29b8a2124a1a9bad")))
       (file-name (string-append name "-" version ".tar.gz"))
       (sha256
        (base32 "19a9lra546f91a3lvjjr7y9yah8q2df8754n5ch9vwdm5hdplf54"))))
    (build-system cargo-build-system)
    (home-page "https://git.disroot.org/hearth/font-mud")
    (synopsis "A library for dynamically generating and packing MSDFs of text glyphs")
    (description "A library for dynamically generating and packing MSDFs of text glyphs.")
    (license license:asl2.0)))
 
Any help would be greatly appreciated.
 
Thanks,
Airi

Re: Network error when cargo-build-system fetches dependency from external repository specified in Cargo.toml

[Ian Eure]

Hi Airi,

Airi via <help-guix@gnu.org> writes:

> Hello,
> I am trying to package a program using the cargo-build-system.
> During the build phase, it tries to fetch a dependency specified 
> in the Cargo.toml file, but fails with a network issue. But when 
> built outside of Guix with a hand-typed "cargo build --release", 
> it builds without error. It's almost as though the 
> cargo-build-system has some kind of network sandbox that 
> prevents fetching repos from urls during the build phase...

All Guix builds, regardless of the build-system they use, run in 
an isolated environment without network access, to enforce 
reproducible builds.

I’m not familiar with Rust or Cargo, but I believe you need to 
package the dependencies msdfgen-rs uses.

  — Ian

Re: Network error when cargo-build-system fetches dependency from external repository specified in Cargo.toml

[Ignas Lapėnas]

Hi Airi,

All rust builds are isolated from the network. In order to build a package,
usually you must provide packages from guix crates-io.scm
<https://git.savannah.gnu.org/git/guix.git/>

Using guix edit and a rust package would also open a current version of guix

for example `guix edit rust-async-recursion` would open crates-io.scm and point
to the package.

┌────
│ (define-public rust-async-recursion-1
│   (package
│     (name "rust-async-recursion")
│     (version "1.0.4")
│     (source (origin
│               (method url-fetch)
│               (uri (crate-uri "async-recursion" version))
│               (file-name (string-append name "-" version ".tar.gz"))
│               (sha256
│                (base32
│                 "1fhwz7jqgsakbjsr2nrsvgs245l1m5dkzir6f9fxw4ngwrywx5qf"))))
│     (build-system cargo-build-system)
│     (arguments
│      `(#:tests? #f      ; TODO: Tests unexpectedly pass.
│        #:cargo-inputs
│        (("rust-proc-macro2" ,rust-proc-macro2-1)
│         ("rust-quote" ,rust-quote-1)
│         ("rust-syn" ,rust-syn-2))
│        #:cargo-development-inputs
│        (("rust-futures-executor" ,rust-futures-executor-0.3)
│         ("rust-trybuild" ,rust-trybuild-1))))
│     (home-page "https://github.com/dcchut/async-recursion")
│     (synopsis "Recursion for async functions")
│     (description "This package provides recursion for async functions in Rust.")
│     (license (list license:expat license:asl2.0))))
└────

The same file contains a lot of example rust packages you can check how
dependencies are “injected”

Also if there are packages that are missing `guix import crate <crate>@<version>`
command is a godsend. Typing it all out would be insane.

Hope it helps.

– 
Best Regards,
Ignas Lapėnas