Re: Building on Windows from scratch - datediff problem found
On 23/01/2014 22:47, John Ralls wrote: On Jan 23, 2014, at 7:23 AM, Gary Bilkus wrote: I've done some more testing and found a problem with libofx and possibly aqbanking ( which I don't use ). It's easy enough to work round, but I'm not sure what the correct fix should be on Windows The problem is that there's a known issue with datediff and mingw, due to differences in the versions of MSCVRT used by mingw as to whether they expect time_t to be 32 or 64 bits. If you know you are compiling for Windows 7, you can get it to work by explicitly setting the windows version appropriately, so that it will use the 64 bit versions of time_t ( even on 32 bit windows ). However, I suspect that compiling that way won't work on XP which doesn't have the 64 bit version. There is lots of noise about this issue in various forums, but no clear answer what the 'correct' solution is if you want to be able to compile on any supported Windows version, and ideally get a package which works everywhere as well. Anyone have any good ideas how to fix this cleanly. The least bad solution might be simply to replace datediff with a simple subtraction, which should work for the cases it's used in libofx. But other dependencies might be different. Are you perhaps thinking of “difftime”? DATEDIFF is a SQL function; difftime is a standard C Library function. This bug seems to be what you’re talking about: http://sourceforge.net/p/mingw/bugs/2152/, linked from http://mingw.5.n7.nabble.com/difftime-broken-td33080.html. So Microsoft has invented a new twist on the 32-bit vs. 64-bit time_t problem by having both and a rather graceless way of determining which to use. In GnuCash we finessed that by not using the standard C functions because we need 64-bit time_t regardless of whether the platform provides it. We’re currently using Glib functions that don’t use it; soon we’ll switch to Boost functions that don’t use it either. It looks to from the bug that you have it backwards: You need to coerce 32-bit time_t because MinGW is screwed up and only calls difftime32() regardless of the size of time_t. That means that you can’t build GnuCash with MinGW wsl>=4.0 on a Win64 system until they fix the bug, or unless AQBanking and LibOFX work around the bug by replacing difftime with a subtraction-and-cast. Regards, John Ralls Sorry, yes, it is of course difftime I meant. I suppose I have it backwards if you mean that I want to use 64 bits but the latest mingw insists on 32 bits. In fact, it will call difftime64 if you define _WIN32_WINNT to _WIN32_WINNT_WIN7 inside _mingw.h . But while that proves the diagnosis, it clearly isn't the right patch! This is not just a 'build on 64 bits' problem by the way. The problem exists even on 32 bit Windows XP using a VM I created to test on, although what's going wrong under the hood may be subtly different, and the WIN32_WINNT_WIN7 kludge obviously doesn't work! . So it's worth fixing if the aim is to have a 'just works' build of gnucash for Windows on mingw. The safest fix is probably to define a 'sufficiently good' difftime and patch both libofx and aqbanking with that version as part of the install.sh process. But before I do that, I'd like to know that the gnucash maintainers would accept it, and if not, what alternative would be OK for eventual inclusion in geerts update. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New Scheme report - trying to load from home dir
On Wednesday 22 January 2014 22:22:49 Yawar Amin wrote: > Hi, > > I'm following the instructions at > http://wiki.gnucash.org/wiki/Custom_Reports#Load_the_report_from_a_us > er_account and trying to prototype a new Scheme report. However I > don't see it anywhere on the Reports menu. There are no indicators as > to what happened, why it failed to show up. > > I have a %HOME%\.gnucash\config.user file with: > > (load > "C:\\Users\\Yawar\\Documents\\coding\\gc-decl-reports\\gc-decl-report > s.scm") > I think the path loading code has issues with windows drive letter specifications. It won't recognize this as an absolute path. You could try the mingw notation instead: /c/Users/Yawar/Documents/... Or as you already discovered a relative path to $HOME/.gnucash. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r23751 - gnucash/trunk/src/business/business-gnome - Posting an invoice doesn't un-hide some widgets.
On Friday 24 January 2014 08:36:22 Mike Evans wrote: > Author: mikee > Date: 2014-01-24 08:36:22 -0500 (Fri, 24 Jan 2014) > New Revision: 23751 > Trac: http://svn.gnucash.org/trac/changeset/23751 > > Modified: >gnucash/trunk/src/business/business-gnome/dialog-invoice.c > Log: > Posting an invoice doesn't un-hide some widgets. > > Make "Date Posted" and "Posted Account" widgets visible when an > invoice is posted. > Cool! This issue has been bugging me for years, but I never got around to search for the cause. Thanks for tracking it down and fixing it! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - datediff problem found
On Jan 24, 2014, at 12:33 AM, Gary Bilkus wrote: > On 23/01/2014 22:47, John Ralls wrote: >> On Jan 23, 2014, at 7:23 AM, Gary Bilkus wrote: >> >>> I've done some more testing and found a problem with libofx and possibly >>> aqbanking ( which I don't use ). It's easy enough to work round, but I'm >>> not sure what the correct fix should be on Windows >>> >>> The problem is that there's a known issue with datediff and mingw, due to >>> differences in the versions of MSCVRT used by mingw as to whether they >>> expect time_t to be 32 or 64 bits. >>> >>> If you know you are compiling for Windows 7, you can get it to work by >>> explicitly setting the windows version appropriately, so that it will use >>> the 64 bit versions of time_t ( even on 32 bit windows ). However, I >>> suspect that compiling that way won't work on XP which doesn't have the 64 >>> bit version. >>> >>> There is lots of noise about this issue in various forums, but no clear >>> answer what the 'correct' solution is if you want to be able to compile on >>> any supported Windows version, and ideally get a package which works >>> everywhere as well. >>> >>> Anyone have any good ideas how to fix this cleanly. The least bad solution >>> might be simply to replace datediff with a simple subtraction, which should >>> work for the cases it's used in libofx. But other dependencies might be >>> different. >>> >> Are you perhaps thinking of “difftime”? DATEDIFF is a SQL function; difftime >> is a standard C Library function. >> >> This bug seems to be what you’re talking about: >> http://sourceforge.net/p/mingw/bugs/2152/, linked from >> http://mingw.5.n7.nabble.com/difftime-broken-td33080.html. >> >> So Microsoft has invented a new twist on the 32-bit vs. 64-bit time_t >> problem by having both and a rather graceless way of determining which to >> use. In GnuCash we finessed that by not using the standard C functions >> because we need 64-bit time_t regardless of whether the platform provides >> it. We’re currently using Glib functions that don’t use it; soon we’ll >> switch to Boost functions that don’t use it either. >> >> It looks to from the bug that you have it backwards: You need to coerce >> 32-bit time_t because MinGW is screwed up and only calls difftime32() >> regardless of the size of time_t. That means that you can’t build GnuCash >> with MinGW wsl>=4.0 on a Win64 system until they fix the bug, or unless >> AQBanking and LibOFX work around the bug by replacing difftime with a >> subtraction-and-cast. >> >> Regards, >> John Ralls >> > Sorry, yes, it is of course difftime I meant. > I suppose I have it backwards if you mean that I want to use 64 bits but the > latest mingw insists on 32 bits. In fact, it will call difftime64 if you > define _WIN32_WINNT to _WIN32_WINNT_WIN7 inside _mingw.h . But while that > proves the diagnosis, it clearly isn't the right patch! > > This is not just a 'build on 64 bits' problem by the way. The problem exists > even on 32 bit Windows XP using a VM I created to test on, although what's > going wrong under the hood may be subtly different, and the WIN32_WINNT_WIN7 > kludge obviously doesn't work! . So it's worth fixing if the aim is to have a > 'just works' build of gnucash for Windows on mingw. > > The safest fix is probably to define a 'sufficiently good' difftime and patch > both libofx and aqbanking with that version as part of the install.sh > process. But before I do that, I'd like to know that the gnucash maintainers > would accept it, and if not, what alternative would be OK for eventual > inclusion in geerts update. You should update the MinGW bug report with the info about _WIN32_WINNT_WIN7; that's more breakage that might affect their solution. What happens on XP? Since there's only 32-bit time_t in that ancient msvcrt, there should be only difftime and no difftime32 and difftime64 to choose from. Yes, of course it's worth fixing, ideally by the upstream developers, ideally by not using POSIX time functions. Stuffing a patch in GnuCash's windows build scripts is highly un-ideal, but might be necessary. Bear in mind that those build scripts primary purpose is to build GnuCash for distribution. Since I don't think that we want to create separate 32 and 64 bit packages, we need them to build for 32-bit by default since a 64-bit Windows will happily run a 32-bit app but not the other way around. If we're going to script for 64-bit builds as well then it should be enabled by an optional variable in custom.sh. As for "sufficiently good" difftime, I imagine that the least-bad version would be what M$ should have done in the first place, which is if (sizeof(time_t) == 8) return (double)((int64)time1 - (int64)time2); else return (double)((int32)time1 - (int32)time2); That could be done as a macro and inserted into one of the header files in each library. Regards, John Ralls ___
Re: New Scheme report - trying to load from home dir
On Jan 23, 2014, at 8:57 PM, Yawar Amin wrote: > > The problem before that was that GnuCash is prepending '$HOME\.gnucash\' to > the beginning of the load function string argument. So if I specified > '$HOME\Documents\coding\gc-decl-reports\gc-decl-reports.scm' the load > function would actually try to load > '$HOME\.gnucash\$HOME\Documents\coding\gc-decl-reports\gc-decl-reports.scm'. > Whoops. I don't know if this behaviour is specific to Windows or to 2.6 > versus 2.4. Actually it's prepending $GNC_DOT_DIR, which defaults to $HOME/.gnucash. It does that because that's where it expects custom reports to be, and it does it on all platforms. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New Scheme report - trying to load from home dir
Yawar Amin writes: > On 2014-01-23 13:50, Derek Atkins wrote: >> [...] >> This is an invalid menu path. You are telling it, literally, >> "gnc:menuname-utility", which isn't a valid menu path name. Try >> changing it to: >> >> 'menu-path (list gnc:menuname-utility) > > Thanks Derek. I could've sworn that '(x) == (list x). But turns out > not the case, for Guile at least. No, '(x) == (list "x") ... in all versions of Scheme, not just guile. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New Scheme report - trying to load from home dir
On 2014-01-24 11:33, Derek Atkins wrote: > [...] > No, '(x) == (list "x") ... in all versions of Scheme, not just guile. Thanks Derek. I just did this: guile> (define x 1) guile> '(x) (x) guile> (list x) (1) So that's the difference I guess Regards, Yawar signature.asc Description: OpenPGP digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: building from svn
Hi, alessandro basili writes: > Hi there, > > I'm having issues in building from source: > >> configure: error: Library requirements (glib->2.0 >= 2.28 gio-2.0 >> >= 2.25 gthread-2.0 gobject-2 gmodule-2) not met; consider >> adjusting the PKG_CONFIG_PATH environment variable if your >> libraries are in a nonstandard prefix so pkg-config can find them. > > here's my apt-cache show for the gir1.0-glib-2.0 package which should > contain all of the required libraries: Umm.. what is "gir1.0-glib-2.0"? GnuCash needs "glib", not "gir". > Does anyone knows how to build on debian/squeeze? > Thanks, Start with: apt-get build-dep gnucash Then add anything else that's necessary for the newer version. > Al -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - datediff problem found
John Ralls writes: > if (sizeof(time_t) == 8) > return (double)((int64)time1 - (int64)time2); > else > return (double)((int32)time1 - (int32)time2); This code probably wouldn't compile cleanly. It would complain about casting to different sizes. Even though theoretically the compiler should be able to optimize the branch by noticing that it is always true or always false, it will still complain about the unused branch. (I know this from personal experience). > That could be done as a macro and inserted into one of the header > files in each library. > > Regards, > John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New Scheme report - trying to load from home dir
On 2014-01-24 10:40, John Ralls wrote: > [...] > Actually it's prepending $GNC_DOT_DIR, which defaults to $HOME/.gnucash. It > does that because that's where it expects custom reports to be, and it does > it on all platforms. Thanks John. I've simplified the report loading instructions a bit in the Custom Reports wiki page using this info. signature.asc Description: OpenPGP digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[MAINT] GnuCash server migration Feb 1-2
Hi, I'm going to migrate 'code.gnucash.org' (our "everything" server) to a new VM/OS install on the weekend of February 1-2. I expect this move will take several hours, during which time all access to email, email archives, wiki, svn, trac, IRC logs, etc will all be unavailable. This is necessary because the services must be disabled on the old server to move the data behind them to the new OS. Most of the data has already been migrated so the majority of time is going to be testing and running "update" scripts to make sure everything is back up correctly. I don't have an exact Time of Day yet when I expect this migration to take place. When I have a better idea I'll send email. That choice will probably happen last-minute due to family obligations. I'll be in the #gnucash IRC chat room during the migration and will be able to provide status updates there. A few notes (mostly for developers): 1) The new server will not have Subversion access. If it turns out that we *need* read-only svn access I can turn it on, but I'm hoping we don't need it. SVN has also been blocked for writing; again, if we need to change that we can work on it. 2) As of this server migration we'll also be migrating to GIT as our primary push repository. Make sure you're familiar. You should be able to at least "pull" from the git service on the current "code". 3) I'm taking the opportunity to refresh the SSH keys on the server. This means all developers with commit access will need to manually refresh your ~/.ssh/known_hosts file, otherwise ssh will complain. The new host has two new keys with the following fingerprints: 256 a0:35:2a:54:ce:df:1b:b8:82:5e:11:83:73:50:47:55 (ECDSA) 2048 20:23:3d:df:f3:13:34:c1:32:ca:11:77:24:21:98:01 (RSA) Let me know if you have any questions! Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: building from svn
On Jan 24, 2014, at 9:02 AM, Derek Atkins wrote: > Hi, > > alessandro basili writes: > >> Hi there, >> >> I'm having issues in building from source: >> >>> configure: error: Library requirements (glib->2.0 >= 2.28 gio-2.0 = 2.25 gthread-2.0 gobject-2 gmodule-2) not met; consider >>> adjusting the PKG_CONFIG_PATH environment variable if your >>> libraries are in a nonstandard prefix so pkg-config can find them. >> >> here's my apt-cache show for the gir1.0-glib-2.0 package which should >> contain all of the required libraries: > > Umm.. what is "gir1.0-glib-2.0"? GnuCash needs "glib", not "gir". It's the gobject introspection type library for GLib. He's apparently under the mistaken impression that it proves that he's installed the correct packages. Alessandro, it doesn't demonstrate anything. In general you get that error because you have only the libraries installed and not the headers. Most distros, Debian included, separate the headers and package config files into a different package ending in -dev or -devel. You need those packages. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] Ship src/report/jqplot/jquery.js in the tarball
Hi,
Please find attached a patch that fixes Debian bug #736434
(http://bugs.debian.org/736434)
The gnucash tarball contains jquery.min.js, which is a minified version
of jquery.js; but the latter is not included in the tarball. The
minified version is not the preferred form of modification, so it is not
source code. The solution implemented by the patch is simply to add
jquery.js to the tarball.
Thanks for considering (if possible for the 2.6.1 release!),
--
.''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
`- GPG Key: 4096R/381A7594
From 4d213d6f88b10732653719c1a25b53d269bbb519 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Villemot?=
Date: Fri, 24 Jan 2014 20:39:06 +
Subject: [PATCH] Ship src/report/jqplot/jquery.js in the tarball.
The tarball contains jquery.min.js, which is a minified version of jquery.js.
The minified version is not the preferred form of modification, so it is not
source code, and jquery.js must also be included.
---
src/report/jqplot/Makefile.am | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/report/jqplot/Makefile.am b/src/report/jqplot/Makefile.am
index fde1ce8..584af39 100644
--- a/src/report/jqplot/Makefile.am
+++ b/src/report/jqplot/Makefile.am
@@ -31,5 +31,6 @@ gncjqplot_DATA = \
plugins/jqplot.pointLabels.js \
plugins/jqplot.trendline.js
-
-EXTRA_DIST = ${gncjqplot_DATA}
+# Also ship jquery.js since it is the source for jquery.min.js
+EXTRA_DIST = ${gncjqplot_DATA} \
+ jquery.js
--
1.8.5.3
signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: building from svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi John, On 1/24/2014 8:35 PM, John Ralls wrote: [] >> Umm.. what is "gir1.0-glib-2.0"? GnuCash needs "glib", not >> "gir". > > It's the gobject introspection type library for GLib. He's > apparently under the mistaken impression that it proves that he's > installed the correct packages. I presume that what Derek suggested should supply the necessary packages in order to build it from source. Main issue is that on Debian/Squeeze I have gnucash 2.2.9 and the 'build-dep' does not cover the dependencies on glib and the like (tried and failed). > Alessandro, it doesn't demonstrate anything. In general you get > that error because you have only the libraries installed and not > the headers. Most distros, Debian included, separate the headers > and package config files into a different package ending in -dev > or -devel. You need those packages. It seems I have also gliblib2.0-dev installed but it does not help... - -- Alessandro Basili PGP Fingerprint DCBE 430E E93D 808B 45E6 7B8A F68D A276 565C 4450 PGP Public Key available at keys.gnugp.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS4vFbAAoJEPaNonZWXERQia0IAK5lSK8oWy+KjeB8XdKlUOx8 ggRPwd+ob+y2pVUH7IKFtJ02qlmpIPoi5+OqfDAiJPs2k+Vip6rIyBoc95wGZhZc EHsY2ZApUy1A1AZgQUoaFJ3lyE2Y+PeBi6pTki3CDTvh/EpRPy0BRRTMlcQmLL7u aBhrWSVGnAIJ+uyhm5MnmL73IYsy0E4lhdpH/kani3RQOaZOBjSTZZ96mVNLtpie WUdBdv6ydvQBKsuvZvWBBU8B4/WjkPMSIoG2BgwJsTIJjTVj5Ln40Wp+GHYfTFn3 hG2/3q+rUsArlduonRlIOh0Z2RuLHdpoH4vagnQa8X36fd9daYj8c9s0s5hFKQ4= =TYqb -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: building from svn
Hi, On Fri, January 24, 2014 6:03 pm, alessandro basili wrote: > I presume that what Derek suggested should supply the necessary > packages in order to build it from source. Main issue is that on > Debian/Squeeze I have gnucash 2.2.9 and the 'build-dep' does not cover > the dependencies on glib and the like (tried and failed). > >> Alessandro, it doesn't demonstrate anything. In general you get >> that error because you have only the libraries installed and not >> the headers. Most distros, Debian included, separate the headers >> and package config files into a different package ending in -dev >> or -devel. You need those packages. > > It seems I have also gliblib2.0-dev installed but it does not help... If your system is so old that it only supplies 2.2.9 then it is probably so old that it does not provide the necessary dependencies to build 2.6. You will need to upgrade your system. In the interim you can *TRY* building the 2.4 branch, but I suspect you wont be able to build 2.6. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] Ship src/report/jqplot/jquery.js in the tarball
On Jan 24, 2014, at 12:46 PM, Sébastien Villemot wrote: > Hi, > > Please find attached a patch that fixes Debian bug #736434 > (http://bugs.debian.org/736434) > > The gnucash tarball contains jquery.min.js, which is a minified version > of jquery.js; but the latter is not included in the tarball. The > minified version is not the preferred form of modification, so it is not > source code. The solution implemented by the patch is simply to add > jquery.js to the tarball. > > Thanks for considering (if possible for the 2.6.1 release!), r23760. Thanks. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: building from svn
On Jan 24, 2014, at 3:03 PM, alessandro basili wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi John, > > On 1/24/2014 8:35 PM, John Ralls wrote: > [] >>> Umm.. what is "gir1.0-glib-2.0"? GnuCash needs "glib", not >>> "gir". >> >> It's the gobject introspection type library for GLib. He's >> apparently under the mistaken impression that it proves that he's >> installed the correct packages. > > I presume that what Derek suggested should supply the necessary > packages in order to build it from source. Main issue is that on > Debian/Squeeze I have gnucash 2.2.9 and the 'build-dep' does not cover > the dependencies on glib and the like (tried and failed). > >> Alessandro, it doesn't demonstrate anything. In general you get >> that error because you have only the libraries installed and not >> the headers. Most distros, Debian included, separate the headers >> and package config files into a different package ending in -dev >> or -devel. You need those packages. > > It seems I have also gliblib2.0-dev installed but it does not help... Then you can run pkg-config —-modversion glib-2.0 and it will tell you what version you have. But Derek’s right, Squeeze is oldstable, and doesn’t have new enough Glib, Gtk, or (IIRC) Guile to build 2.6. You can either build a new Gtk stack and Guile from source, try to find .debs that will apply on Squeeze, or upgrade to Wheezy or Jessie if you want to build 2.6. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
