I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
- Adding podofo
- Adding some new python packages
- Making new pkgs attributes for python packages to build with python 2.6
- Updating some python packages expressions to allow python 2.6, and not only 2.5.
svn path=/nixpkgs/trunk/; revision=19303
make cabal expression add etxra library paths only if they exist.
Adding myself as maintainer so that the buildfarm builds ghc.
svn path=/nixpkgs/trunk/; revision=19198
As app-defaults should be installed with the libXt (maybe it's libXt which loads them), and
stracing that is the place where the code looks for app-defaults (the libXt store path), I
don't know of any better solution in nixpkgs by now.
svn path=/nixpkgs/trunk/; revision=19092
ghdl-wrapper.
I made the gcc-4.3.4 expression allow the 'vhdl' language through ghdl.
The ghdl developer recommends this gcc version; maybe it would work with
gcc-4.4. If not this ghdl version, maybe next versions.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19071
broke the evaluation of nixpkgs.
I also tried to make the gnat wrapper friendly to any gnat installation, not
only gnatboot.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19062
Some things don't work:
- The ghdl expression (it still needs the gcc 4.3.4 src, ...)
- The gnat wrappers need to be more generic - now they work only for the
given gnatboot (taken from gentoo) and gnats installed to their $out
store path.
- Using the cloogppl and ppl. We will need our own gnatboot built with c++
libraries for that.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19060
most of the kernel expressions for the sheevaplug).
I still have not added anything in the kernels about cross compilation.
I moved the platform definitions out of all-packages.
I have not written good platform definitions for the sheevaplug - only for the
PC.
Only the linux-2.6.32 expression uses the platforms kernelConfig.
The linux-2.6.31 was broken, and I left it broken.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19046
sheevaplug kernel, so the kernel does not build in the sheevaplug right now.
I will try to fix that in next commits.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19045
I added 'perl' as their buildInputs to get them built.
I don't know if it is something new from nvidia, but I imagine it may be
introduced in 2.6.31, for any module building.
svn path=/nixpkgs/trunk/; revision=19029
flag. Note that ATerm 2.5 causes Nix to segfault, and ATerm 2.8
doesn't even build on x86_64-linux (see
http://bugzilla.sen.cwi.nl:8080/show_bug.cgi?id=1042).
svn path=/nixpkgs/branches/stdenv-updates/; revision=19020
* Move kernel patches out of all-packages.nix to
os-specific/linux/kernel/patches.nix.
* Make the kernel config available under $out/config (it's also in
$out/lib/modules/$version/build/.config, but that's kind of hard to
find).
svn path=/nixpkgs/branches/kernel-config/; revision=18937
Removing any reference to the gcc-wrapper2, as now the gcc-wrapper already conveys
the changes, I created gcc-wrapper2 in trunk for.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18913
`generate-config.pl' runs `make config' to generate a Linux kernel
configuration file. For each question (i.e. kernel configuration
option), unless an override is provided, it answers "m" if possible,
and otherwise uses the default answer (as determined by the default
config for the architecture). This is safer than allmodconfig,
which answers "y" everywhere it can't answer "m" and thus ends up
enabling a lot of experimental or debug options. (For this reason,
a configuration generated by allmodconfig must be carefully checked
with every new release to ensure that nothing dangerous is enabled.
The default config should be safer wrt new kernel releases.)
Overrides are specified in the `config' argument to generic.nix,
which is a string that contains lines such as `EXT2_FS_POSIX_ACL y'.
The script warns about ignored options, and aborts if `make config'
selects an answer inconsistent with the one in `config'. This
allows us to be sure that `make config' doesn't silently override
our configuration values (e.g., depending on other options, it will
set FB_TILEBLITTING to "y" even if we want it to be "n").
svn path=/nixpkgs/branches/kernel-config/; revision=18910
which deals only with a build time dependency. Let's better have hydra
build cscope (I set me as a maintainer), and prefer simpler expressions
to options on build-time dependencies.
svn path=/nixpkgs/trunk/; revision=18902
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
stdenv.
In this gcc-wrapper2 I made the ld-wrapper.sh to handle the linking with shared
objects through direct pass as ld command arguments of the absolute path to shared
objects, instead of using the -L/-l combinations.
cmake 'FindXXX.cmake' modules make a strong usage of the dynamic linking directly
passing the absolute path to the shared object to the linker, and as our wrapper did
not add any -rpath for those, writting the nix expressions for some cmake packages
resulted in a lot of tricks, compared to using this gcc-wrapper2.
This gcc-wrapper2/ld-wrapper.sh should become the gcc-wrapper/ld-wrapper in a
stdenv update.
I also updated some cmake expressions to use this gcc-wrapper2, and reduced its
tricks.
I also updated the cmake setup-hook for it to make cmake not touch any rpath decided
at build time, when running the 'make install' of makefiles created by cmake.
svn path=/nixpkgs/trunk/; revision=18885
coreutils 7.6, which did not build well. The newer coreutils 8.1 work perfectly,
and we don't need to rely in older versions.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18836
Dealt with the gcc 4.4 expression for it to work well for a native and a cross
compiler, adding a pair of patches to get the job done without much side
effects. One (libtool problems on -B) comes from the gcc 4.3 expression, while
the other fixes a bug already fixed in gcc 4.4.3.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18833
between uclibc/glibc still.
I started the renaming from glibc to libc regarding the cross-toolchain, but I
still have to finish.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18801
I also set the 'glibcLocales' top-level attribute point to 2.11 instead of
2.10, to match that of the 'glibc' top-level attribute.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18746
Fixing the glibc-2.10 expression on cross-builds (which should be ported to
the glibc-2.11 expression once we get "ports" there)
Making kde3 and cyrus-sasl use gcc-4.3, because the strictness in gcc-4.4 does
not allow them build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18706
- I still have not understood why it worked without this fix before, and I think
this has been triggered by the gcc-4.4, but I have not investigated this much. I
went with the trivial fix.
Adding a glibc-2.10.1 expression, because the glibc-2.11 still does not have
a ports release, so it cannot be used in arm. I'm using it only in native
compilation by now.
Making the default glibc to be 2.10 instead of 2.11 in armv5tel-linux.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18688
renaming.
I think directory renaming breaks the usual merges... because it leaves the
'to be removed' directory in the working directory still. A manual 'rm' of the
'to be removed' directory fixed the commit.
svn merge ^/nixpkgs/trunk
svn path=/nixpkgs/branches/stdenv-updates/; revision=18661
