Arch Linux User Repository

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.

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:

• WITH_PYTHON=ON
• COMPILE_GSCHEMAS=OFF

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)

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.

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.

@jebrosen

It does work using the additional cmake flag

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

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

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

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?

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)

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