GnuCash uses Gnome's GSettings to store user preferences. This was not
working before. wrapGAppsHook is introduced to solve this problem, but
it must be tweaked to not wrap GnuCash's cli utilities for fetching
financial quotes. Those are now deliberately wrapped with their Perl
library dependencies.
The existing code is refactored in an attempt to clarify which
dependencies are needed and why.
I wouldn't be able to say exactly why this is the case, but with the
flags that enableDebugging adds to the gnucash derivation, the build
fails. The patch added fixes the warning that causes the build to fail
and makes enableDebugging gnucash work.
The glibc patch is no longer needed, as it's included in 4.6.
This release also includes 888676eb31,
which allows building gnucash as (enableDebugging gnucash) using nix.
The GNU Cash package clearly *wants* to be able to use the libdbi
backends, since it pulls them in as dependencies. However, you can only
open xml formatted GNU cash files.
The CMake scripts hard-code the DVD path to be basically
<PATH_OF_LIBDBI>/dbd. However GNU Cash does check the environment
variable GNC_DBD_DIR, so I set that environment variable in the wrapper
script.
With this change, you should be able to e.g. "Save As" in the sqlite
format.
Fixes issue #57445
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>
* substitute(): --subst-var was silently coercing to "" if the variable does not exist.
* libffi: simplify using `checkInputs`
* pythonPackges.hypothesis, pythonPackages.pytest: simpify dependency cycle fix
* utillinux: 2.32 -> 2.32.1
https://lkml.org/lkml/2018/7/16/532
* busybox: 1.29.0 -> 1.29.1
* bind: 9.12.1-P2 -> 9.12.2
https://ftp.isc.org/isc/bind9/9.12.2/RELEASE-NOTES-bind-9.12.2.html
* curl: 7.60.0 -> 7.61.0
* gvfs: make tests run, but disable
* ilmbase: disable tests on i686. Spooky!
* mdds: fix tests
* git: disable checks as tests are run in installcheck
* ruby: disable tests
* libcommuni: disable checks as tests are run in installcheck
* librdf: make tests run, but disable
* neon, neon_0_29: make tests run, but disable
* pciutils: 3.6.0 -> 3.6.1
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/pciutils/versions.
* mesa: more include fixes
mostly from void-linux (thanks!)
* npth: 1.5 -> 1.6
minor bump
* boost167: Add lockfree next_prior patch
* stdenv: cleanup darwin bootstrapping
Also gets rid of the full python and some of it's dependencies in the
stdenv build closure.
* Revert "pciutils: use standardized equivalent for canonicalize_file_name"
This reverts commit f8db20fb3a.
Patching should no longer be needed with 3.6.1.
* binutils-wrapper: Try to avoid adding unnecessary -L flags
(cherry picked from commit f3758258b8895508475caf83e92bfb236a27ceb9)
Signed-off-by: Domen Kožar <domen@dev.si>
* libffi: don't check on darwin
libffi usages in stdenv broken darwin. We need to disable doCheck for that case.
* "rm $out/share/icons/hicolor/icon-theme.cache" -> hicolor-icon-theme setup-hook
* python.pkgs.pytest: setupHook to prevent creation of .pytest-cache folder, fixes#40273
When `py.test` was run with a folder as argument, it would not only
search for tests in that folder, but also create a .pytest-cache folder.
Not only is this state we don't want, but it was also causing
collisions.
* parity-ui: fix after merge
* python.pkgs.pytest-flake8: disable test, fix build
* Revert "meson: 0.46.1 -> 0.47.0"
With meson 0.47.0 (or 0.47.1, or git)
things are very wrong re:rpath handling
resulting in at best missing libs but
even corrupt binaries :(.
When we run patchelf it masks the problem
by removing obviously busted paths.
Which is probably why this wasn't noticed immediately.
Unfortunately the binary already
has a long series of paths scribbled
in a space intended for a much smaller string;
in my testing it was something like
lengths were 67 with 300+ written to it.
I think we've reported the relevant issues upstream,
but unfortunately it appears our patches
are what introduces the overwrite/corruption
(by no longer being correct in what they assume)
This doesn't look so bad to fix but it's
not something I can spend more time on
at the moment.
--
Interestingly the overwritten string data
(because it is scribbled past the bounds)
remains in the binary and is why we're suddenly
seeing unexpected references in various builds
-- notably this is is the reason we're
seeing the "extra-utils" breakage
that entirely crippled NixOS on master
(and probably on staging before?).
Fixes#43650.
This reverts commit 305ac4dade.
(cherry picked from commit 273d68eff8f7b6cd4ebed3718e5078a0f43cb55d)
Signed-off-by: Domen Kožar <domen@dev.si>
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/gnucash/versions.
These checks were done:
- built on NixOS
- /nix/store/29l8ziil4znyr07dm7f8ki893bqfzqm5-gnucash-3.2/bin/gnc-fq-check passed the binary check.
- /nix/store/29l8ziil4znyr07dm7f8ki893bqfzqm5-gnucash-3.2/bin/gnc-fq-helper passed the binary check.
- /nix/store/29l8ziil4znyr07dm7f8ki893bqfzqm5-gnucash-3.2/bin/gnc-fq-dump passed the binary check.
- /nix/store/29l8ziil4znyr07dm7f8ki893bqfzqm5-gnucash-3.2/bin/gnucash passed the binary check.
- /nix/store/29l8ziil4znyr07dm7f8ki893bqfzqm5-gnucash-3.2/bin/.gnucash-wrapped passed the binary check.
- 5 of 5 passed binary check by having a zero exit code.
- 0 of 5 passed binary check by having the new version present in output.
- found 3.2 with grep in /nix/store/29l8ziil4znyr07dm7f8ki893bqfzqm5-gnucash-3.2
- directory tree listing: https://gist.github.com/c6f09b837c81684d4febbc1c369ae53d
- du listing: https://gist.github.com/f9960cc6c0b43d70986bb1b51c109a68
Patch taken from the upstream repository, should be fixed in next
released version.
This did require moving the invocation of `patchShebangs` from
`patchPhase` to `postpatch`, but this seems consistent with at least
some other packages.
