makeinfo (provided by the texinfo package) is used by the "help"
command in Octave to display info about functions, etc. By default,
Octave looks for "makeinfo" in the PATH, rather than specifying the
location of the executable. This results in Nix not being aware that
makeinfo is required at runtime (so unless you happen have makeinfo
available from your path, "help" won't work).
This patch fixes that by setting the path to makeinfo in Octave,
thereby creating a runtime dependency on texinfo.
This change is required on darwin, but did not make it into the 4.2.1
release of Octave. It is a very small change, and a comment on the
patch includes a link for more information and a note that it should
be removed from subsequent releases.
This was one of the ways to build packages, we are trying
hard to minimize different ways so it's easier for newcomers
to learn only one way.
This also:
- removes texLive (old), fixes #14807
- removed upstream-updater, if that code is still used it should be in
separate repo
- changes a few packages like gitit/mit-scheme to use new texlive
This follows on from PR #16965 for qrupdate and PR #16968 for fltk.
WIth these, the added explicit dependencies on arpack (to support
the octave `eigs` function) and `libwebp`, and not pulling X11 things,
octave works properly on darwin.
The expression inherits integer width from OpenBLAS, so Octave will use
64-bit integers if OpenBLAS supports it. However, this feature in Octave
is experimental, so we continue to use OpenBLAS with 32-bit integers by
default. (This only applies to the integer width, the pointer width is
always the platform-native width.)
I find octave quite unusable, without its help pages. Recently it started to
require gnuplot to generate them (even the text-only).
I also enabled parallel building. A comment from 2012 said about spurious
failures if it were enabled, but I don't know if these happen again. Let's
enable it to see.
(cherry picked from commit a6f1024b1f)
Conflicts:
pkgs/top-level/all-packages.nix
I also add more libs octave appreciates for some functions.
I've not tested the graphics toolkit, but it builds.
svn path=/nixpkgs/trunk/; revision=32465
Linking octave with clapack did not work.
I updated lapack, and additionally I build it with atlas, instead of blas. That should give
better performance. I don't know if atlas builds everywhere though.
On the other hand, maybe some programs linking with liblapack will fail. We'll have to check
the hydra reports.
I plan to remove clapack; liblapack provides a C interface too.
svn path=/nixpkgs/trunk/; revision=32464
plot(1), as 3.6.0 also did. I don't know what's wrong there.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff694e3ad in dtrtri_
Exact as 3.6.0. I'll revert to the old octave version that worked without any
blas or lapack implementation.
--This line, and those below, will be ignored-e-
M pkgs/development/interpreters/octave/default.nix
svn path=/nixpkgs/trunk/; revision=32460
Made octave link with graphicsmagick to get imread() working.
Nevertheless, imread does not work, because of some problems between octave and latest versions of graphicsmagick: http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-February/015295.html
Next to do: add an older version of graphics magick for octave.
svn path=/nixpkgs/trunk/; revision=20389
source regions which are substituded by the tool nix-repository-manager.
See http://github.com/MarcWeber/nix-repository-manager/raw/master/README.
sourceByName is called sourceFromHead now.
updates: MPlayerTrunk, haxe, neko, netsurf, cinelerra, ctags
cinelerra does no longer build due to Xorg update
svn path=/nixpkgs/trunk/; revision=18894
