At the upstream URL at http://git.uclibc.org/uClibc/snapshot/, older
versions are dropped at a regular basis. Unfortunately the tarball
"uClibc-20150131.tar.bz2" has already been deleted from that directory
and I didn't find a mirror providing the same file.
So I've switched it to use fetchzip from the cgit site instead of using
fetchgit directly. The reason why I didn't use fetchgit is that we'd
need need git, which depends (indirectly? not sure, haven't checked) on
libiconv and that in turn triggers an assertion if we're on Linux and
are cross-building using uclibc.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- upgrade 106 -> 108
- fix passphrase rewrapper (password changing should now work fine) as
discussed on https://bugs.launchpad.net/ecryptfs/+bug/1486470
- add lsof dependency so ecryptfs-migrate-home should work out of the
box
All files, dependencies, etc. appear to now be set correctly. Tested
with 'cabal test' in a local nix-shell environment.
Closes https://github.com/peti/nixpkgs/pull/20.
Version 5 doesn't build because it depends on broken/EOL'd python 2.6. Better
switch to something that works. Most users of unversioned cudatoolkit attr are
r-packages, but they are already marked as broken.
Another user is haskellPackages.cuda, it builds fine with cuda 7.
Using sourceforge gives release binaries which don't require us to
regenerate all of the autotools scripts. This removes the need for
dependencies like cppunit and libgcrypt and autoreconfHook.
cc @geerds
Currently it errors out at build time with:
/nix/store/HASH-cudatoolkit-6.5.19/usr_include/host_config.h:82:2:
error: #error -- unsupported GNU version! gcc 4.9 and up are not supported!
Instead of downgrading gcc to 4.8, this patch upgrades cuda to 7.0, which
I think is the better choice. (Cuda 7 dropped support for some older graphics
cards, but gained support for newer ones.)
* Build most of the stuff on /tmp, not in /nix/store.
* Generate hoogle database for all the dependencies.
* Generate haddock index and contents files.
* Cleanup.
`man 1 info` says:
The first non-option argument, if present, is the menu entry to
start from; it is searched for in all `dir' files along INFOPATH.
If it is not present, info merges all `dir' files and shows the
result. Any remaining arguments are treated as the names of menu
items relative to the initial node visited.
Which means that this does what previous programs/info did and #8519
(on-the-fly infodir generation for Emacs) wanted to do, but for both
programs.
