Re: [GNC-dev] GnuCash 3.3 builds on CentOS 7
Eric Wheeler (gnucash-de...@lists.ewheeler.net) said: > Hello all, > > For those interested, we have successfully built GnuCash on CentOS 7. > > 1. download gnucash 3.3: > > https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/g/gnucash-3.3-1.fc30.src.rpm > 2. yum install yum-utils epel-release > 3. yum-builddep gnucash-3.3-1.fc30.src.rpm > 4. yum install boost-devel libsoup-devel gsettings-desktop-schemas > 5. rpm -ivh gnucash-3.3-1.fc30.src.rpm > 6. Patch have_dst() in your local OS boost install: > /usr/include/boost/date_time/local_time/custom_time_zone.hpp > See this patch: https://www.boost.org/patches/1_54_0/002-date-time.patch > > 6. Add this just above '%cmake .' in the gnucash.spec. Note that > -D__STDC_FORMAT_MACROS=1 is important: > > %global optflags %{optflags} -Wno-parentheses -D__STDC_FORMAT_MACROS=1 > %define __cmake cmake3 > sed -i 's/1\.54\.0/1.53.0/g' CMakeLists.txt > %cmake . > > 7. rpmbuild -bb > > There might be other deps, perhaps I had them installed already. But it > works for me! > > (ps, This redhat bugzilla reports the boost bugfix request in case that is > useful: https://bugzilla.redhat.com/show_bug.cgi?id=1636817 ) Thanks for looking at this. I'd be nervous about changing the boost requirements and would prefer that it be fixed before building this for EPEL. But that's just me. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gtk3 + webkit
John Ralls (jra...@ceridwen.us) said: > Geert noted in IRC that > https://bugzilla.redhat.com/show_bug.cgi?id=1375812 indicates that we need > to lose the dependency on WebKit1 ASAP, as Fedora intends to drop it from > distribution in F27. As Geert notes, WebKit2 is Gtk3-only. Note, though, > that on the bug Bill Nottingham suggests that he might flatpack WebKitGtk1 > and request a waiver, and Catanzaro seems to receive that well enough. In terms of Fedora/EPEL - yes, I'll just bundle in webkitgtk as needed for 2.6.x, and maybe look at flatpak if I get the spare time to do so. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash-docs-2.6.12 404?
John Ralls (jra...@ceridwen.us) said: > > On Apr 19, 2016, at 5:48 PM, Bill Nottingham <nott...@splat.cc> wrote: > > > > Was the docs tarball pulled? It's not properly downloading from SF at the > > moment. > > > > Somebody complained about that on IRC yesterday too. The correct URL is > https://sourceforge.net/projects/gnucash/files/gnucash-docs/2.6.12/gnucash-docs-2.6.12.tar.gz/download > and the SH-256 is > 0e4a7338aee0c5ec50d46a9b5f243a08e82215f079a125d85fc95af823906d04. > > Where's the bad link? That is the bad link, at least when I try: [notting@nostromo: ~]$ wget https://sourceforge.net/projects/gnucash/files/gnucash-docs/2.6.12/gnucash-docs-2.6.12.tar.gz/download --2016-04-20 10:39:05-- https://sourceforge.net/projects/gnucash/files/gnucash-docs/2.6.12/gnucash-docs-2.6.12.tar.gz/download Resolving sourceforge.net (sourceforge.net)... 216.34.181.60 Connecting to sourceforge.net (sourceforge.net)|216.34.181.60|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2016-04-20 10:39:05 ERROR 404: Not Found. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash-docs-2.6.12 404?
Was the docs tarball pulled? It's not properly downloading from SF at the moment. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6.2 segfaulting (gtk/oxygen version apparently broken)
Christian Stimming (christ...@cstimming.de) said: Am Donnerstag, 6. März 2014, 12:33:58 schrieb John Ralls: On Mar 6, 2014, at 12:23 PM, Ted Creedon tcree...@easystreet.net wrote: Looks like the GTK/Oxygen theme is broken, changed thmres seems to work OK How do i report this, to who? I’d start with SuSE and let them figure out if it’s an upstream problem or if it’s their fault. Since Bill Nottingham reported that RedHat has also seen some issued with Oxygen, it will probably wind up there, but unless you want to get VCS checkouts of both Gtk and Oxygen and debug the actual problem it’s better to let the SuSE packagers deal with upstream. FTR: I'm also experiencing crashes recently due to oxygen theme/gtk, on Ubuntu 13.10 with gtk-2.24.20 with gtk2-engines-oxygen-1.3.4. Backtrace below. The crash happens when hovering over the toolbar, quite reproducibly (read: rather often - quite annoying). Just in case anyone is interested: Program received signal SIGSEGV, Segmentation fault. 0x764fc92a in IA__gtk_widget_queue_draw (widget=0xa65d290) at /build/buildd/gtk+2.0-2.24.20/gtk/gtkwidget.c:3772 (gdb) bt #0 0x764fc92a in IA__gtk_widget_queue_draw (widget=0xa65d290) at /build/buildd/gtk+2.0-2.24.20/gtk/gtkwidget.c:3772 #1 0x7fffe406616e in Oxygen::ToolBarStateData::delayedUpdate(void*) () from /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so #2 0x7fffe4066845 in Oxygen::ToolBarStateData::updateState(_GtkWidget*, bool, bool) () from /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so ... While different than the trace Ted reported, that seems to match the trace we've had reported for the Fedora builds in our bugzilla. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6.2 segfaulting
John Ralls (jra...@ceridwen.us) said: Yeah, I dunno what Oxygen::MenuStateData::menuItemIsActive is except that it doesn't have anything to do with GnuCash, Gtk+, or GLib. You need to explain your environment in detail and why we should support it, otherwise you're totally on your own. It's a port of the oxygen KDE theme to GTK2, used to make gtk/GNOME apps match KDE when running under KDE. And yes, we've seen some crash reports in Fedora when GnuCash is run with it, although not with that specific backtrace: https://bugzilla.redhat.com/show_bug.cgi?id=1039286 Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Releasing 2.4.11 ?
John Ralls (jra...@ceridwen.us) said: On Jul 10, 2012, at 1:58 PM, Geert Janssens wrote: On 10-07-12 10:23, John Ralls wrote: OK. Has anyone run distcheck to make sure that we have a clean tree? I'm not presently in a position to do that, but I will be on Friday (the 13th ;-) ). If everything's clean on Friday we'll have a release on Saturday. Regards, John Ralls I tried to run distcheck today, and fixed a problem in the account charts. That fix was already in trunk, but not backported yet. But now make distcheck fails for me during configure on gtkhtml3 (2.4 still defaults to gtkhtml3) on Fedora. Fedora ships with gtkhtml 4.2.3. I have installed both library and devel package, so I suspect this is a bug in Fedora. I'm afraid I don't have time to look into this further before I leave. Hopefully someone else can pick this up. No worries, I run distcheck on Debian Stable. The Fedora integrator can sort out his package. ;-) Speaking of, is it ready for integration now? I noticed the tarball hit SF, but not announced here or elsewhere. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] Fix tip-of-the-day with gcc-4.7
When making the text file tips-of-the-day, GnuCash expects 'gcc -E' to preserve at least one of the whitespace lines between entries. However, this relies on behavior of 'gcc -E' that isn't actually part of the spec, and is a historical accident. And it changed in gcc-4.7, such that all the whitespace is removed. Work around this by explicitly adding a newline in the sed expression. Bill diff -up gnucash-2.4.10/doc/Makefile.am.foo gnucash-2.4.10/doc/Makefile.am --- gnucash-2.4.10/doc/Makefile.am.foo 2012-06-21 15:49:01.849038350 -0400 +++ gnucash-2.4.10/doc/Makefile.am 2012-06-21 15:49:08.285038512 -0400 @@ -52,7 +52,7 @@ gnucash.1: gnucash.1.in Makefile tip_of_the_day.list: tip_of_the_day.list.in Makefile ${CC} -E -P -x c -D'N_(x)=x' -o $@.tmp $ cat -s $@.tmp | ${SED} -e 's/^ *//' \ - -e 's/ *$$//' \ + -e 's/ *$$/\n/' \ -e 's/* *[|] */|/' \ -e 's:@-GNUCASH_LATEST_STABLE_SERIES-@:${GNUCASH_LATEST_STABLE_SERIES}:g' $@ rm -f $@.tmp diff -up gnucash-2.4.10/doc/Makefile.in.foo gnucash-2.4.10/doc/Makefile.in --- gnucash-2.4.10/doc/Makefile.in.foo 2012-06-21 14:50:58.0 -0400 +++ gnucash-2.4.10/doc/Makefile.in 2012-06-21 15:28:54.743004680 -0400 @@ -882,7 +882,7 @@ gnucash.1: gnucash.1.in Makefile tip_of_the_day.list: tip_of_the_day.list.in Makefile ${CC} -E -P -x c -D'N_(x)=x' -o $@.tmp $ cat -s $@.tmp | ${SED} -e 's/^ *//' \ - -e 's/ *$$//' \ + -e 's/ *$$/\n/' \ -e 's/* *[|] */|/' \ -e 's:@-GNUCASH_LATEST_STABLE_SERIES-@:${GNUCASH_LATEST_STABLE_SERIES}:g' $@ rm -f $@.tmp ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] Assorted guile-related build fixes
Geert Janssens (janssens-ge...@telenet.be) said: On vrijdag 13 mei 2011, Bill Nottingham wrote: I was doing some testing with guile-2.0 and GnuCash, and encountered the need for the following fixes to make it build. (Note: it still doesn't *work*, but it at least builds for further testing.) Total changes: configure.ac| 14 -- src/import-export/aqbanking/Makefile.am |1 + src/plugins/bi_import/Makefile.am |1 + 3 files changed, 10 insertions(+), 6 deletions(-) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Bill, I just discovered this series of your patches in my mailbox, all covered with dust ;) I'm under the impression they never got applied, right ? AFAIK, yes, although I've only really checked on the 2.4 branch. Patch 2 is obsolete by now [1]. I have made some other changes in the source so aqbanking and bi_import are no longer dependent on guile. Patch 3 seems to make sense to me, I'll apply it shortly. And regarding patch 1, I'm a bit confused. While working on the bug mentioned below, Petr had written a patch very similar to your patch 2, yet it did seem to work without applying patch 1. So your patch series suggests GUILE_INCS has to be AC_SUBST before it can be included, but Petr's patch suggests otherwise. Is GUILE_INCS automatically substituted as part of the other macro's perhaps ? I'm not that well versed in the autotools magic, so I prefer to ask first. Hah, neither am I. But looking at it, GUILE_INCS is in most of the Makefile.am files, so having an explicit substitute of it looks right. (The problem I remember having is it not finding guile correctly in /usr/include/guile/2.0/... which is where our test guile-2.0 packages were putting it). Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] Assorted guile-related build fixes
I was doing some testing with guile-2.0 and GnuCash, and encountered the need for the following fixes to make it build. (Note: it still doesn't *work*, but it at least builds for further testing.) Total changes: configure.ac| 14 -- src/import-export/aqbanking/Makefile.am |1 + src/plugins/bi_import/Makefile.am |1 + 3 files changed, 10 insertions(+), 6 deletions(-) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH 1/3] Set GUILE_INCS as an output variable.
--- configure.ac |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 8a0f501..25a5dbf 100644 --- a/configure.ac +++ b/configure.ac @@ -388,6 +388,7 @@ if test x$saved_GUILE_INCS != x; then fi AS_SCRUB_INCLUDE(GUILE_INCS) +AC_SUBST(GUILE_INCS) AC_SUBST(GUILE_LIBS) AC_SUBST(GUILE) -- 1.7.5.1 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH 2/3] Add GUILE_INCS to CFLAGS where necessary.
--- src/import-export/aqbanking/Makefile.am |1 + src/plugins/bi_import/Makefile.am |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/import-export/aqbanking/Makefile.am b/src/import-export/aqbanking/Makefile.am index 82a0403..36764f9 100644 --- a/src/import-export/aqbanking/Makefile.am +++ b/src/import-export/aqbanking/Makefile.am @@ -64,6 +64,7 @@ AM_CFLAGS = \ ${GNOME_CFLAGS} \ ${GLADE_CFLAGS} \ ${GLIB_CFLAGS} \ + ${GUILE_CFLAGS} \ ${AQBANKING_CFLAGS} uidir = $(GNC_UI_DIR) diff --git a/src/plugins/bi_import/Makefile.am b/src/plugins/bi_import/Makefile.am index 9d02a6d..09411f1 100644 --- a/src/plugins/bi_import/Makefile.am +++ b/src/plugins/bi_import/Makefile.am @@ -51,6 +51,7 @@ AM_CFLAGS = \ -I${top_srcdir}/lib/libc \ ${GNOME_CFLAGS} \ ${GLADE_CFLAGS} \ + ${GUILE_CFLAGS} \ ${QOF_CFLAGS} \ ${GLIB_CFLAGS} -- 1.7.5.1 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH 3/3] Check for guile-2.0 as well as guile-1.8.
--- configure.ac | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index 25a5dbf..6d569e1 100644 --- a/configure.ac +++ b/configure.ac @@ -370,12 +370,13 @@ fi GUILE_LIBS= # Look up GUILE_CFLAGS and GUILE_LIBS, and version check -PKG_CHECK_MODULES(GUILE, [guile-1.8 = 1.8.5], , [AC_MSG_ERROR([ - - guile does not appear to be installed correctly, or is not in the - correct version range. Perhaps you have not installed the guile - development packages? Gnucash requires at least version 1.8.5 to build. -])]) +PKG_CHECK_MODULES(GUILE, [guile-1.8 = 1.8.5], , [ + PKG_CHECK_MODULES(GUILE, [guile-2.0 = 2.0.0], , [AC_MSG_ERROR([ +guile does not appear to be installed correctly, or is not in the +correct version range. Perhaps you have not installed the guile +development packages? Gnucash requires at least version 1.8.5 to build. + ])]) +]) # Look up GUILE executable AC_PATH_PROG(GUILE, guile) -- 1.7.5.1 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH 2/3] Add GUILE_INCS to CFLAGS where necessary.
Bill Nottingham (nott...@redhat.com) said: --- src/import-export/aqbanking/Makefile.am |1 + src/plugins/bi_import/Makefile.am |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/import-export/aqbanking/Makefile.am b/src/import-export/aqbanking/Makefile.am index 82a0403..36764f9 100644 --- a/src/import-export/aqbanking/Makefile.am +++ b/src/import-export/aqbanking/Makefile.am @@ -64,6 +64,7 @@ AM_CFLAGS = \ ${GNOME_CFLAGS} \ ${GLADE_CFLAGS} \ ${GLIB_CFLAGS} \ + ${GUILE_CFLAGS} \ ${AQBANKING_CFLAGS} So, reading this I see my commit message refers to GUILE_INCS, and the patch refers to GUILE_CFLAGS. These appear to be used somewhat interchangeably throughout the buildsystem; they evaluate the same in any case. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Future of Gnucash: Most productive platform (programming language and toolkit)?
John Ralls (jra...@ceridwen.us) said: 2. Gtk+-3.0 is supposed to be released next month. It removes a bunch of libraries which have been deprecated for several years upon which Gnucash at present depends. All code that depends on those libraries needs to get rewritten or we're not going to be in a bunch of distros by the end of 2011 ? Gtk-2 isn't going to be removed from things like Fedora or RHEL anytime sooon. Much like Qt3 has yet to go away, it's likely to live on for a while, even if it's not the 'default' version of the toolkit. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Future of Gnucash: Most productive platform (programming language and toolkit)?
John Ralls (jra...@ceridwen.us) said: On Dec 28, 2010, at 9:06 PM, Bill Nottingham wrote: John Ralls (jra...@ceridwen.us) said: 2. Gtk+-3.0 is supposed to be released next month. It removes a bunch of libraries which have been deprecated for several years upon which Gnucash at present depends. All code that depends on those libraries needs to get rewritten or we're not going to be in a bunch of distros by the end of 2011 ? Gtk-2 isn't going to be removed from things like Fedora or RHEL anytime sooon. Much like Qt3 has yet to go away, it's likely to live on for a while, even if it's not the 'default' version of the toolkit. WTF? I said exactly that _one_sentence_later_, suggesting that we'll need to have two branches to support both the aggressive and conservative distros. My point is that even the aggressive distributions are going to have gtk2 around... it's not going to disappear there. (If you want, you could compare GnuCash's life on GNOME 1.x, which lasted 4 years after the release of GNOME 2.0.) Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AW: gnucash upgrade from 2.2.9 to 2.3.14: AqBanking configfolderchanged
Jannick Asmus (jannick.n...@gmail.com) said: Thx. That is easy. Here the prompted result: C:\Program Files\gnucash-unstable\binaqbanking-cli updateconf Config for AqBanking 4 found, no update needed. Your configuration seems to be ok. I checked: no change. But I did some configs already to have HBCI run with 2.3.14. Perhaps AqB didn't like that and prefers the its config folder untouched. What I discovered that appeared to happen (not on OSX) is that the first time you run GnuCash compiled against the new aqbanking, it creates enough of a stub config that the migration won't run. You have to remove that stub, and *then* run 'aqbanking-cli updateconf'. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash upgrade from 2.2.9 to 2.3.14: AqBanking configfolderchanged
Martin Preuss (aquaman...@gmx.de) said: On Dienstag 17 August 2010, Bill Nottingham wrote: [...] What I discovered that appeared to happen (not on OSX) is that the first time you run GnuCash compiled against the new aqbanking, it creates enough of a stub config that the migration won't run. You have to remove that stub, and *then* run 'aqbanking-cli updateconf'. [...] Thats correct. The application is supposed to call the update/check function before the first call to AB_Banking_Init() to possibly update an old configuration. Something like the attached? (warning: completely untested other than 'it builds') Bill diff -up gnucash-2.3.13/src/import-export/aqbanking/gnc-ab-utils.c.foo gnucash-2.3.13/src/import-export/aqbanking/gnc-ab-utils.c --- gnucash-2.3.13/src/import-export/aqbanking/gnc-ab-utils.c.foo 2010-08-17 11:00:55.980535002 -0400 +++ gnucash-2.3.13/src/import-export/aqbanking/gnc-ab-utils.c 2010-08-17 11:08:54.822535006 -0400 @@ -134,6 +134,29 @@ gnc_AB_BANKING_new(void) api = AB_Banking_new(gnucash, NULL, 0); g_return_val_if_fail(api, NULL); +#ifdef AQBANKING_VERSION_4_PLUS +/* Check for config migration */ +if (AB_Banking_HasConf4(api, 0) != 0) +{ +if (AB_Banking_HasConf3(api, 0) == 0) +{ +g_message(gnc_AB_BANKING_new: importing aqbanking3 configuration\n); +if (AB_Banking_ImportConf3(api, 0) 0) +{ +g_message(gnc_AB_BANKING_new: unable to import aqbanking3 configuration\n); +} +} +else if (AB_Banking_HasConf2(api, 0) == 0) +{ +g_message(gnc_AB_BANKING_new: importing aqbanking2 configuration\n); +if (AB_Banking_ImportConf2(api, 0) 0) +{ +g_message(gnc_AB_BANKING_new: unable to import aqbanking2 configuration\n); +} +} +} +#endif /* AQBANKING_VERSION_4_PLUS */ + /* Init the API */ g_return_val_if_fail(AB_Banking_Init(api) == 0, NULL); ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Is there anything I should know to replace GnomeDruid with GtkAssistant?
Derek Atkins (warl...@mit.edu) said: - goffice for RHEL5 is missing (required) cairo support (introduced by me early 2010) This is a bigger issue that I don't think Bill could fix. Speaking as a package maintainer, I'm OK with keeping 2.2.x in EPEL for RHEL 5, and targeting EPEL for RHEL 6 with 2.4.x. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH 2.3.13] fix Latvian account trees
Otherwise they end up in the wrong place. Bill diff -up gnucash-2.3.13/accounts/lv_LV/Makefile.am.foo gnucash-2.3.13/accounts/lv_LV/Makefile.am --- gnucash-2.3.13/accounts/lv_LV/Makefile.am.foo 2010-06-03 14:33:44.429101189 -0400 +++ gnucash-2.3.13/accounts/lv_LV/Makefile.am 2010-06-03 14:33:27.314976349 -0400 @@ -1,5 +1,5 @@ -accountdir = ${GNC_ACCOUNTS_DIR}/C +accountdir = ${GNC_ACCOUNTS_DIR}/lv account_DATA = \ acctchrt_brokerage.gnucash-xea \ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r19220 - gnucash/trunk/accounts/lv_LV - fix Latvian account trees, patch by Bill Nottingham.
Christian Stimming (stimm...@tuhh.de) said: Am Thursday 03 June 2010 schrieb Geert Janssens: Author: gjanssens Date: 2010-06-03 15:33:37 -0400 (Thu, 03 Jun 2010) New Revision: 19220 Trac: http://svn.gnucash.org/trac/changeset/19220 Modified: gnucash/trunk/accounts/lv_LV/Makefile.am Log: fix Latvian account trees, patch by Bill Nottingham. Thanks for applying this patch! As this patch just barely missed the 2.3.13 tag, doesn't this mean that in the 2.3.13 tarball the C (=english) account templates are broken because they will be overwritten by the Latvian ones? Yes, that's how I noticed it. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] fix libdbi hardcoded driver directory usage
Geert Janssens (janssens-ge...@telenet.be) said: Obviously, it's easy to configure with --with-dbi-dbd-path pointing at the proper location for development and all is well. I just wonder if it's possible to rewrite configure in such a way that it always does the right thing. I mean is there some automatic parameter like $libdir but one that then points to the system wide lib directory instead of the one relative to prefix ? You could have the configury not set GNC_DBD_DIR *at all*, unless --with-dbi-dbd-path is passed. That's a more complex change to the environment, though. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] fix libdbi hardcoded driver directory usage
1) libdbi, in its default configuration, puts the driver directory in $libdir/dbd, not a hardcoded /usr/lib/dbd. Fix gnucash's configury to use the same. 2) If GNC_DBD_DIR is not set, fall back to the libdbi compiled-in default (whatever it may be) rather than a hardcoded value, as it's more likely to be correct. Bill diff -up gnucash-2.3.12/src/backend/dbi/gnc-backend-dbi.c.foo gnucash-2.3.12/src/backend/dbi/gnc-backend-dbi.c --- gnucash-2.3.12/src/backend/dbi/gnc-backend-dbi.c.foo2010-05-18 12:36:31.929812252 -0400 +++ gnucash-2.3.12/src/backend/dbi/gnc-backend-dbi.c2010-05-18 12:38:29.962687968 -0400 @@ -1007,7 +1007,6 @@ void gnc_module_init_backend_dbi(void) { QofBackendProvider *prov; -#define DEFAULT_DBD_DIR /usr/lib/dbd const gchar* driver_dir; int num_drivers; gboolean have_sqlite3_driver = FALSE; @@ -1019,8 +1018,7 @@ gnc_module_init_backend_dbi(void) driver_dir = g_getenv( GNC_DBD_DIR ); if ( driver_dir == NULL ) { -PWARN( GNC_DBD_DIR not set: using %s\n, DEFAULT_DBD_DIR ); -driver_dir = DEFAULT_DBD_DIR; +PWARN( GNC_DBD_DIR not set: using libdi built-in default\n); } num_drivers = dbi_initialize( driver_dir ); diff -up gnucash-2.3.12/configure.in.foo gnucash-2.3.12/configure.in --- gnucash-2.3.12/configure.in.foo 2010-05-18 12:51:28.688812527 -0400 +++ gnucash-2.3.12/configure.in 2010-05-18 12:52:28.985062367 -0400 @@ -582,9 +582,9 @@ then AC_CHECK_HEADERS(dbi/dbi.h) if test x$ac_cv_header_dbi_dbi_h != xno; then AC_ARG_WITH( dbi-dbd-dir, - [AS_HELP_STRING([--with-dbi-dbd-dir=PATH],[specify location of libdbi drivers @:@default=/usr/lib/dbd@:@])], + [AS_HELP_STRING([--with-dbi-dbd-dir=PATH],[specify location of libdbi drivers @:@default=${libdir}/dbd@:@])], GNC_DBD_DIR=$with_dbi_dbd_dir, - GNC_DBD_DIR=/usr/lib/dbd) + GNC_DBD_DIR=${libdir}/dbd) LIBDBI_LIBS=-ldbi DBI_DIR=dbi ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash 2.3.x/2.4 and Fedora
When we started developing for Fedora 13, I included gnucash-2.3.x, as I was pretty sure it would be finalized before Fedora 13 was, and I wanted to get some more testing on it. Well, that's not going to happen at this point (http://fedoraproject.org/wiki/Releases/13/Schedule), so I'm left with a couple of options: 1) Ship F-13 with 2.3.x, push 2.4.0 as an update as soon as it's out 2) Back F-13 down to 2.2.x (and beta users might need to back out their data, ouch), and then ship 2.4.0 as an update. Which would the GnuCash developers prefer? Sorry about causing this... Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Stabilizing 2.4.0
Derek Atkins (warl...@mit.edu) said: - QSF export (or was this active in 2.2.9 already?) This should be off unless the crashing issues have been fixed. And even if those issues HAVE been fixed we might want to disable it because we have no QSF import. Exporting of account tree to QSF was enabled in 2.2.9, but crashes due to a GTK bug. 2.3.x doesn't hit the GTK bug, so it doesn't crash. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Vision behind the Cutecash experiment (was: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)
Christian Stimming (stimm...@tuhh.de) said: I want to get in the place (again) where I can develop a finance software with a set of goals which are slightly different from those of the gnucash project. That's why I started Cutecash - just to see how far I and those who join can get in reaching those goals. I have the following two goals in mind: #1: Create the best possible user experience in a finance management software #2: Have the highest possible amount of fun during development All I can say is that if rewriting an entire GUI interface from scratch in C++ is what you find most fun, you're wired for a different sort of fun than me. But more power to you. On the wiki page http://wiki.gnucash.org/wiki/Cutecash I've additionally explained how some of my current design decisions are based on these two main goals. If anyone prefers the decisions to be chosen differently, he/she is very welcome to start a different project experiment, and we'll see the outcome of each of us after some time. I've seen all sorts of design decisions in gnucash so far. With all this observations, now I came to the point where I told myself I have to make some of those decisions in a different way in order to have a fun project again. Cutecash is an experiment with such a different set of design choices. It is up to the generous observer to decide which result will look better in the long run. My concern is... why is this then in the main GnuCash trunk? Why not just have the configury in the main trunk to build the backend separate, and then we can have as many UI forks as we have people want to do? Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Log file with mkstemp() suffix or not? Re: r15435
Christian Stimming (stimm...@tuhh.de) said: Can someone explain to me the intention of the following code that initialiizes the trace file output file descriptor (from src/libqof/qof/qoflog.c:157ff) fname = g_strconcat(log_filename, .XX, NULL); if ((fd = g_mkstemp(fname)) != -1) { g_rename(fname, log_filename); fout = fdopen(fd, w); } where log_filename==/tmp/gnucash.trace, so that fname will be something like /tmp/gnucash.trace.KSHDJS. From reading the code, I guess it should mean Open gnucash.trace.KSHDJS as trace file and immediately after opening it, rename it back into gnucash.trace. That's at least what the introduction of this code in http://svn.gnucash.org/trac/changeset/15435 suggests. That's what's intended, yes. And it works for me. ... 12566 open(/home/notting/tmp/gnucash.trace.RNY78U, O_RDWR|O_CREAT|O_EXCL, 0600) = 3 12566 rename(/home/notting/tmp/gnucash.trace.RNY78U, /home/notting/tmp/gnucash.trace) = 0 ... Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash on CentOS 5
Geert Janssens (janssens-ge...@telenet.be) said: RHEL as target platform is in serious trouble... 1. There's no packaged webkit for RHEL5/EPEL 2. RHEL5 (base) ships libdbi 0.8.1, but GnuCash uses DBI_DECIMAL_SIZEMASK a constant that is only defined starting from libdbi 0.8.2. I'm not sure how to proceed here. I thought webkit and dbi were the two major features to warrant the 2.4 release. If they're not possible on RHEL, can we say then that we support RHEL ? Phill, if you read this, it may be a good idea to set a minimum required version for libdbi in configure.in... Speaking solely for myself, I'm OK with leaving RHEL 5 at 2.2.x and pushing 2.4.x into the next version of RHEL/EPEL. But I'm not 100% sure how many users we have on RHEL 5 that would want a newer version. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash on CentOS 5
Derek Atkins (warl...@mit.edu) said: Speaking solely for myself, I'm OK with leaving RHEL 5 at 2.2.x and pushing 2.4.x into the next version of RHEL/EPEL. But I'm not 100% sure how many users we have on RHEL 5 that would want a newer version. When is EL6 due? I am not at liberty to divluge that information. (Sorry.) Could we still release 2.4 with webkit (but without dbi) support for EL5? I could certainly build it that way. In fact, couldn't it be configured with gtkhtml if absoultely necessary? Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.2.9 fails configure for guile, looking for 1.6, cannot find guile, yet I have guile 1.8
Kenneth Wolcott (kennethwolc...@gmail.com) said: No, it was an rpm :-) Not that bad about mixing tarballs and rpms :-) how to uninstall the rpm? sudo yum remove gnucash? How to install EPEL? sudo yum install EPEL Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: mirrors.xmission.com * base: centos-distro.cavecreek.net * centosplus: mirror.5ninesolutions.com * epel: mirror.hmc.edu * extras: mirror.5ninesolutions.com * updates: mirrors.netdna.com Setting up Install Process No package EPEL available. Nothing to do Sounds like you have the EPEL repository already. Which repository is GnuCash coming from for you? Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Deprecated libraries
Derek Atkins (warl...@mit.edu) said: Phil Longstaff plongst...@rogers.com writes: I tried a build last night with deprecated gnome/glib/gtk/gdk/... features disabled. I submitted a patch for one simple change. GnomeDruid (libgnomeui) is deprecated in favor of GtkAssistant. I logged a bug for this one. GtkTooltips is deprecated in favor of GtkTooltip. However, there are comments in the code to the effect that some needed features aren't in Gtk (tooltip on each item of a combo box). Others, as Derek says, are dependencies of our dependencies. When were these new interfaces added to Gtk? Do we have a new minimum version of Gtk? GtkAssistant is from GTK+ 2.10. GtkToolTip is GTK+ 2.12. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Deprecated libraries
Derek Atkins (warl...@mit.edu) said: When were these new interfaces added to Gtk? Do we have a new minimum version of Gtk? GtkAssistant is from GTK+ 2.10. GtkToolTip is GTK+ 2.12. Thanks Bill. It's kinda what I was afraid of. I think I can convince myself that it's okay to require gtk-2.10. I'm not sure about 2.12. What version does Ubuntu 8.04 have? I think we'd blow RHEL-5 out of the water if we increase the gtk requirement that far, wont we? RHEL 5 ships gtk-2.10.x, yes. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fedora 11 problems
Ian Leonard (i...@smallworld.cx) said: Okay, this is normal... What's printed in /tmp/gnucash.trace? * 14:32:32 WARN gnc.backend.file.sx no template account with name [078c88574c969c326fbccebca959a21b] * 14:32:32 WARN gnc.backend.file.sx no template account with name [1d5528ef64a304dc2b8c120b53c00526] * 14:32:32 WARN gnc.backend.file.sx no template account with name [de6e90b49f6f38822c8feb70d9d03f75] * 14:32:32 WARN gnc.backend.file.sx no template account with name [d2ee454a634a0903397954e350ce29d0] * 14:32:32 WARN gnc.backend.file.sx no template account with name [7d2f4ee3b8390da842ed85c591bb4db1] * 14:32:32 WARN gnc.backend.file.sx no template account with name [e3e4effa0b670f77cbfcf7b39c097011] * 14:32:32 WARN gnc.backend.file.sx no template account with name [7027d699f12fabc0c4754a332eadfa7c] This means there's an issue with your Scheduled Transactions... Yes. But it was just a warning. Do you think this is the cause of my problems? I can redo those if they can be unpicked from the data file. This sounds like another example of: https://bugzilla.redhat.com/show_bug.cgi?id=493734 or possibly: http://bugzilla.gnome.org/show_bug.cgi?id=573702 Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18041 - gnucash/trunk - Merge webkit branch into trunk.
Derek Atkins (warl...@mit.edu) said: Ahh, yeah, like I said, Fedora-7 era. I'm not sure offhand what version of Gnome Fedora-8 or 9 has, but I would hope that we should support any distros that were released by, say, May 1, 2008. Fedora 8 is Gnome-2.20, glib-2.14.x, libsoup-2.2.x. Fedora 9 is Gnome-2.22, glib-2.16.x, libsoup-2.4.x. Fedora 9 does have an included webkit-1.0.0 version; haven't checked if it's new enough for GnuCash. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New GnuCash release?
Raffael Luthiger (mo...@huanga.com) said: Cristian Marchi wrote: Speaking of flags I thought about it some time ago; if you are going in this direction (flags instead of text) I could work on providing the flags for the actual translations. Just nedd to know the preferred image format (i suggest png) and the size in pixel. (We might want to eventually change to flags instead of words because the menu is getting pretty wide). I recommend you not to use flags. Flags represent countries and not languages. If the size of the menu is a problem then why not go for a select drop-down menu? Also, if it starts using flags, Fedora/RH would start patching out the flags, due to policy. (https://fedoraproject.org/wiki/Languages#Flags) Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New GnuCash release?
Derek Atkins (warl...@mit.edu) said: Also, if it starts using flags, Fedora/RH would start patching out the flags, due to policy. (https://fedoraproject.org/wiki/Languages#Flags) How would fedora patch out http://www.gnucash.org/ ?? Oof. Don't mind me, I missed the first half of the conversation. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FYO: changing OFX version from 102 to 103 breaks access to citigroup (secureofx2.bankhost.com) credit cards
Archimerged Ark Submedes (archimer...@gmail.com) said: I reported this at https://bugzilla.redhat.com//show_bug.cgi?id=481084 and they say CANTFIX. Yes - it's fixed in current versions of libofx and aqbanking, but we can't put those versions on Fedora 9 without breaking the ABI. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FYO: changing OFX version from 102 to 103 breaks access to citigroup (secureofx2.bankhost.com) credit cards
Derek Atkins (warl...@mit.edu) said: I reported this at https://bugzilla.redhat.com//show_bug.cgi?id=481084 and they say CANTFIX. Yes - it's fixed in current versions of libofx and aqbanking, but we can't put those versions on Fedora 9 without breaking the ABI. Does anything other than GnuCash use it? kmymoney2 and grisbi, in Fedora. (This problem only exists on Fedora 9, we have new enough versions on Fedora 10, and too-old versions on Fedora 8 and earlier.) Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r16213 - gnucash/trunk/src/bin - Call gbr_init() only on ENABLE_BINRELOC, #450991. Move variables into #ifdef'ed blocks.
Christian Stimming ([EMAIL PROTECTED]) said: However, I think there should be at least *some* error/debug message on undef'd ENABLE_BINRELOC because this can very easily be disabled unintentionally (e.g. by the subtle autoconf changes that required http://svn.gnucash.org/trac/changeset/15457 subsequently). Could you please add some message to gnucash.trace for the undef'd case? Thanks. Isn't that better as a build-time rather than run-time warning, though? Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fedora 6.9
John Newman ([EMAIL PROTECTED]) said: I had to run yum update, but once that was done GnuCash worked. But before that is was not even loading. Right, it was a g-wrap packaging bug, since fixed. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gtkhtml3 - gnomeprint vs. GtkPrint
Bill Nottingham ([EMAIL PROTECTED]) said: In any case, I opened up a enhancement request against goffice for it. Upstream implies that GOffice can work with GtkPrint/Cairo without any changes - see http://bugzilla.gnome.org/show_bug.cgi?id=412388. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gtkhtml3 - gnomeprint vs. GtkPrint
I don't know if anyone else was already looking at this, but I took some time to look at handling the gtkhtml3-3.13.9x conversion to GtkPrint, in order to get gnucash building again for the Fedora devel tree. In short, I'm not sure how workable any conversion to simultaneously handle both is - 1) it changes the printing module from procedural to being done by attaching handlers to a GtkPrintOperation 2) gnucash exports pretty much a bare wrapper on the gnome-print APIs to scheme for the check-printing code, so that would have to be changed as well 3) Even if gnucash is fixed to work with a GtkPrint gtkhtml... goffice still uses gnomeprint in all released upstream versions. So, it would seem to me the best course of action is to just claim that gtkhtml-3.14 or later is unsupported; upstream is changing both the API and ABI version, so it should fail any configure check gnucash already has. Unless someone who hacks in gtk code more than I do (i.e., once every 3-6 months) wants to take a go at chainsawing the printing code. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gtkhtml3 - gnomeprint vs. GtkPrint
David Hampton ([EMAIL PROTECTED]) said: 3) Even if gnucash is fixed to work with a GtkPrint gtkhtml... goffice still uses gnomeprint in all released upstream versions. This is where I see problems. Gnucash embeds goffice pie charts and bar charts into gtkhtml reports. Not a problem today as both use GnomePrint. I'm not sure how we could do this if gtkhtml used GtkPrint and goffice used GnomePrint. Looking at the goffice gnomeprint code, it may actually be simpler than the gtkhtml code to port - it doesn't actually deal with *printing*, per se, just rendering to a context. Adding an additional gog_graph_print_to_gtk_print that just changes the calls to cairo calls for use with GtkPrint is probably fairly doable, although I don't know when upstream might get around to it. (This also brings in that gnucash's internal copy of goffice would need upgraded to whatever version that would end up being.) In any case, I opened up a enhancement request against goffice for it. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] skip the ofx version check, it's superfluous
The attached removes the call to ofxdump to check the version of libofx - it's superfluous as we check for libofx_get_new_context() in our test program, which didn't exist in libofx 0.7.0. Noticed when testing a build on a system that had the libofx libraries, but not the actual ofxdump test program. Bill --- gnucash-2.0.5/configure.in.foo 2007-02-24 01:34:56.0 -0500 +++ gnucash-2.0.5/configure.in 2007-02-24 01:35:40.0 -0500 @@ -744,39 +744,6 @@ LIBOFX_CFLAGS=-I${OFXPREFIX}/include fi -### Check libofx version -# Obtain version string -AC_MSG_CHECKING(for libofx version = 0.7.0) -if test x${OFXPREFIX} = x ; then - ofx_version_output=`ofxdump --version` -else - ofx_version_output=`${OFXPREFIX}/bin/ofxdump --version` -fi -# Extract version number; output format changed from 0.6.x to 0.7.x -LIBOFX_VERSION=`echo ${ofx_version_output} | sed 's/\([[^0-9]]*\)\([[0-9]]*\.\)/\2/' ` -LIBOFX_VERSION_MAJOR=`echo ${LIBOFX_VERSION} | cut -d. -f1` -LIBOFX_VERSION_MINOR=`echo ${LIBOFX_VERSION} | cut -d. -f2` -# Make sure the numbers are not empty -if test x${LIBOFX_VERSION_MAJOR} = x ; then - LIBOFX_VERSION_MAJOR=0 -fi -if test x${LIBOFX_VERSION_MINOR} = x ; then - LIBOFX_VERSION_MINOR=0 -fi -# Now check for = 0.7.x or = 1.x.x -if test ${LIBOFX_VERSION_MAJOR} -ge 1 -o \ -${LIBOFX_VERSION_MINOR} -ge 7; then - # This is libofx = 0.7.x - AC_MSG_RESULT([found ${LIBOFX_VERSION}]) -else -if test x${want_ofx} = xyes ; then - AC_MSG_ERROR([found ${LIBOFX_VERSION}; Libofx 0.7.0 or newer needed for ofx support]) -else - AC_MSG_RESULT([found ${LIBOFX_VERSION}; Libofx 0.7.0 or newer needed for ofx support]) -want_ofx=no -fi -fi - if test x${want_ofx} != xno ; then # Version number verified. Now check header files. AC_MSG_CHECKING(for libofx/libofx.h) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash patch
Yoshihiro Ota ([EMAIL PROTECTED]) said: +--- src/gnome-utils/gnc-html.c.orig Tue Feb 20 23:18:48 2007 src/gnome-utils/gnc-html.c Tue Feb 20 23:18:38 2007 +@@ -1325,7 +1325,7 @@ + return; + } + +- gtk_html_print(GTK_HTML(html-html), ps-context); ++ gtk_html_print_page(GTK_HTML(html-html), ps-context); + gnc_print_session_done(ps); + } + It's nowhere near that simple. ps-context in gtk_html_print_page (for new gtkhtml3) is a GtkPrintContext, not a GnomePrintContext. I strongly supsect that making this change may make it build/link, but then all the print-session.c gnome_print_* calls will blow up spectacularly. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash patch
David Hampton ([EMAIL PROTECTED]) said: It's nowhere near that simple. ps-context in gtk_html_print_page (for new gtkhtml3) is a GtkPrintContext, not a GnomePrintContext. I strongly supsect that making this change may make it build/link, but then all the print-session.c gnome_print_* calls will blow up spectacularly. So is gtkhtml3 in the middle of a conversion from GnomePrint to GtkPrint and they just haven't bumped the .so version yet? As far as I can tell, yes. http://bugzilla.gnome.org/show_bug.cgi?id=401970 http://bugzilla.gnome.org/show_bug.cgi?id=408671 Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: problems with gtk_html_print in gtkhtml.h
Derek Atkins ([EMAIL PROTECTED]) said: Indeed... Did they not change the .so version when they removed the symbol? No. Bug filed upstream @ gnome.org. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Raise dependency versions of GLib, Pango and GTK+
Andreas Köhler ([EMAIL PROTECTED]) said: currently the code base depends on GLib = 2.4, Pango = 1.6 and GTK+ = 2.4. I would like to propose higher base versions, at least for GLib, better for all three of them. I occasionally build packages for RHEL 4; if this was the case for 2.2, I'd probably stop with the latest 2.0.x, as having to ship an entirely different glib/gtk+/etc stack is a bit more pain than I'd like. I wouldn't say that's a reason by itself to *not* do it, though. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: g-wrap should configure against glib-2.0 [patch]
Josh Sled ([EMAIL PROTECTED]) said: While g-wrap builds and runs fine against glib-2.0, its configure script only checks for glib[-1.0]. As most modern systems don't otherwise need glib-1.x, it'd be nice if future releases of g-wrap didn't either. http://bugs.gentoo.org/show_bug.cgi?id=161903 contains a patch against the g-wrap-1.9.7 distributed configure.ac that changes the test. Hopefully this can be included if/when there's a g-wrap-1.9.8. FWIW, in Fedora we've been building it this way for a while. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: OFX file sample fro GC
Derek Atkins ([EMAIL PROTECTED]) said: There may be some samples in the libofx sources. I don't know. In the libofx tarball, there are some sample files in the 'doc' dir - we package them in the libofx-devel package; not sure what other people do. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash docs source with .svn files?
Thomas Bushnell BSG ([EMAIL PROTECTED]) said: Surely the .svn stuff does not belong in the gnucash-docs tarball? When I was building from SVN, it didn't require it to build... Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] silence startup with guile-1.8
Chris Shoemaker ([EMAIL PROTECTED]) said: Can you please check r13984? I moved this after the (define-module ...) and wrapped it in a version-check. 13985 is quiet for me w/guile-1.8. (Don't have a guile-1.6 box right now to test against.) Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] [RFC] fixes for guile-1.8
It still spews a huge pile of warnings on startup that I haven't tracked down yet, but this is the start of some work to get gnucash going with guile-1.8. What this patch changes: qif-parse.scm: Fixes: ERROR: In procedure scm_lreadr: ERROR: /usr/src/build/746034-x86_64/BUILD/gnucash-1.9.5/intl-scm/../src/import-export/qif-import/qif-parse.scm:9:50: illegal character in escape sequence: #\| make[2]: *** [guile-strings.c] Error 1 during build. engine-helpers.c: scm_block_gc no longer exists in guile-1.8. The engine-helpers.c probably needs wrapped in a version-check, which is why this is a RFC... Bill --- gnucash-1.9.5/src/engine/engine-helpers.c.foo 2006-05-09 17:08:56.0 -0400 +++ gnucash-1.9.5/src/engine/engine-helpers.c 2006-05-09 17:09:05.0 -0400 @@ -1686,8 +1686,6 @@ if (!q) return SCM_BOOL_F; - ++scm_block_gc; - /* terms */ pair = scm_cons (gnc_query_terms2scm (qof_query_get_terms (q)), SCM_EOL); pair = scm_cons (scm_str2symbol (terms), pair); @@ -1723,7 +1721,6 @@ /* Reverse this list; tag it as 'query-v2' */ pair = scm_reverse (query_scm); - --scm_block_gc; return scm_cons (scm_str2symbol (query-v2), pair); } @@ -1928,8 +1925,6 @@ gboolean si1 = TRUE, si2 = TRUE, si3 = TRUE; int max_results = -1; - ++scm_block_gc; - while (!SCM_NULLP (query_scm)) { const gchar *symbol; @@ -2008,8 +2003,6 @@ } } - --scm_block_gc; - if (ok search_for) { qof_query_search_for (q, search_for); qof_query_set_sort_order (q, sp1, sp2, sp3); --- gnucash-1.8.12/src/import-export/qif-import/qif-parse.scm.guile18 2006-03-16 12:56:35.0 +0100 +++ gnucash-1.8.12/src/import-export/qif-import/qif-parse.scm 2006-03-16 12:56:43.0 +0100 @@ -7,7 +7,7 @@ ; (define qif-category-compiled-rexp - (make-regexp ^ *(\\[)?([^]/\\|]*)(]?)(/?)([^\|]*)(\\|(\\[)?([^]/]*)(]?)(/?)(.*))? *$)) + (make-regexp ^ *(\\[)?([^]/\\|]*)(]?)(/?)([^\\|]*)(\\|(\\[)?([^]/]*)(]?)(/?)(.*))? *$)) (define qif-date-compiled-rexp (make-regexp ^ *([0-9]+) *[-/.'] *([0-9]+) *[-/.'] *([0-9]+).*$|^ *([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]).*$)) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] [RFC] fixes for guile-1.8
Derek Atkins ([EMAIL PROTECTED]) said: engine-helpers.c: scm_block_gc no longer exists in guile-1.8. The engine-helpers.c probably needs wrapped in a version-check, which is why this is a RFC... Yeah, this is a bit more of a problem. This particular operation can really beat on the guile garbage collector. Does guile 1.8 have some API we could use to manually turn the garbage collection on and off? With the GC on it's a huge performance hit during these particular operations. So I'd really prefer not to just outright remove this if we can find some other way to do what we want. In the NEWS file of guile-1.8.0: ** The GC can no longer be blocked. The global flags scm_gc_heap_lock and scm_block_gc have been removed. The GC can now run (partially) concurrently with other code and thus blocking it is not well defined. So, I'd read that as 'no'. (I'm in no way an expert on guile internals.) Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] [RFC] fixes for guile-1.8
Derek Atkins ([EMAIL PROTECTED]) said: Thanks! BTW, Miroslav Lichvar ([EMAIL PROTECTED]) is the originator of this patch, just to get the attribution right. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] silence startup with guile-1.8
Starting up gnucash with guile-1.8 yields the following noise: WARNING: (srfi srfi-35): `every' imported from both (oop goops util) and (srfi srfi-1) WARNING: (srfi srfi-35): `any' imported from both (oop goops util) and (srfi srfi-1) WARNING: (g-wrap util): imported module (srfi srfi-34) overrides core binding `raise' WARNING: (g-wrap): imported module (srfi srfi-34) overrides core binding `raise' WARNING: (g-wrap rti): imported module (srfi srfi-34) overrides core binding `raise' WARNING: (g-wrap rti): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (g-wrap c-types): imported module (srfi srfi-34) overrides core binding `raise' WARNING: (g-wrap c-types): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (g-wrap enumeration): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (g-wrap guile): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (g-wrap compat): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (g-wrap ws standard): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (g-wrap guile ws standard): `class-name' imported from both (oop goops) and (g-wrap) WARNING: (gnucash app-utils): imported module (gnucash main) overrides core binding `string-join' WARNING: (gnucash app-utils): imported module (ice-9 slib) overrides core binding `string-capitalize!' WARNING: (gnucash app-utils): imported module (ice-9 slib) overrides core binding `string-capitalize' WARNING: (gnucash app-utils): imported module (ice-9 slib) overrides core binding `string-upcase!' ... ~ 500 lines suppressed ... WARNING: (gnucash business-gnome): imported module (gnucash main) overrides core binding `string-join' WARNING: (gnucash price-quotes): imported module (gnucash main) overrides core binding `string-join' gnucash: [M] Found Finance::Quote version 1.08 Obviously, it's a few more warnings than we'd like. From the guile-1.8.0 NEWS file: -- ** The module system now checks for duplicate bindings. The module system now can check for name conflicts among imported bindings. The behavior can be controlled by specifying one or more 'duplicates' handlers. For example, to make Guile return an error for every name collision, write: (define-module (foo) :use-module (bar) :use-module (baz) :duplicates check) The new default behavior of the module system when a name collision has been detected is to 1. Give priority to bindings marked as a replacement. 2. Issue a warning (different warning if overriding core binding). 3. Give priority to the last encountered binding (this corresponds to the old behavior). If you want the old behavior back without replacements or warnings you can add the line: (default-duplicate-binding-handler 'last) to your .guile init file. -- ... so, that's what I do in the attached patch. Arguably, some of this could be cleaned up in the modules themselves, as some of the warnings are from included-with-guile ice9 or srfi themselves. But the hammer approach is simpler. Bill --- gnucash-1.9.5/src/scm/main.scm.foo 2006-05-09 21:09:19.0 -0400 +++ gnucash-1.9.5/src/scm/main.scm 2006-05-09 21:09:55.0 -0400 @@ -15,6 +15,8 @@ ;; 51 Franklin Street, Fifth FloorFax:+1-617-542-2652 ;; Boston, MA 02110-1301, USA [EMAIL PROTECTED] +(default-duplicate-binding-handler 'last) + (define-module (gnucash main)) (use-modules (ice-9 slib)) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] [RFC] fixes for guile-1.8
Derek Atkins ([EMAIL PROTECTED]) said: Quoting Bill Nottingham [EMAIL PROTECTED]: Derek Atkins ([EMAIL PROTECTED]) said: Thanks! BTW, Miroslav Lichvar ([EMAIL PROTECTED]) is the originator of this patch, just to get the attribution right. Oh. Too late. Already attributed it to you. ;) Looks like src/import-export/qif-io-core/qif-parse.scm needs the same fix. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gcc-4.1 ?
Derek Atkins ([EMAIL PROTECTED]) said: I thought that David had tested gnucash on FC5t2 which uses 4.1... It builds fine for me, although I haven't tried in a week or so. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] (trivial) grammar
Ow, my eyes. :) Bill Index: src/gnome-utils/Makefile.am === --- src/gnome-utils/Makefile.am (revision 13429) +++ src/gnome-utils/Makefile.am (working copy) @@ -270,7 +270,7 @@ if [ -r $(srcdir)/gnc-svninfo.h ] ; then \ cp $(srcdir)/gnc-svninfo.h _gnc-svninfo.h ; \ else \ - echo You're building from SVN... But you're build system is broken ; \ + echo You're building from SVN... But your build system is broken. ; \ echo Don't do that. Complain to your build-system creator. ; \ exit 1 ; \ fi ; \ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
Derek Atkins ([EMAIL PROTECTED]) said: Any chance you could just update g-wrap to 1.9.6 now? Gnucash 1.8 should build fine against g-wrap 1.9.6. That would at least make it easier to build gnucash on FC5 -- it's a pain on FC4 because of the bad interaction of gcc4, g-wrap-1.3.4, and -Werror. Should be done now. Note that ffi is linked into g-wrap statically, as I'd rather not export that for other apps. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
Derek Atkins ([EMAIL PROTECTED]) said: Wonderful! Thank you. Now if only I could figure out why ffi on Solaris/sparc fails during link-time! I had to pull some target support from upstream libffi (gcc.gnu.org); I haven't looked, but maybe there are bits missing in the g-wrap import for that? Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
Derek Atkins ([EMAIL PROTECTED]) said: Quoting Bill Nottingham [EMAIL PROTECTED]: Derek Atkins ([EMAIL PROTECTED]) said: Or is it too late for that, too? Pretty much supposed to be frozen except for last bugfixes at this point. *grf* Okay.. :( I realize this is somewhat of a philosophical argument, but this is why I wouldn't dist a project with -Werror, as you never know what new warnings new compilers may trip you up with in the future. But other people see this differently than me. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
Derek Atkins ([EMAIL PROTECTED]) said: Or is it too late for that, too? Pretty much supposed to be frozen except for last bugfixes at this point. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
[EMAIL PROTECTED] ([EMAIL PROTECTED]) said: Yea, I noticed this myself. Apparantly building g-wrap-1.9.6 depends on glib-devel.. I fixed it myself by changing the glib to glib2 in configure.in, running 'autoconf', and then re-running configure. Actually, this always made me curious - how does pulling both glib1 and glib2 into the same address space *not* cause problems? Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
[EMAIL PROTECTED] ([EMAIL PROTECTED]) said: Honestly, I don't know. I've never seen it cause a problem. In fact all my development (on FC3) has used g-wrap 1.3.4. Unforunately the g-wrap-1.9.6 configure script doesn't properly detect the lack of glib1, so it tries to build it even when it's not able to (which is the cause of the g-wrap build error). I'm not sure whether gnucash2 requires the g-wrap glib bindings... But you can certainly build g-wrap against glib2 with that small configure modification. Another silly question - what does 1.9.6 buy you? For FC, I'm still at 1.3.x, mainly because of inertia (well, and the fact that if we're going to build libffi, it should probably come from the compiler tree.) - 1.3.x seems to work fine. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling gnucash2 on FC5-devel (gcc 4.1.0)
[EMAIL PROTECTED] ([EMAIL PROTECTED]) said: Quoting Dave Herman [EMAIL PROTECTED]: I install glib-devel today and was able to build/install both 1.9 and svn. When attempting to run either version I found that I need to install umb-scheme. Yea, you need that for slib... Um, the g-wrap-devel package should've brought that in. For the FC5 devel tree, you only need slib; it works without umb-scheme. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] turn off G_DISABLE_DEPRECATED for qof/guid.c
In glib-2.9/2.10, GMemChunk is deprecated for GSlice. GSlice isn't added until 2.9/2.10, so we can't port the code to that. Hence, turn off G_DISABLE_DEPRECATED for this one file only. Bill --- gnucash/lib/libqof/qof/guid.c.foo 2005-12-22 17:13:33.0 -0500 +++ gnucash/lib/libqof/qof/guid.c 2005-12-22 17:17:02.0 -0500 @@ -27,6 +27,8 @@ #ifdef HAVE_CONFIG_H # include config.h #endif +/* fix for glib-2.10 */ +#undef G_DISABLE_DEPRECATED #include sys/types.h #include ctype.h ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] turn off G_DISABLE_DEPRECATED for qof/guid.c
Bill Nottingham ([EMAIL PROTECTED]) said: In glib-2.9/2.10, GMemChunk is deprecated for GSlice. GSlice isn't added until 2.9/2.10, so we can't port the code to that. Hence, turn off G_DISABLE_DEPRECATED for this one file only. That will teach me to send mail before reading the mailbox first... I see this is already getting handled in the other thread. :) Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 64-bit issues, login accounts on an Athlon-64 available.
Christian Stimming ([EMAIL PROTECTED]) said: Am Mittwoch, 7. Dezember 2005 17:26 schrieb Englisch, Volker (NIH/NCI) [C]: I've now been able to compile GnuCash on my 64-bit system Just noticed that even though I can compile GC (without the --enable-hbci option) I can not run it: [EMAIL PROTECTED] ~]$ /opt/gnucash/bin/gnucash ERROR: In procedure dynamic-link: ERROR: file: libgw-wct, message: /usr/lib/libgw-wct.so.0: cannot open shared object file: No such file or directory It's looking in the wrong place - this (in theory) should be in /usr/lib64 (assuming x86_64 - you aren't building for ia64, are you? :) ) Does that library exist in /usr/lib64? If so, there might be a misbuilt libtool .la file somewhere. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compiling on Fedora Rawhide
Neil Williams ([EMAIL PROTECTED]) said: What version of goffice is available for rawhide? It's not in Fedora Core or Extras ATM, unless I've missed something. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: HBCI Support
David Hampton ([EMAIL PROTECTED]) said: aqbanking-1.0.4beta-0.fc3 aqbanking-devel-1.0.4beta-0.fc3 aqhbci-1.0.2beta-0.fc3 aqhbci-devel-1.0.2beta-0.fc3 gwenhywfar-1.7.2-0.fc3 gwenhywfar-devel-1.7.2-0.fc3 The error message mentions an aqhbci-qt-tools package. I don't see any such RPM available from RedHat. It's in Fedora Extras. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] (gnome2) check for gtkhtml-3.6 as well
Josh Sled ([EMAIL PROTECTED]) said: On Fri, 2005-02-11 at 15:01, Bill Nottingham wrote: It builds, and the gtkhtml test menu item works. gtkhtml-3.6 is what will be in GNOME 2.10, may as well use whatever is available on the system. Thanks! This is applied, though after some digging I saw that there's also a libgtkhtml-3.2, and extended the check for that, too... Now, the bigger question is _why_ are there all these seperate pkgconfig files? Different sonames, different link lines. Perhaps we should script: for rel in [ 0 .. 10 ] ; do # check for gtkhtml-3.$rel done in configure. Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash-1.6.0 build problem with some guile versions
scm_long_long2num and its inverse are only compiled when LONGLONGS is defined in guile-1.3.4; this isn't the default. The attached allows gnucash to build on such a system (otherwise it tries to link in functions that don't exist...) Bill --- gnucash-1.6.0/configure.in.foo Mon Jun 18 23:05:27 2001 +++ gnucash-1.6.0/configure.in Mon Jun 18 23:05:29 2001 @@ -549,7 +549,9 @@ } ],[ AC_MSG_RESULT(yes) - AC_DEFINE(GUILE_LONG_LONG_OK,1,is sizeof(long_long) = sizeof(gint64)) + AC_CHECK_LIB(guile, scm_long_long2num, + AC_DEFINE(GUILE_LONG_LONG_OK,1,is sizeof(long_long) = + sizeof(gint64))) ],[ AC_MSG_RESULT(no) ])