In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Since years I'm not maintaining anything of the list below other
than some updates when I needed them for some reason. Other people
is doing that maintenance on my behalf so I better take me out but
for very few packages. Finally!
This update should also fix the build the hydra: one part of the
change is to build paraview with Qt-5.9, as this is the configuration
that paraview upstream supports.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
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
before it didn't. Through this commit I expect the build farm to try to build kde, and see
whether this way it builds without the unusual NIX_CFLAGS_COMPILE set in the qt setup-hook.
svn path=/nixpkgs/trunk/; revision=15838
