Package Details: gnucash-git 3.7.r132.g9661a77f3-1

Git Clone URL: (read-only, click to copy)
Package Base: gnucash-git
Description: A personal and small-business financial-accounting application - GIT version
Upstream URL:
Licenses: GPL
Conflicts: gnucash, gnucash-devel, gnucash-gtk3-git, gnucash-latest, gnucash-python, gnucash-xbt
Provides: gnucash
Submitter: not_anonymous
Maintainer: not_anonymous (jebrosen)
Last Packager: jebrosen
Votes: 10
Popularity: 0.000006
First Submitted: 2015-02-13 14:09
Last Updated: 2019-10-16 02:42

Latest Comments

1 2 3 4 5 Next › Last »

jebrosen commented on 2019-10-16 02:38

Thanks. I remember some of those are changes I hoped gnucash would implement, and it looks like they have. I switched to ledger myself at the start of this year and have not been following GnuCash development, so I forgot about them. Honestly I am mildly surprised that this PKGBUILD has worked for a year and a half without changes, minor dependency differences notwithstanding.

I will update the deps and cmake flags to match what's in community (which looks about the same as what you listed). Please let me know if something still looks off.

waschtl commented on 2019-10-15 14:47

TL/DR: remove dependency on libgnomecanvas and add cmake flags WITH_PYTHON=ON and COMPILE_GSCHEMAS=OFF. Additional steps are possible for further cleanup.

In order to reproduce my issue, I needed a clean ArchLinux installation (which I created with pacstrap). And there I was able to remind myself what gave me the impression I had:

The dependency on libgnomecanvas caused an error right away, which basically made me think that the PKGBUILD was using outdated dependencies and possibly also an outdated build procedure (since that had also changed not too long ago). I now see from your comments here that you have updated the build procedure, even though the outdated dependency remains.

After removing the dependency on libgnomecanvas, the build completed successfully.

I would like to make some additional points, though:

The official package sets a couple of cmake flags, which this package does not. This may make this package unusable as a drop-in replacement for some users:


Here are also a couple of minor points that make it just a little more difficult to see what actually happens in the build process:

  • CMAKE_INSTALL_LIBEXECDIR does not appear to get evaluated (it has no effect)
  • WITH_OFX=ON is already the default value
  • WITH_AQBANKING=ON is already the default value

And finally, some of the dependencies are overly broad and will pull in packages a user does not need and may not want:

  • libdbi-drivers: needed in makedepends, but not in depends. It should be in optdepends, too. It is possible to run gnucash without an SQL backend.
  • libdbi: needed in depends (instead of libdbi-drivers)
  • slib: not needed (use guile instead)
  • guile: needed in depends (instead of slib)
  • gtest: is pulled in by gmock
  • intltool: not needed since 2018-02-27
  • libmariadbclient: has been renamed to mariadb-libs
  • mariadblibs: needed in makedepends (instead of libmariadbclient)
  • sqlite3: not needed (in favor of libdbi-drivers)

jebrosen commented on 2019-09-28 00:49

It works for me (currently 3.7+66+g1be9bfbf0) - the only patch missing in this PKGBUILD compared to community/gnucash is present upstream. What problems are you encountering?

As a side node, libgnomecanvas is no longer needed for a while now and can be removed.

waschtl commented on 2019-09-27 19:47

I don't believe that this package will compile with the current git version. Have a look at the comment to my out-of-date flag for a working PKGBUILD.

RemoteAdmin commented on 2018-04-21 06:01


It does work using the additional cmake flag

jebrosen commented on 2018-04-20 23:48

RemoteAdmin: gnucash in [community] has a cmake flag -DHAVE_GWEN_GTK3=ON Does adding it resolve the problem for you?

RemoteAdmin commented on 2018-04-20 05:07

The latest build leads to a 'conflicting files' at installation

error: failed to commit transaction (conflicting files)
/usr/lib/ exists in both 'gwenhywfar' and 'gnucash-git'
Errors occurred, no packages were upgraded.

eschwartz commented on 2018-02-16 04:04

Please report this as a bug to pacman-dev or the bugtracker, because we must be incompetent or something.

hooks that "sometimes" don't work would be sort of like pacman that "sometimes" doesn't work -- a sign that something is seriously screwed up.

If I actually believed you, then I would still say that using a post_install script as a workaround for the fact that pacman hooks are majorly broken is wrong, and you should, again, report this to pacman-dev or the bugtracker.


Does it bother you that these supposedly broken hooks don't work for repo packages that have no install script? But you didn't file a bazillion bugs for all those likewise broken packages...


Who do you think I trust? Myself, a Trusted User and pacman developer, or you, who has made an unsubstantiated claim with some seriously questionable background logic?

not_anonymous commented on 2018-02-16 00:24

And sometimes the "hooks" do NOT work. Been there, done that...and I have the tee-shirt too. i.e. For now, I feel the hooks should remain. They will cause NO problems. (Trust me ...grin)

eschwartz commented on 2018-02-16 00:09

The install script should be removed altogether, as everything it does or did is handled by hooks, specifically

/usr/share/libalpm/hooks/glib-compile-schemas.hook ==> glib2

/usr/share/libalpm/hooks/gtk-update-icon-cache.hook ==> gtk-update-icon-cache

/usr/share/libalpm/hooks/update-desktop-database.hook ==> desktop-file-utils