By default, "nix-env -i ghostscript" used to install a version of Ghostscript
that didn't support X11. IMHO, this was the wrong choice for a user profile.
svn path=/nixpkgs/trunk/; revision=23829
Also replace the monolitic derivation hol_light_binaries with smaller
derivations. Now the installation works as follows:
# Install the base system and a script "start_hol_light"
$ nix-env -i hol_light_sources hol_light
# Install a checkpointed executable with the core library preloaded
$ nix-env -i hol_light_core_dmtcp
# Install HOL Light binaries preloaded with other specific libraries:
$ nix-env -i hol_light_multivariate_dmtcp
$ nix-env -i hol_light_complex_dmtcp
$ nix-env -i hol_light_sosa_dmtcp
$ nix-env -i hol_light_card_dmtcp
svn path=/nixpkgs/trunk/; revision=23815
i.e., remove the version from the name. Nix has its own mechanism to
prevent a packages to be upgraded. Instead we distinguish development
version (coq-dev-VERSION) from stable versions (coq-VERSION).
Also remove derivation for coq-8.3-beta0-1 which is now superseded by
coq-devel-8.3pre1.
svn path=/nixpkgs/trunk/; revision=23813
Note: In this version we introduce a new schema for the name of the coq
derivations where the coq version is included in the name (i.e.,
"coq8.3-8.3pre1" instead of "coq-8.3pre1"). The reason for this is that often
coq releases introduce several incompatibilities. Thus I argue that, in
general, users do not want nix-env to upgrade automatically form one release to
another. Also version string "8.3pre1" is used instead of "8.3-rc1" to trigger
the nix mechanism for versions comparison.
svn path=/nixpkgs/trunk/; revision=23803
It should work for both firefox 3.6 and firefox 3.5 (said roconnor on irc).
Thanks to the wiki page http://wiki.nixos.org/wiki/Java_in_Firefox which explained
why what we had did not work.
svn path=/nixpkgs/trunk/; revision=23801
It had to be 'coreutils' instead, but I don't think they cross-build. They
cross-build only in stdenv-updates I tihnk.
svn path=/nixpkgs/trunk/; revision=23774
flipped to denote what it actually does (i.e., a string fragment
that comes *after* the named fragments). One day we can have
`stringBefore'.
svn path=/nixpkgs/trunk/; revision=23761
