Re: Source directory restructuring

[Sumit Bhardwaj]

John and Geert,

As I remembered, I am still having problem with cmake. I have pasted the
error message below. Is this a known problem? If not, will it be better to
wait for Geert's restructuring and then try to fix it? For reference,
autotools work.

Thanks,
Sumit

​[3/942] cd /home/bhardwajs/ac/devel/gnucash/po && /usr/bin/cmake ...e -D
PO_DIR=/home/bhardwajs/ac/devel/gnucash/po -P check-po.cmake
FAILED: po/CMakeFiles/check-po
cd /home/bhardwajs/ac/devel/gnucash/po && /usr/bin/cmake -D
INTLTOOL_UPDATE=/usr/bin/intltool-update -D PO_DIR=/home/bhardwajs/ac/deve
l/gnucash/po -P check-po.cmake
The usage of POTFILES.ignore is deprecated. Please consider moving the
content of this file to POTFILES.skip.
The following files contain translations and are currently not in use.
Please
consider adding these to the POTFILES.in file, located in the po/ directory

If some of these files are left out on purpose then please add them to
POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
of left out files has been written in the current directory.
Please report to gnucash-devel@gnucash.org
CMake Error at check-po.cmake:22 (MESSAGE):
 POTFILES.in is missing files.  See 'missing' in
 /home/bhardwajs/ac/devel/gnucash/po


On Wed, Aug 9, 2017 at 11:54 AM, John Ralls 
wrote:

>
> > On Aug 9, 2017, at 9:16 PM, Alex Aycinena 
> wrote:
> >
> >>
> >>
> >>
> >> -- Forwarded message --
> >> From: John Ralls 
> >> To: Sumit Bhardwaj 
> >> Cc: gnucash-devel 
> >> Bcc:
> >> Date: Tue, 8 Aug 2017 20:01:44 +0300
> >> Subject: Re: Source directory restructuring
> >>
> >>> On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj 
> wrote:
> >>>
> >>> John,
> >>>
> >>> If the plan is to dump autotools, should we ask also devs to make sure
> >> that
> >>> they can build using cmake? I have had problems in the past and
> >> therefore,
> >>> I have stuck with autotools so far.
> >>>
> >>> What are the things we want to confirm in the cmake toolchain?
> >>> cmake
> >>> cmake install
> >>> cmake check
> >>>
> >>> Anything else?
> >> Sumit,
> >>
> >> No. cmake  srcdir && make && make check && make install or (quite
> a
> >> bit faster) cmake -G Ninja  srcdir && ninja check && ninja
> install.
> >>
> >> You generally need to at least specify a -DCMAKE_INSTALL_PREFIX unless
> you
> >> want GnuCash installed in /usr/local which back in the day was a
> reasonable
> >> thing to do but isn't really anymore. Because of normal linker behavior
> and
> >> GnuCash's overuse of loadable modules you also need to uninstall before
> >> building, especially when changing branches. The incantation for that in
> >> cmake is xargs rm < install_manifest.txt.
> >>
> >> Geert and I use the cmake+ninja build system most of the time and the
> >> Windows automated build has been using it for just over a year. I think
> >> that it's well tested. There's a known problem that the dependency graph
> >> doesn't capture everything especially for some of the scheme modules so
> >> allowing too much parallelism (setting -j too high on a many-core
> machine)
> >> will try to build some things before their dependencies are done. That's
> >> not a blocker to dropping autotools. The only loose end at present is
> that
> >> there are still a few rough edges in the dist target that need to be
> >> cleaned up.
> >>
> >> Regards,
> >> John Ralls
> >>
> >>
> >
> > I switched to cmake and ninja a few months ago when I had trouble
> building
> > with autotools and I thought everything was working fine. I pushed a
> commit
> > and found that some changes to unit tests that I had made didn't work and
> > so I accidently broke the build. I had assumed that ninja check, which
> had
> > been successful, had run the unit tests and hadn't bother to check for
> > sure. I was finally able to get autotools to work by not including the
> > debug arg in configure and so was able to run the unit test, fix it and
> > push the fix. I have been using autotools since to make sure the tests
> are
> > all run.
> >
> > My question is whether cmake now runs all the same unit tests.
> >
>
> Alex,
>
> IIRC you flagged those tests as not run and Geert fixed them. Do you
> remember what they were?
>
> I think that cmake and autotools are running the same set of tests but I
> haven't done a test-by-test comparison in a while.
>
> Regards,
> John Ralls
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Python bindings and Gtk3

[Mike Alexander]

> On Aug 9, 2017, at 1:49 PM, John Ralls  wrote:
> 
> Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?
> 

It’s version 3.22.

> Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?
> 
> You can try fiddling with the tab-label styling in ~/.config/gtk-3.0/gtk.css. 
> There's some guidance in 
> https://developer.gnome.org/gtk3/unstable/theming.html 
> .

I’ll take a look at that.

Mike
 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[John Ralls]

> On Aug 9, 2017, at 9:16 PM, Alex Aycinena  wrote:
> 
>> 
>> 
>> 
>> -- Forwarded message --
>> From: John Ralls 
>> To: Sumit Bhardwaj 
>> Cc: gnucash-devel 
>> Bcc:
>> Date: Tue, 8 Aug 2017 20:01:44 +0300
>> Subject: Re: Source directory restructuring
>> 
>>> On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj  wrote:
>>> 
>>> John,
>>> 
>>> If the plan is to dump autotools, should we ask also devs to make sure
>> that
>>> they can build using cmake? I have had problems in the past and
>> therefore,
>>> I have stuck with autotools so far.
>>> 
>>> What are the things we want to confirm in the cmake toolchain?
>>> cmake
>>> cmake install
>>> cmake check
>>> 
>>> Anything else?
>> Sumit,
>> 
>> No. cmake  srcdir && make && make check && make install or (quite a
>> bit faster) cmake -G Ninja  srcdir && ninja check && ninja install.
>> 
>> You generally need to at least specify a -DCMAKE_INSTALL_PREFIX unless you
>> want GnuCash installed in /usr/local which back in the day was a reasonable
>> thing to do but isn't really anymore. Because of normal linker behavior and
>> GnuCash's overuse of loadable modules you also need to uninstall before
>> building, especially when changing branches. The incantation for that in
>> cmake is xargs rm < install_manifest.txt.
>> 
>> Geert and I use the cmake+ninja build system most of the time and the
>> Windows automated build has been using it for just over a year. I think
>> that it's well tested. There's a known problem that the dependency graph
>> doesn't capture everything especially for some of the scheme modules so
>> allowing too much parallelism (setting -j too high on a many-core machine)
>> will try to build some things before their dependencies are done. That's
>> not a blocker to dropping autotools. The only loose end at present is that
>> there are still a few rough edges in the dist target that need to be
>> cleaned up.
>> 
>> Regards,
>> John Ralls
>> 
>> 
> 
> I switched to cmake and ninja a few months ago when I had trouble building
> with autotools and I thought everything was working fine. I pushed a commit
> and found that some changes to unit tests that I had made didn't work and
> so I accidently broke the build. I had assumed that ninja check, which had
> been successful, had run the unit tests and hadn't bother to check for
> sure. I was finally able to get autotools to work by not including the
> debug arg in configure and so was able to run the unit test, fix it and
> push the fix. I have been using autotools since to make sure the tests are
> all run.
> 
> My question is whether cmake now runs all the same unit tests.
> 

Alex,

IIRC you flagged those tests as not run and Geert fixed them. Do you remember 
what they were?

I think that cmake and autotools are running the same set of tests but I 
haven't done a test-by-test comparison in a while.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[Alex Aycinena]

>
>
>
> -- Forwarded message --
> From: John Ralls 
> To: Sumit Bhardwaj 
> Cc: gnucash-devel 
> Bcc:
> Date: Tue, 8 Aug 2017 20:01:44 +0300
> Subject: Re: Source directory restructuring
>
> > On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj  wrote:
> >
> > John,
> >
> > If the plan is to dump autotools, should we ask also devs to make sure
> that
> > they can build using cmake? I have had problems in the past and
> therefore,
> > I have stuck with autotools so far.
> >
> > What are the things we want to confirm in the cmake toolchain?
> > cmake
> > cmake install
> > cmake check
> >
> > Anything else?
> Sumit,
>
> No. cmake  srcdir && make && make check && make install or (quite a
> bit faster) cmake -G Ninja  srcdir && ninja check && ninja install.
>
> You generally need to at least specify a -DCMAKE_INSTALL_PREFIX unless you
> want GnuCash installed in /usr/local which back in the day was a reasonable
> thing to do but isn't really anymore. Because of normal linker behavior and
> GnuCash's overuse of loadable modules you also need to uninstall before
> building, especially when changing branches. The incantation for that in
> cmake is xargs rm < install_manifest.txt.
>
> Geert and I use the cmake+ninja build system most of the time and the
> Windows automated build has been using it for just over a year. I think
> that it's well tested. There's a known problem that the dependency graph
> doesn't capture everything especially for some of the scheme modules so
> allowing too much parallelism (setting -j too high on a many-core machine)
> will try to build some things before their dependencies are done. That's
> not a blocker to dropping autotools. The only loose end at present is that
> there are still a few rough edges in the dist target that need to be
> cleaned up.
>
> Regards,
> John Ralls
>
>

I switched to cmake and ninja a few months ago when I had trouble building
with autotools and I thought everything was working fine. I pushed a commit
and found that some changes to unit tests that I had made didn't work and
so I accidently broke the build. I had assumed that ninja check, which had
been successful, had run the unit tests and hadn't bother to check for
sure. I was finally able to get autotools to work by not including the
debug arg in configure and so was able to run the unit test, fix it and
push the fix. I have been using autotools since to make sure the tests are
all run.

My question is whether cmake now runs all the same unit tests.

Regards,

Alex
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[John Ralls]

> On Aug 9, 2017, at 8:02 PM, Geert Janssens  wrote:
> 
> On woensdag 9 augustus 2017 18:51:52 CEST Geert Janssens wrote:
>>> Geert and I use the cmake+ninja build system most of the time and the
>>> Windows automated build has been using it for just over a year. I think
>>> that it's well tested. There's a known problem that the dependency graph
>>> doesn't capture everything especially for some of the scheme modules so
>>> allowing too much parallelism (setting -j too high on a many-core machine)
>>> will try to build some things before their dependencies are done. That's
>>> not a blocker to dropping autotools. The only loose end at present is that
>>> there are still a few rough edges in the dist target that need to be
>>> cleaned up.
>> 
>> Which dist target rough edges are you referring to here ?
>> 
>> I know there is the issue I can't add Makefile.in files to the dist tarball
>> (because Rob's dist rules prevent my cmake version from running the
>> necessary commands). Other than that the dist tarball generated via both
>> build systems are identical on my system after I ironed out a few minor
>> issues last month. Since we're right now discussing dropping autotools,
>> this very issue becomes moot.
>> 
>> Do you know other ones ?
> 
> Oh, and there is this little detail called Travis... Perhaps I should first 
> test whether it can switch to cmake or not.

I did when I was testing it but now I've forgotten. Having the tarball have 
both systems configs and makefiles and so on was certainly one of them, and 
you're right that it's moot when we drop autotools.

I'm sure that Travis can do cmake, but not sure that it can do a new enough 
cmake: We need at least 3.0 and 3.2 or later is preferred. ISTR that Travis has 
only 2.8.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Python bindings and Gtk3

[John Ralls]

> On Aug 9, 2017, at 7:28 AM, Mike Alexander  wrote:
> 
>> On Aug 9, 2017, at 12:21 AM, Mike Alexander > > wrote:
>> 
>>> On Aug 8, 2017, at 10:23 AM, John Ralls >> > wrote:
>>> 
>>> I don't know if the MacPorts X-build uses the CoreText or FontConfig 
>>> backend for Pango, but if it uses CoreText it might be your problem.
>> 
>> I don’t know either.  I see that Pango’s configure looks for (and finds) 
>> fontconfig, but then says "checking which cairo font backends could be 
>> used... quartz freetype”.  I suspect it is using fontconfig.  I am using a 
>> Retina display, but the text in the tabs seems like it’s normal size.  There 
>> is a lot of blank space around the text that makes the tab bigger.  In fact 
>> the text itself is smaller in the Gtk3 version.  Here are a couple of 
>> screenshots.
> 
> 
> I guess attachments aren’t allowed, I should have known.  The screenshots are 
> at 
> 
> https://www.dropbox.com/s/9ge32ydfc95fum8/Gtk2%20tabs.png?dl=0 
>  (Gtk2)
> and
> https://www.dropbox.com/s/c650pqyjbyl1zvn/Gtk3%20tabs.png?dl=0 
>  (Gtk3)

Hmm, looks like both whitespace and font are larger. What version of Gtk+-3?

You can try fiddling with the tab-label styling in ~/.config/gtk-3.0/gtk.css. 
There's some guidance in https://developer.gnome.org/gtk3/unstable/theming.html 
.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Testing attachments. Please ignore

[Derek Atkins]

Hi,
You should see a small attachment of the IHTFP logo attached to this email.
No need to respond; I'll see the email myself.
Just ensuring that actual "attachments" are not blocked (they shouldn't me).
Note that *INLINE* attachments still fail.  But actual attachments like
this should work.

Thanks, and sorry to fill your inbox.

-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: Source directory restructuring

[Geert Janssens]

On woensdag 9 augustus 2017 18:51:52 CEST Geert Janssens wrote:
> > Geert and I use the cmake+ninja build system most of the time and the
> > Windows automated build has been using it for just over a year. I think
> > that it's well tested. There's a known problem that the dependency graph
> > doesn't capture everything especially for some of the scheme modules so
> > allowing too much parallelism (setting -j too high on a many-core machine)
> > will try to build some things before their dependencies are done. That's
> > not a blocker to dropping autotools. The only loose end at present is that
> > there are still a few rough edges in the dist target that need to be
> > cleaned up.
> 
> Which dist target rough edges are you referring to here ?
> 
> I know there is the issue I can't add Makefile.in files to the dist tarball
> (because Rob's dist rules prevent my cmake version from running the
> necessary commands). Other than that the dist tarball generated via both
> build systems are identical on my system after I ironed out a few minor
> issues last month. Since we're right now discussing dropping autotools,
> this very issue becomes moot.
> 
> Do you know other ones ?

Oh, and there is this little detail called Travis... Perhaps I should first 
test whether it can switch to cmake or not.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[Geert Janssens]

On dinsdag 8 augustus 2017 19:01:44 CEST John Ralls wrote:
> > On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj  wrote:
> > 
> > John,
> > 
> > If the plan is to dump autotools, should we ask also devs to make sure
> > that
> > they can build using cmake? I have had problems in the past and therefore,
> > I have stuck with autotools so far.
> > 
> > What are the things we want to confirm in the cmake toolchain?
> > cmake
> > cmake install
> > cmake check
> > 
> > Anything else?
> 
> Sumit,
> 
> No. cmake  srcdir && make && make check && make install or (quite a
> bit faster) cmake -G Ninja  srcdir && ninja check && ninja install.
> 
> You generally need to at least specify a -DCMAKE_INSTALL_PREFIX unless you
> want GnuCash installed in /usr/local which back in the day was a reasonable
> thing to do but isn't really anymore. Because of normal linker behavior and
> GnuCash's overuse of loadable modules you also need to uninstall before
> building, especially when changing branches. The incantation for that in
> cmake is xargs rm < install_manifest.txt.
> 
> Geert and I use the cmake+ninja build system most of the time and the
> Windows automated build has been using it for just over a year. I think
> that it's well tested. There's a known problem that the dependency graph
> doesn't capture everything especially for some of the scheme modules so
> allowing too much parallelism (setting -j too high on a many-core machine)
> will try to build some things before their dependencies are done. That's
> not a blocker to dropping autotools. The only loose end at present is that
> there are still a few rough edges in the dist target that need to be
> cleaned up.
 
Which dist target rough edges are you referring to here ?

I know there is the issue I can't add Makefile.in files to the dist tarball 
(because Rob's dist rules prevent my cmake version from running the necessary 
commands). Other than that the dist tarball generated via both build systems 
are identical on my system after I ironed out a few minor issues last month. 
Since we're right now discussing dropping autotools, this very issue becomes 
moot.

Do you know other ones ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Redundant infrastructure

[Jon Daley]

On Wed, 9 Aug 2017, Derek Atkins wrote:

All the solutions I know about are for multiple instances in the same
data center.  I have no idea how to do it in a globally distributed
manner.


Failover can be setup via DNS, to ping/check a host and then swap IPs if 
the first host doesn't respond, and theb you can decide what you want to 
do when the first host comes back up, probably auto-switching back is 
harder to setup due to changes that happen on the second server while thw 
first is down.


dnsmadeeasy.com has the cheapest (and actually best) service for this (as 
well as other things - I've used them commercially for ten years or so, 
and had almost no issues.


But, for gnucash, I'd think you don't really need a high availability 
solution like this.  I'd expect good backups to be good enough, 
particularly if it is a virtual server that can be spun back up from the 
backup.  But, even real hardware is probably good enough - there probably 
aren't that many urgent requests that come that can't wait a day or two. 
And DNS could always be manually changed in the worst case.


All that said, if you want to go that route, I have experience with this 
and can spend time or at least recommend software options.



--
Jon Daley
http://jon.limedaley.com
~~
We are trying to get unemployment to go up and
  I think we're going to succeed.
-- Ronald Reagan
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Python bindings and Gtk3

[Derek Atkins]

Mike,

Mike Alexander  writes:

> I guess attachments aren’t allowed, I should have known.  The
> screenshots are at

*attachments* are allowed

*INLINE* images are not.

-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: Redundant infrastructure

[Derek Atkins]

Geert Janssens  writes:

>> > Of course this doesn't help with the service redundancy.  If there IS a
>> > local issue (hardware, power, network) then the service will go offline
>> > until it can be repaired.  Granted, I have a large-scale UPS and a
>> > natural-gas-powered backup generator so there is no longer a local power
>> > outage issue.  However HW and ISP issues are a bit more out of my
>> > control.
>> 
>> I could provide a mirror site for redundancy with my shared hosting (at
>> Dreamhost), if that would help. Perhaps just a "hot backup" that could be
>> enabled if you did lose connectivity or so far a while, rather than working
>> up a more complicated High Availability system. I assume a brief outage
>> (eg, hour?) of the bug tracker would not be critical to life.
>
> That's very kind. For the record I have two redundant servers myself that can 
> be configured to run as backups/mirrors/whatever of the gnucash 
> infrastructure.
>
> This is something I'd like to pick up some time later, when gnucash 2.7/.28 
> are taking less of my time. Those are top priority now as several distros are 
> starting to drop gnucash due to the webkit obsolescence.

Linas and I have talked about it as well.

The problem, of course, is that it's easy to set up load-balancing
redundancy (with two separate systems in separate locations) both
serving requests..  But this really only works for static (or
quazi-static) content.

I'm not sure how we would accomplish that with the Wiki or even GIT,
where there's a read-write backend.  For something backed by a database
you would need to run multiple instances of MySQL with concurrency
behind them.  I'm not enough of a MySQL guru to set that up.

Similarly, I'm not sure how we would replicate the Mailman instances.
We could certainly set up a redundant MX record, but SMTP already holds
mail for ~5 days so should handle relatively short outages.

The other option is to have a "hot spare" running, which is taking
updates from the primary but isn't serving any content.  But I don't
know how to handle an "automated cutover" in the case of a failure.

All the solutions I know about are for multiple instances in the same
data center.  I have no idea how to do it in a globally distributed
manner.

> Geert

-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: about that restructuring, and .scm files

[Christopher Lam]

Hi John

Thank you I'll do this when I return to broadband; being away from home and
using LTE means productivity high but bandwidth low.

gnctimeperiod-utilities.scm is from Doug Doughty and is a huge list of
various parameters for date selection for his reports. I wouldn't have a
clue how to code in C++.

I'll create PR in 10 days' time and hopefully someone will test a build.

C

On 9 August 2017 at 01:21, John Ralls  wrote:

>
> > On Aug 8, 2017, at 6:02 PM, Christopher Lam 
> wrote:
> >
> > Regarding adding new reports
> >
> > Apologies if this is the worst time to ask, but I believe I have fixed
> some
> > scheme reports which can be plugged in the following folders. I've tested
> > in Windows and Ubuntu and they seem to work well. It'll belong in Report
> >
> > Collected Reports, and would make a nice addition to 2.8 release.
> >
> > - scm/gnucash/* will hold gnctimeperiod-utilities.scm and
> > report-other-menu.scm
> > - scm/gnucash/report/standard-reports/* will hold new reports
> >
> > Unfortunately I cannot identify the proper source for the scm/gnucash/*
> > folder - it seems to accumulate files from src/engine, src/scm... I guess
> > src/scm is the right one? I don't know how to build from source to test.
>
>
> Chris,
>
> No, it's a good time to ask.
>
> scm/gnucash collects all of the guile binding code from the various
> modules. I don't know what "timeperiod-utilities" is supposed to be, but it
> sounds like it should be an extension of src/engine/gnc-date.cpp. We want
> to use the same date code throughout GnuCash so whatever you need in
> timeperiod-utilities should be written in C++ and should wrap
> boost::date_time to hide the implementation (so that we can easily switch
> to another implementation if e.g. the C++ committee adds something to the
> standard library or we decide that ICU provides a better fit) and then
> provide Guile bindings via SWIG to support your report changes.
>
> It would be a good idea to get a PR up so that we can give you more
> detailed guidance.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel