2013-11-12 GnuCash IRC logs
00:19:00 *** ErKa has joined #gnucash
00:25:40 *** vym has joined #gnucash
00:33:23 *** yargy has quit IRC
00:35:43 *** vym has quit IRC
00:48:09 *** vym has joined #gnucash
01:05:08 *** ErKa has quit IRC
01:37:46 *** yargy has joined #gnucash
02:04:34 *** vym has quit IRC
02:12:03 *** fell_ is now known as fell
02:35:49 *** vym has joined #gnucash
02:40:07 *** aqua___ has joined #gnucash
03:06:59 *** vym has joined #gnucash
03:17:03 *** vym has quit IRC
03:25:39 *** vym has joined #gnucash
03:43:17 *** vym has quit IRC
03:45:57 *** aqua___ has quit IRC
04:05:36 *** nafg has quit IRC
04:10:02 *** john has quit IRC
04:11:37 *** againstdemons has joined #gnucash
04:25:37 *** vym has joined #gnucash
04:35:48 *** vym has quit IRC
05:25:41 *** vym has joined #gnucash
05:35:46 *** vym has quit IRC
05:53:15 *** aqua___ has joined #gnucash
05:55:36 *** mikee has joined #gnucash
05:55:50 <mikee> @op
05:55:51 *** gncbot sets mode: +o mikee
06:04:15 <gjanssens> Ok, in need of some autoconf advice...
06:04:45 <gjanssens> Is there some macro or function to check the presense of another macro ?
06:05:43 <gjanssens> something like "AC_IFDEFINED([GUILE_PROGS], [yes - do something], [no - do something else])
06:05:48 <PaulFertser> gjanssens: m4_ifdef but it's not really recommended afair
06:06:18 <gjanssens> PaulFertser: thanks
06:06:49 <gjanssens> I found that one, but autoconf complains it's not a known macro
06:07:01 <gjanssens> Running autoconf ...
06:07:02 <gjanssens> configure.ac:437: error: possibly undefined macro: m4_ifdef
06:07:04 <gjanssens> If this token and others are legitimate, please use m4_pattern_allow.
06:07:05 <PaulFertser> gjanssens: what version is that?
06:07:05 <gjanssens> See the Autoconf documentation.
06:07:24 <gjanssens> 2.69
06:07:48 <gjanssens> The problem I have to solve is this:
06:08:18 <gjanssens> If the guile 1.8 and guile 2.0 develoopment packages are installed next to each other
06:08:50 <PaulFertser> Does GnuCash not use pkg-config to track dependencies?
06:09:01 <gjanssens> there is a set of macros starting with GUILE_1_8_... for 1.8 and another set GUILE_...
06:09:18 <gjanssens> pkg-config doesn't tell me which macro I should run
06:09:41 <gjanssens> Particularly because some platforms don't do this.
06:10:01 <PaulFertser> But it tells what version is available and what compile and link flags are needed, it should be about enough I'd guess?
06:10:27 <gjanssens> No, I need the specific GUILE_CHECK_MODULES macro
06:10:37 <gjanssens> And the GUILE_PROGS macro
06:10:56 <gjanssens> Or the _1_8_ equivalents on some platforms..
06:11:44 <PaulFertser> Does that m4_ifdef error happen also after "autoreconf -if" ?
06:12:18 <PaulFertser> Probably libtoolize needed to be rerun or something like that.
06:12:48 <gjanssens> Same error after autoreconf -if
06:13:06 <PaulFertser> If you can determine the version with pkg-config, why can't you use the appropriate macros depending on the result?
06:13:42 <gjanssens> Because the version doesn't map one to one to the macros on all platforms
06:14:09 <gjanssens> Example: Fedora 19 uses GUILE_1_8_PROGS for guile 1.8
06:14:19 <gjanssens> and GUILE_PROGS for guile 2
06:14:39 <gjanssens> Fedora 17 uses GUILE_PROGS for guile 1.8
06:15:07 <gjanssens> Of course Fedora 17 is "old" and not supported anymore, but I'm pretty sure
06:15:23 <gjanssens> some debian versions still use GUILE_PROGS for guile 1.8 as well
06:15:31 <PaulFertser> That sounds eh, broken? Do Fedora folks patch the official upstream pc files?
06:15:43 <gjanssens> Yes, they do
06:15:48 <PaulFertser> Sigh
06:15:59 <PaulFertser> then you'll need to understand how come m4_ifdef doesn't work indeed
06:16:28 <gjanssens> Out of curiosity, how else could Fedora install guile 1.8 and guile 2 alongside each other ?
06:16:58 <gjanssens> I understand there's two different .pc files.
06:17:28 <PaulFertser> I guess if they realized upstream is using conflicting m4 shared files they should have notified the upstream so that the conflict was eliminated there for all distros.
06:17:29 <gjanssens> But afaict these don't lead autoconf to the proper set of macros depending on the chosen guile version
06:18:59 <gjanssens> Ok, IC
06:19:31 <gjanssens> Anyway, thanks for the guidance. I'll look further to why m4_ifdef is not working
06:19:42 <gjanssens> Got to go for lunch now
06:19:48 *** gjanssens is now known as gjanssens-afk
06:22:06 <PaulFertser> I have m4_rename_m4([ifdef]) in /usr/share/autoconf/m4sugar/m4sugar.m4 here with 2.68
06:25:26 *** vym has joined #gnucash
06:32:46 *** GabrieleV has quit IRC
06:35:27 *** vym has quit IRC
06:39:08 *** fell_ has joined #gnucash
06:39:10 *** gncbot sets mode: +o fell_
06:41:46 *** aqua___ has quit IRC
06:46:05 *** fell has quit IRC
06:49:20 *** aqua___ has joined #gnucash
07:09:43 *** Jimraehl1 has left #gnucash
07:19:37 *** Jimraehl1 has joined #gnucash
07:24:09 *** gjanssens-afk is now known as gjanssens
07:24:36 <gjanssens> PaulFertser: is there a reason not to use ifdef directly instead of m4_ifdef ?
07:25:42 <PaulFertser> "With a few exceptions, all the M4 native macros are moved in the `m4_'..."
07:26:30 *** aqua___ has quit IRC
07:27:32 <gjanssens> Hmm, so after m4_rename_m4 is called on ifdef, the ifdef macro becomes undefined. Right...
07:29:32 <gjanssens> m4sugar.m4 has the same rename in version 2.69
07:30:25 <gjanssens> How is this m4 file used by autoconf normally ? Do I need to add macro to configure.ac ?
07:30:57 <gjanssens> Or should this be added via our autogen.sh script ?
07:40:32 <PaulFertser> Should be auto-used, without anything.
07:41:15 <PaulFertser> $ autom4te -l autoconf - <<EOF | grep defined
07:41:15 <PaulFertser> AC_INIT() m4_ifdef([ifdef], [Was defined], [Was not defined])
07:41:15 <PaulFertser> AC_OUTPUT
07:41:15 <PaulFertser> EOF
07:41:29 <PaulFertser> Outputs Was defined here
07:41:49 <gjanssens> Ok, looks like m4_ifset works
07:41:59 <gjanssens> Perhaps m4_ifdef is reserved for internal use
07:44:01 *** Topcat has joined #gnucash
07:44:10 *** aqua___ has joined #gnucash
07:47:06 <PaulFertser> gjanssens: i've just upgraded to 2.69 here and the autom4te test still works, says m4_ifdef is defined.
07:56:01 *** Topcat has quit IRC
07:56:40 *** Topcat has joined #gnucash
07:57:08 <gjanssens> PaulFertser: I get "Was defined" as well when I run the test above
07:57:57 <gjanssens> I suppose the issue must be elsewhere...
08:01:11 <PaulFertser> gjanssens: autom4te is supposed to work the same as autoconf so m4_ifdef should be available for you in configure.ac as well...
08:02:17 <PaulFertser> gjanssens: i've just added m4_ifdef to some configure.ac that's known to work, and autoconf went through just fine.
08:04:04 <gjanssens> Which suggests GnuCash does something unusual or my system does.
08:14:42 *** Topcat1 has joined #gnucash
08:17:19 <PaulFertser> Running autoconf twice on my system produces a configure file with gnucash configure.ac and m4_ifdef inside.
08:19:03 *** Topcat has quit IRC
08:25:25 *** vym has joined #gnucash
08:32:59 *** Topcat has joined #gnucash
08:34:49 <gjanssens> PaulFertser: I retried to use m4_ifdef and now it works here as well. Go figure...
08:35:14 <gjanssens> It will remain a mystery why it didn't before.
08:35:31 *** vym has quit IRC
08:36:51 *** Topcat1 has quit IRC
08:40:06 <PaulFertser> gjanssens: :)
08:49:20 *** GabrieleV has joined #gnucash
08:56:00 *** Topcat1 has joined #gnucash
09:00:13 *** Topcat has quit IRC
09:08:05 *** Topcat1 has quit IRC
09:11:21 <gjanssens> Another brain teaser :)
09:12:00 <gjanssens> Our configure script allows users to override CFLAGS and LDFLAGS retrieved via pkg-config for guile
09:12:27 <gjanssens> In which scenario would that make sense ?
09:13:04 <gjanssens> I can imagine a developer working with a custom compiled guile installed in a non-local path
09:13:34 <gjanssens> But that custom guile also as a .pc file installed somewhere that should have the proper CFLAGS and LDFLAGS for that version of guile
09:14:16 <gjanssens> So I'd set PKG_CONFIG_PATH to find this .pc file rather than overruling CFLAGS and LDFLAGS, right ?
09:15:07 <gjanssens> Any other cases where a user would want to override these ?
09:18:25 <PaulFertser> When he doesn't have pkg
09:18:30 <PaulFertser> -config installed at all
09:18:41 <PaulFertser> Or when crosscompiling without pkg-config wrapper
09:18:58 <PaulFertser> It's standard pkg-config feature, any configure script allows that.
09:25:24 <gjanssens> Ok, but the way the GnuCash configure script is set up currently, it will abort if pkg-config is not installed
09:25:34 *** vym has joined #gnucash
09:25:51 <gjanssens> The crosscompiling scenario may be valid
09:26:48 *** Topcat has joined #gnucash
09:26:58 <gjanssens> I think even there GnuCash assumes pkg-config should be working properly
09:27:41 <PaulFertser> Sometimes people want to take a shortcut instead of configuring a proper pkg-config wrapper.
09:27:47 <PaulFertser> I guess
09:28:08 <gjanssens> Perhaps.
09:28:33 <gjanssens> Looking further in the gnucash configure script it's clear that this has been coded very inconsistently
09:29:04 <gjanssens> Only a handful of PKG_CHECK_MODULES calls are wrapped with CFLAGS/LDFLAGS saving code
09:29:31 <PaulFertser> Why should they be wrapped that way?
09:29:51 <gjanssens> I don't know, I just see it is done in some cases
09:30:12 <PaulFertser> Sounds like an unneeded hack.
09:30:27 <gjanssens> There's calls like
09:30:30 <gjanssens> if test "x$GUILE_LIBS" != x; then
09:30:31 <gjanssens> saved_GUILE_LIBS="$GUILE_LIBS"
09:30:33 <gjanssens> fi
09:30:34 <gjanssens> if test "x$GUILE_INCS" != x; then
09:30:36 <gjanssens> saved_GUILE_INCS="$GUILE_INCS"
09:30:37 <gjanssens> fi
09:30:39 <gjanssens> GUILE_LIBS=""
09:30:54 <gjanssens> and then after the PKG_CHECK_MODULES call
09:31:07 <PaulFertser> Probably that was some stuff for the times when pkg-config wasn't required.
09:31:08 <gjanssens> GUILE_INCS="${GUILE_CFLAGS}"
09:31:10 <gjanssens> if test "x$saved_GUILE_LIBS" != x; then
09:31:11 <gjanssens> GUILE_LIBS="$saved_GUILE_LIBS"
09:31:13 <gjanssens> fi
09:31:14 <gjanssens> if test "x$saved_GUILE_INCS" != x; then
09:31:16 <gjanssens> GUILE_INCS="$saved_GUILE_INCS"
09:31:32 <PaulFertser> _INCS sounds wrong and inconsistent with the way pkg-config macros currently allow to overwrite results.
09:31:55 * gjanssens was wondering about that already
09:32:18 <gjanssens> So you *can* overwrite pkg-config macro results ?
09:32:34 <gjanssens> is it part of the macro ?
09:32:53 <PaulFertser> Of course, with MYSTUFF_LIBS and MYSTUFF_CFLAGS, see man pkg-config
09:33:07 <PaulFertser> Nothing extra is needed for that in configure.ac, it's fully transparent.
09:33:42 <PaulFertser> If you run the generated ./configure --help you'll see pkg-config macros adding descriptions for those options.
09:34:32 *** vym has quit IRC
09:39:23 <gjanssens> I read both man pkg-config and ./configure --help, but couldn't clearly discover how this should work
09:39:40 <gjanssens> Are you saying that if I set GUILE_CFLAGS before running configure
09:40:08 <gjanssens> that PKG_CHECK_MODULES(GUILE,...) will not overwrite it ?
09:40:42 <PaulFertser> gjanssens: if you want to discover exactly how it works you can read it up in /usr/share/aclocal/pkg.m4 . Yes, the variable will overwrite detection.
09:40:48 *** yargy has quit IRC
09:41:51 <PaulFertser> In fact the detection won't happen at all.
09:42:23 <warlord> gjanssens: That code was from before guile had a .pc file
09:42:35 <PaulFertser> I guessed it right, hehe :)
09:42:46 <gjanssens> Ok, thanks for all the feedback.
09:43:01 * gjanssens is still learning a lot about autoconf
09:43:13 <gjanssens> PaulFertser: thanks for your patience :)
09:43:19 <PaulFertser> gjanssens: welcome :)
09:43:32 <gjanssens> I will remove that old stuff while I'm working in that area
09:43:43 <PaulFertser> I'm not an autoconf expert myself but had to learn some working on OpenOCD.
09:43:44 <warlord> gjanssens: yes, I believe that pkg-config can overwrite results.
09:43:50 <warlord> (if called multiple times)
09:44:28 <gjanssens> warlord: pkg-config maybe, but according to that man page PKG_CHECK_MODULES won't
09:44:44 <warlord> hmm
09:44:53 <gjanssens> See, I'm learning ;)
09:44:59 <warlord> But if there is data it wont re-run the check..
09:54:36 *** Topcat1 has joined #gnucash
09:55:25 *** aqua___ has quit IRC
09:59:15 *** Topcat has quit IRC
10:06:41 *** Topcat1 has quit IRC
10:07:14 *** Topcat has joined #gnucash
10:14:13 *** Topcat has quit IRC
10:14:45 *** Topcat has joined #gnucash
10:25:19 *** Anton_ has joined #gnucash
10:25:39 *** vym has joined #gnucash
10:26:17 *** Anton has quit IRC
10:31:28 *** vym has quit IRC
10:44:41 *** aqua___ has joined #gnucash
11:09:27 *** aqua_ has joined #gnucash
11:09:47 *** benoitg has joined #gnucash
11:16:32 *** aqua___ has quit IRC
11:19:37 *** vym has joined #gnucash
11:28:13 *** warlord has quit IRC
11:35:28 *** jmd has joined #gnucash
11:42:51 *** aqua_ has quit IRC
11:48:42 *** StuM has quit IRC
11:59:59 *** vym1 has joined #gnucash
11:59:59 *** vym has quit IRC
12:00:52 *** StuM has joined #gnucash
12:13:10 *** warlord has joined #gnucash
12:13:11 *** gncbot sets mode: +o warlord
12:20:35 *** StuM has quit IRC
12:21:06 *** bpburns has joined #gnucash
12:28:19 *** ErKa has joined #gnucash
12:30:27 *** john has joined #gnucash
12:30:27 *** gncbot sets mode: +o john
13:07:06 *** nafg has joined #gnucash
13:11:13 *** vym1 has quit IRC
13:20:34 *** vym has joined #gnucash
13:21:44 *** Krzysiek_K has joined #gnucash
13:33:24 *** Topcat has joined #gnucash
13:38:50 *** Krzysiek_K has left #gnucash
13:45:24 *** Topcat has quit IRC
14:48:10 *** vym has quit IRC
15:09:16 *** aqua_ has joined #gnucash
15:19:17 *** vym has joined #gnucash
15:24:28 *** aqua_ has quit IRC
15:25:15 *** vym has quit IRC
15:25:25 *** vym has joined #gnucash
15:32:30 *** nafg has quit IRC
15:34:23 *** nafg has joined #gnucash
15:35:31 *** vym has quit IRC
15:56:08 <gjanssens> any idea what (python) package on Fedora I'd have to install to be able to import the _testcapi module ?
15:56:38 <gjanssens> The test suite for our optional python bindings is failing with this error:
15:56:53 <gjanssens> File "./runTests.py", line 8, in <module>
15:56:54 <gjanssens> from test import test_support
15:56:56 <gjanssens> File "/usr/lib64/python2.7/test/test_support.py", line 22, in <module>
15:56:57 <gjanssens> import _testcapi
15:56:59 <gjanssens> ImportError: No module named _testcapi
15:57:41 <gjanssens> "test" is a module installed on my system by installing python
15:58:00 <gjanssens> It needs module _testcapi though, which it doesn't find
15:58:15 <gjanssens> At least not on my Fedora 19 64-bit system
15:58:33 *** yargy has joined #gnucash
16:00:21 *** jmd has quit IRC
16:25:42 *** vym has joined #gnucash
16:35:45 *** vym has quit IRC
16:44:33 *** gjanssens is now known as gjanssens-afk
16:48:33 *** ErKa has joined #gnucash
16:55:16 <warlord> gjanssens-afk: maybe http://python.6.x6.nabble.com/Testsuite-dependency-on-testcapi-td4563422.html has some useful info?
16:55:58 <warlord> gjanssens-afk: or https://bitbucket.org/pypy/pypy/src/317c58dc4f89f38f7b05595ea44b5cef835fe5bd/lib_pypy/_testcapi.py
18:11:26 <john> gjanssens-afk: _testcapi.so is part of python; it should be in /usr/lib64/python2.7/lib-dyload. Fedora leaves it out, so the solution will have to be to automatically skip the tests as suggested in the first of Derek's links.
18:25:36 *** vym has joined #gnucash
18:28:06 *** StuM has joined #gnucash
18:28:43 *** vym has quit IRC
18:29:41 *** vym has joined #gnucash
19:00:50 *** EliBro has joined #gnucash
19:02:00 <EliBro> I'm running GnuCash 2.4.10 on Ubuntu. My datafile is in SQLite format. I recently tried out importing from bank OFX files. There may have been some transactions with text with accented characters - portuguese. Now when I open the file in GnuCash I get all kinds of strange behavior like all accounts have zero balance and no transactions. Any ideas on what to do to remedy the situation? The file still has 4.3 MB size.
19:02:27 <EliBro> A screenshot of what happens when I open the file. http://imagebin.org/275683
19:03:48 *** ErKa has quit IRC
19:27:42 <warlord> EliBro: Um, I think you just destroyed your database.
19:27:45 <warlord> Do you have a backup?
19:29:38 <warlord> Sorry -- gotta run
19:29:40 *** warlord has quit IRC
19:33:06 *** john has quit IRC
19:33:13 *** vym has quit IRC
19:34:04 *** john has joined #gnucash
19:34:05 *** gncbot sets mode: +o john
19:40:32 <EliBro> OK, thanks. I have an old file from June. I'll have to try again.
19:41:14 *** EliBro has left #gnucash
19:45:33 *** vym has joined #gnucash
20:28:44 *** benoitg has quit IRC
20:39:18 *** driggs has joined #GnuCash
20:41:21 <driggs> Hi all! I'm going through the tedious process of assigning TXF Categories to all my accounts for income tax reporting... Does anyone know of any mapping from the default GnuCash Accounts to TXF Categories, or am I cursed to manually research every single one and hope I pick the right category?
20:51:32 *** vym has quit IRC
20:58:26 <john> You're cursed, sorry. FWIW, I went through that exercise a couple of years ago and after it was done decided that importing the TXF info into TurboTax didn't actually get me enough to be worth maintaining it.
21:03:22 *** john is now known as john_afk
21:13:42 <driggs> john_afk: Thanks :-) That's what I was afraid of. I'm doing my 2012 taxes -- very late -- and had hoped this would speed things along.
21:14:50 <driggs> Is there an easy way then to simply truncate a GnuCash file to a starting and ending date (1st and last of the year 2012) so I'm only working with that single year and ignoring the Tax Report features?
21:24:37 *** vym has joined #gnucash
21:27:32 *** vym1 has joined #gnucash
21:27:32 *** vym has quit IRC
21:31:29 *** raeburn has joined #gnucash
21:37:39 *** vym1 has quit IRC
22:19:25 <raeburn> Is the gnucash mailing list archive search page known to be broken?
22:25:44 *** vym has joined #gnucash
22:35:52 *** vym has quit IRC
22:39:40 *** vym has joined #gnucash
22:53:07 *** linas_ is now known as linas
23:12:04 *** vym has quit IRC
23:34:05 *** ErKa has joined #gnucash
23:55:42 *** vym has joined #gnucash