is now made available in the interactive test driver. For instance,
you can do
$ nix-build tests/ -A quake3.driver
$ ./result/bin/nixos-test-driver
> eval $ENV{'testScript'};
... see VMs + X11 + Quake get started, bots running around ...
>
So after this you can run commands interactively on the VMs in the
state they were in after the conclusion of the test script.
svn path=/nixos/trunk/; revision=25158
interactively on a network specification. For instance:
$ nix-build tests/ -A quake3.driver
$ ./result/bin/nixos-test-driver
> startAll;
client1: starting vm
client1: QEMU running (pid 14971)
server: starting vm
server: QEMU running (pid 14982)
...
> $client1->execute("quake3 ...");
* Use the GNU readline library in interactive mode.
svn path=/nixos/trunk/; revision=25156
attribute name of the machine in the model. This allows
networking.hostName and deployment.targetHost to be omitted for
typical networks.
svn path=/nixos/trunk/; revision=25125
I've packaged this as a separate expression because it depends on poppler (why
don't they look for pdftops on runtime?..).
svn path=/nixpkgs/trunk/; revision=25124
It's really an abstract configuration option that specifies that *some*
SSH daemon should be enabled (which could be OpenSSH).
svn path=/nixos/trunk/; revision=25119
I had added the audit_suid.patch some time ago, and at some point niksnut added
this ignore-origin.patch. I think both fix the situation, the
ignore-origin.patch being released sooner than the audit_suid. As the
ignore-origin-patch is not in the recent glibc, it makes me think it was a quick
solution to the vulnerability, later properly fixed.
I remove, then, the ignore-origin.patch. We can check later if we remain
vulnerable.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25110
I also update the url for the ports to take the upstream tarball instead of a
copy I had in vicerveza.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25108
path worth a "-rpath" entry.
This put a problem in the bootstrap, where we built 'zlib' and wanted to link programs with it, and while they got linked well, at runtime the boostrap-tools zlib came first on rpath becaue
the ld call was done with "-dynamic-linker ..." before "-lz".
I saw this trouble on the fuloong, where the zlib in boostrap-tools is not
runtime compatible with that binutils are linked to.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25107
Michael Raskin