"nix import" fails

Hooray, a bad subject line!

FWIW, this was while running the Nix daemon with my "service", but it

is not required for the imports.

abyayala$ guix import nix ~/re-src/nixpkgs curl

;;; SSAX warning: Skipping PI: xml

trace: stdenv.isArm is deprecated after 18.03

trace: lib.zip is deprecated, use lib.zipAttrsWith instead

trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`

trace: `mkStrict' is obsolete; use `mkOverride 0' instead.

trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!

error: stack overflow (possible infinite recursion)

Backtrace:

In guix/import/snix.scm:

191:9 19 (loop #<input: #{read pipe}# 14> () #f _)

191:9 18 (loop #<input: #{read pipe}# 14> () #f _)

191:9 17 (loop #<input: #{read pipe}# 14> () #f _)

191:9 16 (loop #<input: #{read pipe}# 14> () #f _)

191:9 15 (loop #<input: #{read pipe}# 14> () #f _)

191:9 14 (loop #<input: #{read pipe}# 14> () #f _)

191:9 13 (loop #<input: #{read pipe}# 14> () #f _)

191:9 12 (loop #<input: #{read pipe}# 14> () #f _)

191:9 11 (loop #<input: #{read pipe}# 14> () #f _)

191:9 10 (loop #<input: #{read pipe}# 14> () #f _)

191:9 9 (loop #<input: #{read pipe}# 14> () #f _)

191:9 8 (loop #<input: #{read pipe}# 14> () #f _)

191:9 7 (loop #<input: #{read pipe}# 14> () #f _)

191:9 6 (loop #<input: #{read pipe}# 14> () #f _)

191:9 5 (loop #<input: #{read pipe}# 14> () #f _)

191:9 4 (loop #<input: #{read pipe}# 14> () #f _)

191:9 3 (loop #<input: #{read pipe}# 14> () #f _)

191:9 2 (loop #<input: #{read pipe}# 14> () #f _)

191:9 1 (loop #<input: #{read pipe}# 14> () #f _)

In sxml/upstream/SSAX.scm:

1896:21 0 (_ #<input: #{read pipe}# 14> #f #<procedure 7f8b08622…> …)

sxml/upstream/SSAX.scm:1896:21: Throw to key `parser-error' with args `(#<input: #{read pipe}# 14> "EOF while

reading a token " "reading char data")'.

This bug is resolved by following the current documentation and

executing

export NIX_REMOTE=daemon

.

However, even then the import fails:

$ guix import nix nixpkgs/ hello

;;; SSAX warning: Skipping PI: xml

trace: warning: `stdenv.isArm` is deprecated after 18.03. Please use `stdenv.isAarch32` instead

trace: lib.zip is deprecated, use lib.zipAttrsWith instead

trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`

trace: `mkStrict' is obsolete; use `mkOverride 0' instead.

trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!

And after about 15 minutes the import crashes with a stack overflow.

Andreas

Sorry, I did not look at the error message well enough, the bug is indeed

still the same as reported.

Andreas

So, I just discussed with a Nix expert, Profpatsch.

Apparently something changed in nixpkgs a while ago, so that the following

code does not work any more:

$ export NIX_REMOTE=daemon

$ nix-instantiate --eval --strict -A hello nixpkgs/

trace: `types.list` is deprecated; use `types.listOf` instead

trace: types.optionSet is deprecated; use types.submodule instead

trace: Warning: `showVal` is deprecated and will be removed in the next release, please use `traceSeqN`

trace: `lib.nixpkgsVersion` is deprecated, use `lib.version` instead!

trace: lib.zip is deprecated, use lib.zipAttrsWith instead

trace: `mkStrict' is obsolete; use `mkOverride 0' instead.

trace: warning: `stdenv.isArm` is deprecated after 18.03. Please use `stdenv.isAarch32` instead

trace: warning: `stdenv.isArm` is deprecated after 18.03. Please use `stdenv.isAarch32` instead

trace: warning: `stdenv.isArm` is deprecated after 18.03. Please use `stdenv.isAarch32` instead

trace: warning: `stdenv.isArm` is deprecated after 18.03. Please use `stdenv.isAarch32` instead

error: overrideDerivation not yet supported for functors

(use '--show-trace' to show detailed location information)

We should have checked the return value...

Omitting the "--strict" flag is not a solution, since then lazy evaluation

leads to most interesting fields of the result being empty (the return string

value is "<CODE>").

A potential solution is evaluating for different package fields separately,

but this would require more or less a complete rewrite of the importer.

I wonder if the solution would not be to drop it completely... Interestingly

enough, the programmatic nature of Nix makes it much more difficult to import

packages, since we cannot simply use the abstract syntax tree of the

textual representation of a package.

Here are a few possible commands to run:

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; singular.version"

"4.1.1p2"

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; map (drv: drv.name) singular.buildInputs"

[ "gmp-6.1.2" "ncurses-6.1-20190112" "readline-6.3p08" "ntl-11.3.2" "flint-2.5.2" "cddlib-0.94j" ]

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; map (drv: drv.name) singular.nativeBuildInputs"

[ "bison-3.3.2" "perl-5.28.2" "pkg-config-0.29.2" "hook" ]

(notice that there is now a difference between build and native build

inputs, and even more types)

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; singular.src"

[error message]

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; (singular.override { fetchurl = lib.id; }).src"

{ sha256 = "07x9kri8vl4galik7lr6pscq3c51n8570pyw64i7gbj0m706f7wf"; url = "http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-1-1/singular-4.1.1p2.tar.gz";}

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; (linbox.override { fetchurl = lib.id; }).src"

[error message]

$ nix-instantiate --eval --strict -E "with import $PATH_TO_NIXPKGS {}; (linbox.override { fetchFromGitHub = lib.id; }).src"

{ owner = "linbox-team"; repo = "linbox"; rev = "v1.6.3"; sha256 = "10j6dspbsq7d2l4q3y0c1l1xwmaqqba2fxg59q5bhgk9h5d7q571"; }

So for the latter two cases, one would need to try both and catch errors.

Andreas

Hello,

Andreas Enge <andreas@enge.fr> skribis:

Do we know exactly why Nix stack-overflows? Perhaps we’re evaluating

fields we shouldn’t evaluate?

It used to work :-), so something must have changed in the Nix

evaluation rules or in how Nixpkgs attribute sets are written. We

should ask the Nix folks for guidance.

Ludo’.

‘guix import nix’ has now been removed:

https://issues.guix.gnu.org/47871

Closing!

Ludo’.

tags 32339 notabug

close 32339

quit