Acknowledgement sent
to Nils Gillmann <ng0@n0.is>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Tue, 31 Jul 2018 20:01:02 GMT) (full text, mbox, link).
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
Information forwarded
to bug-guix@gnu.org: bug#32339; Package guix.
(Tue, 18 Jun 2019 14:15:01 GMT) (full text, mbox, link).
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
Information forwarded
to bug-guix@gnu.org: bug#32339; Package guix.
(Fri, 21 Jun 2019 15:07:02 GMT) (full text, mbox, link).
Hello,
Andreas Enge <andreas@enge.fr> skribis:
> 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>").
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’.
Information forwarded
to bug-guix@gnu.org: bug#32339; Package guix.
(Tue, 20 Apr 2021 10:42:01 GMT) (full text, mbox, link).
Added tag(s) notabug.
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Tue, 20 Apr 2021 10:43:02 GMT) (full text, mbox, link).
bug closed, send any further explanations to
32339@debbugs.gnu.org and Nils Gillmann <ng0@n0.is>
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Tue, 20 Apr 2021 10:43:02 GMT) (full text, mbox, link).
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Tue, 18 May 2021 11:24:05 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.