Age | Commit message (Collapse) | Author |
|
|
|
|
|
(cherry picked from commit 92600a90e248aa27f2aedcce4ad309f987a390df)
|
|
I'm currently not maintaining any packages.
|
|
|
|
Test failed on i686 in a sandbox because some packages required
to build the nixos manual for the container were missing. Add them.
|
|
Since 4f6df27aee0a3f620d65280c7b6644d5cce094ae, nix.useSandbox defaults
to true which causes the Nix build within the containers-imperative test
to fail while trying to hardlink files into the chroot:
link("/nix/store/foo", "/nix/store/bar.drv.chroot/nix/store/foo")
= -1 EPERM (Operation not permitted)
The reason this happens is that the hosts store is mounted using 9p and
an overlayfs is mounted on top, so even if we would disable the tmpfs
for the upper directory the hardlink would still cross filesystem
boundaries, which then fails with the above error code.
I haven't yet seen any other test which fails in a similar way, which
might be because building within VM tests is not very common and the
installer tests build in a separate store, so they're not affected.
Signed-off-by: aszlig <aszlig@nix.build>
Issue: https://github.com/NixOS/nix/issues/2324
Cc: @aristidb, @edolstra, @chaoflow, @kampfschlaefer
|
|
This reverts commit 095fe5b43def40279a243e663c662b02caac5318.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
|
|
Apparently merging #43021 1bdb1387103 did increase memory usage
in some cases. 1 GiB for a VM memory seems still low enough to me.
|
|
While building the container there are a few occasions where stdenvNoCC
is used underneath. During the last staging merge, some change now tries
to build texinfo during the test while building stdenvNoCC.
With this change, I'm adding stdenvNoCC to the closure to make sure that
even when we have future stdenv changes, it doesn't break (well, except
if we do have another variation like stdenvNoCC that overrides stdenv).
I haven't bisected the exact change, but I'd suspect that it could be
one of the commits in #39457.
This fixes the test and it no longer fails with the following error:
error: unable to download 'http://ftpmirror.gnu.org/texinfo/texinfo-6.5.tar.xz': Couldn't resolve host name (6)
builder for '/nix/store/r7sf1wjbnimwgnv276jh59nfnzw40x30-texinfo-6.5.tar.xz.drv' failed with exit code 1
cannot build derivation '/nix/store/5w1pv788ayi1wahyy76i90yqv96ai4h5-texinfo-6.5.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/cnsfkf0j5xmm14zzm5a3a66pz66gbc82-stdenv-linux.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/11kkhk57ic8kfd7g197sqwgd0pzqfjhl-nixos-system-foo-0-18.09pre-git.drv': 1 dependencies couldn't be built
error: build of '/nix/store/11kkhk57ic8kfd7g197sqwgd0pzqfjhl-nixos-system-foo-0-18.09pre-git.drv' failed
/run/current-system/sw/bin/nixos-container: failed to build initial container configuration
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @aristidb, @edolstra, @chaoflow, @kampfschlaefer
|
|
... introduced by 1f0b6922d3c
continuation of 88fa50c2f2bbc472fe7169eac8f2a1b2312ef03b
|
|
The commit c6f7d4367894047592cc412740f0c1f5b2ca2b59 changed the system
attribute to be below config.nixpkgs.localSystem, but the test still
uses the old attribute.
I have not tested whether the test actually succeeds but just checked
whether evaluation works and it evaluates successfully now.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
I can't claim to fully understand this, but the change seems safe,
and it fixes the test on my machine.
|
|
Seems like the right thing to do.
|
|
Just removing the system argument because it doesn't exist (it's
actually config.nixpkgs.system, which we're already using). We won't get
an error anyway if we're not actually using it, so this is just an
aesthetics fix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
Make sure that we always have everything available within the store of
the VM, so let's evaluate/build the test container fully on the host
system and propagate all dependencies to the VM.
This way, even if there are additional default dependencies that come
with containers in the future we should be on the safe side as these
dependencies should now be included for the test as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @kampfschlaefer, @edolstra
|
|
|