This continues #23374, which always kept around both attributes, by
always including both propagated files: `propgated-native-build-inputs`
and `propagated-build-inputs`. `nativePkgs` and `crossPkgs` are still
defined as before, however, so this change should only barely
observable.
This is an incremental step to fully keeping the dependencies separate
in all cases.
One should depend on
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables, regardless of
the host platform, at run time.
Netatalk 3.1.11 is the latest stable release. There is also a nasty bug
with netatalk < 3.1.11 (https://sourceforge.net/p/netatalk/bugs/636/)
that prevents using netatalk shares for time machine backups.
The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
This requires some small changes in the stdenv, then working around the
weird choice LLVM made to hardcode @rpath in its install name, and then
lets us remove a ton of annoying workaround hacks in many of our Go
packages. With any luck this will mean less hackery going forward.
Changes:
* The patch `glusterfs-fix-unsubstituted-autoconf-macros` was deleted
because the issue was fixed upstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1450588
* The `glusterd-ganesha.c` part of `glusterfs-use-PATH-instead-of-hardcodes`
was detleted because `glusterd-ganesha.c` was removed upstream
without replacement that has the relevant hardcoded paths.
Closes https://github.com/NixOS/nixpkgs/pull/29062
This fixes:
Traceback (most recent call last):
File "/nix/store/7f9arl3f9xyj8sm05mkanh2mlp217192-glusterfs-3.10.2/libexec/glusterfs/glusterfind/changelog.py", line 22, in <module>
import libgfchangelog
File "/nix/store/7f9arl3f9xyj8sm05mkanh2mlp217192-glusterfs-3.10.2/libexec/glusterfs/glusterfind/libgfchangelog.py", line 21, in <module>
libgfc = CDLL("libgfchangelog.so", use_errno=True, mode=RTLD_GLOBAL)
File "/nix/store/nlyr5ankhi7yvva8zndi718zj37js270-python-2.7.13-env/lib/python2.7/ctypes/__init__.py", line 362, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libgfchangelog.so: cannot open shared object file: No such file or directory
Connection to 10.0.0.2 closed.
when running `glusterfind pre`.
Done by setting PYTHONPATH/LD_LIBRARY_PATH as for the other
Python scripts.
Fixes error
File "/nix/store/lxpsl84km87xpk59nai6a33ihgpfs7qr-glusterfs-3.10.2/libexec/glusterfs/glusterfind/changelog.py", line 105, in populate_pgfid_and_inodegfid
file_xattrs = xattr.list(p)
AttributeError: 'module' object has no attribute 'list'
when using `glusterfind pre`.
* 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
It was being parsed incorrectly, as noted on
https://github.com/NixOS/nix/issues/1440
nix-repl> builtins.parseDrvName ntfs3g.name
{ name = "ntfs"; version = "3g-2017.3.23"; }
Or else `services.udev.packages = [ bcache-tools ]` cannot be used.
To not break bcache in the initrd I'm modifying this in stage-1.nix:
- --replace /bin/sh ${extraUtils}/bin/sh
+ --replace ${bash}/bin/sh ${extraUtils}/bin/sh
Reasoning behind that change:
* If not modifying the /bin/sh pattern in any way, it will also match
${bash}/bin/sh, creating a broken path like
/nix/store/HASH-bash/nix/store/HASH-bash/bin/sh in the udev rule file.
* The addition of /bin/sh was done in 775f381a9e
("stage-1: add bcache support"). It seems somewhat plausible that
no new users have appeared since then and we can take this opportunity
to back out of this change without much fear of regressions.
If there _are_ regressions, they should be in the form of build time
errors, not runtime (boot), due to how the udev rule output is checked
for invalid path references. So low risk, IMHO.
* An alternative approach could be to copy the /bin/sh substitute rule
over to the non-initrd udev rules implementation in NixOS, but I think
this way is better:
- The rules file comes with a working path out of the box.
- We can use more precise pattern matching when modifying the udev
rules for the initrd.
Done by setting PATH and PYTHONPATH appropriately.
Adds the following patches:
* One that removes hardcodes to /sbin, /usr/bin, etc.
from gluster, so that programs like `lvm` and `xfs_info` can be
called at runtime; see https://bugzilla.redhat.com/show_bug.cgi?id=1450546.
* One that fixes unsubstituted autoconf macros in paths (a problem
in the 3.10 release); see https://bugzilla.redhat.com/show_bug.cgi?id=1450588.
* One that removes uses of the `find_library()` Python function that does
not behave as expected in Python < 3.6 (and would not behave correctly
even on 3.6 in nixpkgs due to #25763);
see https://bugzilla.redhat.com/show_bug.cgi?id=1450593.
I think that all of these patches should be upstreamed.
Also adds tests to check that none of the Python based utilities
throw import errors, calling `--help` or equivalent on them.
This is because the source tarball available on
https://download.gluster.org/pub/gluster/glusterfs/3.10/3.10.1/glusterfs-3.10.1.tar.gz
has different contents than the v3.10.1 tag;
for example, it lacks the file `xlators/features/ganesha/src/Makefile.am`,
which the tag has.
This is because GluserFS's release process removes some unused files.
This made impossible to apply patches written by or for upstream, as those
are written against what's in upstream's git.
As a nice side effect, we no longer have to hardcode the "3.10" in the
`3.10/${version}` part of the URL.
