First I tried to fix the build like this:
> This fixes the build of the wordgrinder package by disabling the build
> of "xwordgrinder", the non-curses frontend of wordgrinder.
>
> For re-enabling the build, this patch shall be reverted and then go on
> from there.
>
> I opted for disabling the x frontend of this program because the whole
> purpose of this is to use a curses writing program (at least for me).
> It seems that hacking around the new build system in nixpkgs is a
> non-trivial task and I wanted to get this package out of the door as
> fast as possible because I already delayed the fix by a few days (or is
> it weeks already), so this is the simple fix.
>
> If someone wants to have the X frontend again, I can invest more time at
> some point.
But then the almighty aszlig came around and told me how to do it right. So here
we go, with a patch from me that is acutally from aszlig (see #60122).
This fixes the build.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Signed-off-by: aszlig <aszlig@nix.build>
Fixes: 6b2bd330fa ("wordgrinder: Fix sha256 hash")
Fixes: 19a3abc1b8 ("wordgrinder: 0.7.1 -> 0.7.2")
Merges: https://github.com/NixOS/nixpkgs/pull/60122
Cc: @devhell
The hash used for fetchFromGitHub was on the archive itself, however
fetchFromGitHub is actually a wrapper of fetchzip:
hash mismatch in fixed-output derivation '...-source':
wanted: sha256:1zqx3p9l22njni44ads3fyw3xh6807wmb5k1x2glg61z81cwc6sf
got: sha256:08lnq5wmspfqdjmqm15gizcq0xr7mg4h62qhvwj63v0sd6ks1cal
When using nix-prefetch-url without the --unpack argument, I get:
1zqx3p9l22njni44ads3fyw3xh6807wmb5k1x2glg61z81cwc6sf
And with the --unpack argument:
08lnq5wmspfqdjmqm15gizcq0xr7mg4h62qhvwj63v0sd6ks1cal
Just to be 100% sure the contents are the same, I also diffed the
contents of the former tarball with the outputs of the unpacked dir and
they're the same.
I didn't actually test the package (which doesn't build right now
anyway), but now at least the source checksum is fixed :-)
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthiasbeyer
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
I'm baaaaack!
This patch reverts my patch where I removed myself as maintainer because
of my traveling. I'm back now and I want to maintain these packages
again.
This reverts commit ce1c1e3093.
Incorporate wrapGAppsHook so that all gnumeric binaries are wrapped,
following the convention used by many gnome applications.
This addresses two issues:
1. The packaged ssconvert, ssdiff, ssgrep, and ssindex executables
in bin are not currently wrapped so some expected environment
variables including XDG_DATA_DIRS and GIO_EXTRA_MODULES are not
set. The result is many warnings on stderr when running these
commands, e.g.
==================================================================
CRITICAL **:...go_conf_add_monitor: assertion 'node || key' failed
CRITICAL **:...go_conf_get_node: assertion 'parent || key' failed
WARNING **:...unknown GOConfMonitor id.
==================================================================
2. None of the binaries, including gnumeric, currently wrap the
environment variable GDK_PIXBUF_MODULE_FILE. This can cause
segfaults if an incompatible GDK_PIXBUF_MODULE_FILE is already set
in the environment (e.g. by plasma5). This could be encountered
running a nixos pre-19.03 gnumeric binary from a nixos 18.09 KDE
session.
Poppler was upgraded in [0] and therefore the build broke, as
poppler/goo/gtypes.h was moved into poppler/goo/gfile.h [1].
The patch is intended to be broght upstream and then can be reverted.
[0] 7757e43fcb
[1] ef3ef702bc
To make updating large attribute sets faster, the update scripts
are now run in parallel.
Please note the following changes in semantics:
- The string passed to updateScript needs to be a path to an executable file.
- The updateScript can also be a list: the tail elements will then be passed
to the head as command line arguments.
A few things changed:
- no need for stdenv.hostPlatform == stdenv.buildPlatform conditional - this is already done in make-derivation
- put xvfb_run in installCheckInputs
Thanks to @symphorien for this work, which apart from the update itself
includes a few more fixes and cleanups.
I've tested building and running the upgraded Paperwork and while I
haven't done extensive testing on every little feature it seems to work
so far.
The changes also include an addition to fetchFromGitLab, which allows to
specify a group.
Merges: #46487
* libreoffice-still: -> 6.0.6.2
* (newer than our current 'fresh!')
* libreoffice-fresh: -> 6.1.0.3
* 6.1.1(.1) is currently pre-release, FWIW
* Use normal gcc, not gcc5
* dropping 'glibc' from buildInputs fixed this (?)
* remove many fixes/touchups/workarounds/hacks
* hopefully everything still works for everyone
* disable online update since that seems unlikely to work anyway
* fix autogen/configure invocations
* disable libnumbertext in 6.1.x since not packaged
* drop 'touch solenv/inc/target.mk' as unclear what it was for
and doesn't seem to be currently needed
* cleanup link gen a bit[1]
* split checks to check phase
[1]
primary motivation was to stop creating links like:
'libreoffice-6.0.5.2/src/-libxslt-1.1.32.tar.gz' -> '/nix/store/503v5hmhm430bld0h078gacmkniwdllr-libxslt-1.1.32.tar.gz'
'libreoffice-6.0.5.2/src/libxslt-1.1.32.tar.gz' -> '/nix/store/503v5hmhm430bld0h078gacmkniwdllr-libxslt-1.1.32.tar.gz'
This is mostly accomplished by simply using the 'md5name' field
which the python script kindly generates for us
(including the use of non-md5 if md5 is not set or empty).
* 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 273d68eff8)
Signed-off-by: Domen Kožar <domen@dev.si>
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!
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/grisbi/versions.
These checks were done:
- built on NixOS
- Warning: no invocation of /nix/store/d57ny55jq154x7iv786w0c7hxsddnvf7-grisbi-1.0.4/bin/grisbi had a zero exit code or showed the expected version
- Warning: no invocation of /nix/store/d57ny55jq154x7iv786w0c7hxsddnvf7-grisbi-1.0.4/bin/.grisbi-wrapped had a zero exit code or showed the expected version
- 0 of 2 passed binary check by having a zero exit code.
- 0 of 2 passed binary check by having the new version present in output.
- found 1.0.4 with grep in /nix/store/d57ny55jq154x7iv786w0c7hxsddnvf7-grisbi-1.0.4
- directory tree listing: https://gist.github.com/88cf58691f673a3bb235fbe5a74e830e
- du listing: https://gist.github.com/56e8df132720715c41cd5f30253080d8
Since 772eef9168 Boost no longer has
Python support enabled by default, so depending on whether Ledger has
Python support built in we also use either Boost with Python support or
without.
Tested building with and without Python support and both builds now
succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @the-kenny, @jwiegley
It's a really small fix that even could have been done via sed, but I'm
using the upstream patch instead so that once a new upstream release
comes along we don't forget to drop the patch.
The patch is from the upstream commit at:
https://cgit.kde.org/kmymoney.git/commit/?id=e5198a902996b27bf9abde0ad24af82d55ab5dc1
Signed-off-by: aszlig <aszlig@nix.build>
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
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
1. For some reason libreoffice-still was still referencing the Fresh
expression.
2. Moved gdb from buildInputs to nativeBuildInputs.
3. Minor update for both branches.
In particular, this contains Firefox-related and libgcrypt updates.
Other larger rebuilds would apparently need lots of time to catch up
on Hydra, due to nontrivial rebuilds in other branches than staging.
Lots of packages are missing versions in their name. This adds them
where appropriate. These were found with this command:
$ nix-env -qa -f. | grep -v '\-[0-9A-Za-z.-_+]*$' | grep -v '^hook$'
See issue #41007.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/skrooge/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/l83qij463yvk1nqxahdcm9amfnp7zdm8-skrooge-2.13.0/bin/skroogeconvert -h’ got 0 exit code
- ran ‘/nix/store/l83qij463yvk1nqxahdcm9amfnp7zdm8-skrooge-2.13.0/bin/skroogeconvert --help’ got 0 exit code
- found 2.13.0 with grep in /nix/store/l83qij463yvk1nqxahdcm9amfnp7zdm8-skrooge-2.13.0
- directory tree listing: https://gist.github.com/699ec87fffb73399c86ad11632ed9b17
This adds KMyMoney, a finance manager for KDE plus a few required
dependencies.
I ran the upstream test suite as well as the following manual tests:
* Basic startup
* Completing the wizard
* Add some test transactions
* GPG encryption
* Generation of charts and reports
* Rough check whether OFX integration lists supported financial
institutions.
* Small check of AqBanking implementation, whether accounts and users
can be configured, but didn't test actual connectivity with a
financial institution.
* Check of Weboob integration with a test PayPal backend, however also
just with a dummy account and without actually connecting to PayPal.
On top of that, the application already is being used by the person
requesting me to package this, so I'd guess it works well enough.
I'm merging this without the review from @ttuegel because it only adds
packages and doesn't change anything fundamental about the KDE
ecosystem.
The only change here is to add C++ support to "mpir", where the
maintainer (@7c6f434c) has approved the change.
I tried to use -DENABLE_SQLCIPHER and also passed the right directories
to the Qt 5 source of the QSQLiteDriver but CMake then failed to run
qt4_automoc, by which I'd imply that SQLCipher is not maintained
anymore (after all KMyMoney using qgpgme as well, which doesn't require
sources).
Another odd thing is that CMake reports that the weboob plugin is
disabled, but after inspecting it turns out that the reporting is just
wrong. This is already fixed upstream but not yet released in
KDE/kmymoney@8b086cf921.
In addition of running the upstream test suite I have manually tested a
few things in a VM by using the following Nix expression:
(import <nixpkgs/nixos> {
configuration = { pkgs, ... }: {
environment.systemPackages = with pkgs; [
kmymoney aqbanking gwenhywfar libchipcard python2Packages.weboob
kgpg
];
users.users.test.isNormalUser = true;
virtualisation.diskSize = 4096;
virtualisation.memorySize = 2048;
services.xserver = {
enable = true;
inherit ((import <nixpkgs/nixos> {}).config.services.xserver) layout;
displayManager.sddm.enable = true;
displayManager.sddm.autoLogin.enable = true;
displayManager.sddm.autoLogin.user = "test";
desktopManager.default = "plasma5";
desktopManager.plasma5.enable = true;
};
};
}).vm
The things I have tested in particular are:
* Basic startup
* Completing the wizard
* Add some test transactions
* GPG encryption
* Generation of charts and reports
* Rough check whether OFX integration lists supported financial
institutions.
* Small check of AqBanking implementation, whether accounts and users
can be configured, but didn't test actual connectivity with a
financial institution.
* Check of Weboob integration with a test PayPal backend, however also
just with a dummy account and without actually connecting to PayPal.
One of the upstream tests "reports-chart-test" seems to fail even though
generating charts and reports are working when testing manually. It also
seems that this is the case on other distributions, for example Gentoo
has disabled that test as well:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5169cec68fa6fd67841
Note that I didn't add myself as a maintainer because I'm not personally
using KMyMoney but just packaged it for someone else. I hope this is
useful for other people, so that maybe someday[TM] there will be a
proper maintainer.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
With this patch I remove myself as a maintainer for all packages I
currently maintain.
This is due the fact that I will be basically off the grid from May 2018
until early 2019, as I will be on a trip through north america.
I will revert this patch as soon as I'm back, as I plan to continue
contributing to nixpkgs then.
But as I cannot maintain anything during that time, I'd like to get this
patch merged.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0/bin/skroogeconvert -h` got 0 exit code
- ran `/nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0/bin/skroogeconvert --help` got 0 exit code
- ran `/nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0/bin/skroogeconvert -v` and found version 2.12.0
- ran `/nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0/bin/skroogeconvert --version` and found version 2.12.0
- ran `/nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0/bin/skroogeconvert -h` and found version 2.12.0
- ran `/nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0/bin/skroogeconvert --help` and found version 2.12.0
- found 2.12.0 with grep in /nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0
- found 2.12.0 in filename of file in /nix/store/yjdafzss769kl6jg9asxyalgy7a5xxz7-skrooge-2.12.0
