Package Details: gnucash-git 2.7.4-1

Git Clone URL: (read-only)
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: 9
Popularity: 3.306730
First Submitted: 2015-02-13 14:09
Last Updated: 2018-02-13 16:23

Latest Comments

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

jebrosen commented on 2018-02-13 16:28

I have pushed the update to use cmake since autotools was finally dropped in master. It would be good to know what stops working. I believe gnome-keyring / libsecret is still unsupported, but everything else about building and running GnuCash should work as well as or better than it did before.

RemoteAdmin commented on 2018-02-13 08:48

@jebrosen GnuCash 2.7.4 got merged today and, as you saw coming, broke everything.

jebrosen commented on 2018-02-10 00:20

GnuCash 2.7.4 has been released, but has not been merged into the git master branch upstream. I have prepared fixes to the PKGBUILD to support 2.7.4 when it does come and breaks everything, but I am not comfortable pointing to the unstable branch on git.

Until then, please do not flag this package out of date.

DonHugo commented on 2018-02-08 15:00

2.4.7 has been released:

jebrosen commented on 2018-01-28 22:10

@windy: Then I'd rather wait until 2.7.4 comes out and we have to switch to cmake anyway. I'll look into dropping the gconf stuff as well, but it seems to be unrelated to your original issue.

windy commented on 2018-01-28 21:51

For the locale issue, I commented a commit on GitHub and got the reply to drop autogen and also remove all gconf stuff from the PKGBUILD:

jebrosen commented on 2018-01-28 16:32

@windy: The locale issue you describe is almost certainly a bug in GnuCash. It looks like it might be fixed in the unstable branch.

@all: GnuCash has completely removed autotools support in the unstable branch, which will probably be merged into master around their next development release. When that happens gnucash-gtk3-git and gnucash-git will break; gnucash-git will be updated to use cmake (maybe after a few days delay) and gnucash-gtk3-git will be destroyed.

CMake will be mostly good for this package, as it makes a few hacks in the PKGBUILD unnecessary. Unfortunately, it still lacks libsecret/gnome-keyring support.

All comments