2017-12-02 GnuCash IRC logs

00:39:40 *** bertbob has quit IRC
00:41:01 *** anon has quit IRC
00:43:15 *** bertbob has joined #gnucash
00:46:23 *** bertbob has quit IRC
01:02:33 *** bertbob has joined #gnucash
01:11:37 *** Mechtilde has joined #gnucash
01:26:33 *** fell has quit IRC
01:27:41 *** fell has joined #gnucash
02:06:58 *** marusich has joined #gnucash
02:10:09 *** xi has quit IRC
02:30:29 <Mechtilde> I use version 2.6.18 from Debian. I try to do my monthly transaction. I get the message "Your local ban account has no SEPA information .." I execute the stated line there but no success.
02:31:02 <Mechtilde> I checked the configuration
02:45:28 *** hoijui has joined #gnucash
02:48:19 *** gjanssens has joined #gnucash
02:48:19 *** ChanServ sets mode: +o gjanssens
02:54:59 <Mechtilde> I use version 2.6.18 from Debian. I try to do my monthly transaction. I get the message "Your local ban account has no SEPA information .." I execute the stated line there but no success.
02:55:01 <Mechtilde> I checked the configuration
03:03:54 *** hoijui has quit IRC
03:48:23 <Mechtilde> collecting account data works
03:48:39 <Mechtilde> but I can't start any SEPA transactions
03:51:12 *** marusich has quit IRC
03:59:44 *** chris has joined #gnucash
05:21:48 *** chris has quit IRC
05:39:27 *** tuxd00d has quit IRC
06:12:31 *** chris has joined #gnucash
06:36:58 *** ah has joined #gnucash
06:49:05 *** chris has quit IRC
07:10:02 *** ah has quit IRC
07:26:53 *** chris has joined #gnucash
07:56:05 *** rallidae has joined #gnucash
08:07:21 *** caveman has joined #gnucash
08:22:46 *** storyjesse has joined #gnucash
08:24:14 *** Jimraehl1 has joined #gnucash
08:26:26 *** Jimraehl1 has quit IRC
08:29:04 *** rallidae has quit IRC
08:51:54 <caveman> Hello. I know very little about accounting and I am new to GNUCash. When I start a new "file" should it include my personal accounts and my (very) small business accounts in the same file? If not, can transactions be made easily between files?
09:02:20 <gjanssens> caveman: you can't make transactions between files
09:03:01 <gjanssens> From an accounting point of view your personal finance and small business finance are two independent entities
09:03:20 <gjanssens> They both have their own view on what transactions concern them
09:04:04 <gjanssens> So strictly speaking you should manage them independently, which means that you have to enter some transactions twice
09:04:53 <gjanssens> Having said that, there are probably ways to set up both in one file. You'll have to consult a local accountant to check if that's legally allowed where you live though :)
09:05:26 <caveman> gjanssens:ok, I'll keep them separate. I would like to follow good accounting practices. Thanks for your help, this should get me started.
09:05:52 <gjanssens> caveman: you're welcome and enjoy gnucash!
09:05:58 <caveman> thank
09:05:59 <caveman> s
09:06:30 *** caveman has quit IRC
09:17:49 *** O01eg has quit IRC
09:45:08 *** reactormonk has joined #gnucash
09:45:23 <reactormonk> chris, took me a little while to figure out that "actions" as tab-sensitive
09:45:23 <gncbot> reactormonk: Sent 2 days, 8 hours, and 13 minutes ago: <chris> Actions > Check & Repair & All
09:56:02 <chris> .
09:56:02 <gncbot> chris: Sent 17 hours and 37 minutes ago: <lmat> I just pushed an updated time64-ftw with the updates you requested some time ago.
09:56:45 <chris> reactormonk - true, glad you found it
09:57:06 <chris> lmat will get back on it in a couple days ;)
10:17:27 *** anon has joined #gnucash
10:34:44 *** anon has quit IRC
10:46:23 <codesmythe> @tell jralls We're still installing one file in libexec: https://github.com/Gnucash/gnucash/blob/unstable/common/test-core/CMakeLists.txt#L76 . Do we need to remove that?
10:46:23 <gncbot> codesmythe: The operation succeeded.
10:56:45 *** anon has joined #gnucash
10:57:35 *** storyjesse has quit IRC
11:07:48 <anon> I'm sure this has been asked before, but any timeline on when webkitgtk will be replaced so that gnucash can be added back to the Arch official repos?
11:10:49 <codesmythe> anon: See https://wiki.gnucash.org/wiki/Release_Schedule . The hope is to release 2.8.0 sometime in the first quarter of 2018.
11:17:52 *** chris has quit IRC
11:43:46 *** tuxd00d has joined #gnucash
11:49:19 <anon> Thanks codesmythe
12:02:59 *** jralls has joined #gnucash
12:02:59 *** ChanServ sets mode: +o jralls
12:04:31 <jralls> .
12:04:31 <gncbot> jralls: Sent 1 hour and 18 minutes ago: <codesmythe> We're still installing one file in libexec: https://github.com/Gnucash/gnucash/blob/unstable/common/test-core/CMakeLists.txt#L76 . Do we need to remove that?
12:06:33 <jralls> chris: Good catch, thanks. Yes, we need to at least move it.
12:11:16 *** fekepp has quit IRC
12:14:31 *** fekepp has joined #gnucash
12:29:04 <jralls> gjanssens: I had a thought yesterday about the new versioning system... Some distros have a habit of backporting commits from the repo onto tarball releases. One would think that our frequent release policy would deter that, but I was looking at some old bug reports and apparently Dmitry of Debian seems to think it necessary anyway.
12:29:53 <gjanssens> jralls: the "catch" was by codesmythe :)
12:30:08 <gjanssens> Other than that I'm all ears about the versioning system
12:30:23 <jralls> gjanssens: Oh, so it was. Sorry, codesmythe.
12:31:40 <jralls> So I wonder if the new commit-based versioning will catch that.
12:32:12 <gjanssens> jralls: It won't
12:32:54 <gjanssens> The version data is collected when run from a git repo and passed on as is into the tarball
12:33:37 <gjanssens> But the way it works distro maintainers can override our version tags, and I believe that is what they should do if they change the tarball in some way
12:35:26 <jralls> What do you think are the odds that they will? And what about if they load the tarball into git as a vendor branch to keep track of what they've backported?
12:36:38 <gjanssens> FWIW to override our version tags, the GNUCASH_BUILD_ID cmake variable is available
12:36:56 <gjanssens> What the odds are ? It will depend a bit on how much we promote this.
12:37:39 <gjanssens> I see distro maintainers using this at least on Fedora
12:37:52 <gjanssens> Not for gnucash, because it wasn't possible before
12:39:11 <gjanssens> jralls: as for adding our tarball in git themselves, that's an interesting case.
12:39:20 <jralls> It wasn't in Dmitry's build logs for bug 790845, but then he hadn't patched the tarball.
12:39:49 *** tuxd00d has quit IRC
12:39:53 <gjanssens> My first guess would have been our build system detects git and will extract the version tags
12:40:07 <jralls> That's certainly what I'd do. I don't do any coding without a VCS to help me keep track of what I've done and to roll back when I screw up.
12:40:29 <gjanssens> However at the same time the header files with the version info are already present, so it's possible cmake/autotools won't bother trying to recreate it.
12:40:55 <jralls> Yes, that's what I'd expect. So it would be e.g. gnucash-2.7.2+gitxxxxx where xxxxx is a hash that isn't in our repo.
12:41:48 <gjanssens> But distro maintainers also requested an option to override our VCS detection quite some some back: BUILDING_FROM_VCS
12:41:59 <gjanssens> Exactly to handle this situation.
12:42:16 <jralls> Ah, so they can disable it.
12:42:39 <gjanssens> Yes, although I have never tested whether it was properly ported to cmake
12:42:45 <gjanssens> I know it worked on autotools
12:43:07 *** jotrago has quit IRC
12:43:32 *** jotrago has joined #gnucash
12:44:11 <gjanssens> I don't think we can detect reliably whether our tarball has been patched.
12:44:42 <jralls> Visual inspection of the toplevel CMakeLists.txt fins no OPTION(BUILDING_FROM_VCS) so it would seem not.
12:45:26 <codesmythe> jralls: We run a script to determine BUILDING_FROM_VCS. It could be made an option.
12:45:26 <gjanssens> I imagine we'd need to store an md5 or shaXYZ sum over our source tree inside the tarballs we generate to detect this
12:45:59 <jralls> Sure we can. The build can hash the source tree and write it somewhere, and at startup we read "somewhere" and write it out to gnucash.trace.
12:46:04 <gjanssens> But that would alter the source tree sum itself and besides it could be easily altered as well
12:47:13 <gjanssens> Well, I was thinking of making decisions at runtime based on whether the hash matches or not...
12:47:28 <gjanssens> Wouldn't that be trickier ?
12:47:43 <jralls> Anything can be altered. We're looking to overcome sloth not malice. And no, "somewhere" would be in the build tree so it wouldn't affect the source tree's hash.
12:48:09 <gjanssens> Ah right.
12:49:23 <jralls> What kind of decision at run time?
12:50:08 <gjanssens> Of course the "source tree" should be the dist source tree, because in a real source tree there can be autotools and other autogenerated files.
12:50:30 <jralls> I'm just looking for something that we can easily find during user support to tell us exactly what they've got.
12:50:45 <gjanssens> The decision to alter the version string to display as we now alter it as well based on whether the build was done from a release tag or not
12:50:56 <jralls> Not once we get rid of autotools. CMake is much better about keeping its build stuff to itself.
12:51:28 <gjanssens> Yes, autotools makes things much harder than necessary...
12:52:25 <gjanssens> So the easiest way would indeed displaying the source hash in about.
12:53:04 <jralls> Isn't the version string a make-dist time decision?
12:53:22 <gjanssens> The slightly more involved way would be to adjust the code that currently tests this (purely based on git commit at build time) to also take the source tree hash into account
12:54:17 <gjanssens> No it's a build time decision, because it is always set, but differently depending on whether we build from a tagged commit or not
12:55:20 <jralls> Yes, when building from VCS. But if one builds from a tarball there's no git tag or commit hash to look for, so those must be already in the tarball.
12:56:33 <gjanssens> Indeed at that point they are
12:57:12 <gjanssens> But only the basic tags are hardcoded
12:57:21 <gjanssens> The string is composed at runtime
12:58:39 <gjanssens> And at this point you can alter it still based on whether the current source hash matches the dist tarball's one or not
12:58:57 <gjanssens> (the source tree's hash in the dist tarball that is)
12:59:16 <gjanssens> I will have to leave in a couple of minutes...
12:59:30 <jralls> But *that* does alter the tree's hash.
12:59:34 <jralls> OK.
13:00:53 <gjanssens> What does alter the tree's hash ?
13:01:18 <jralls> Writing it into the tarball.
13:01:45 <gjanssens> Indeed, that's what I started with
13:02:04 <gjanssens> The rest followed because you asked what I would do with it
13:03:11 <gjanssens> So just adding whatever is the current hash is in the about dialog probably easier and more realistic in short time
13:03:22 <jralls> I had something a bit less invasive in mind. Compute the hash and write it to gnucash.trace. Make dist could report it as output and I could put it in the release notes.
13:04:16 <gjanssens> Hmm, as it mostly serves our support needs, your solution is probably sufficient
13:04:17 <jralls> The when we get a bug report that seems weird we can compare the hash in the gnucash.trace with the release notes and if it's different go see what the distro changed.
13:05:01 <gjanssens> Agreed
13:07:39 *** xi has joined #gnucash
13:10:28 <gjanssens> jralls, codesmythe: different topic
13:10:45 <gjanssens> I recently came across a presentation called "Modern Cmake" (https://www.youtube.com/watch?v=JsjI5xr1jxM)
13:10:53 <gjanssens> Which I found very interesting
13:11:17 <gjanssens> I plan to apply some of its techniques in the next major development cycle (once 2.8 is out)
13:11:55 <jralls> Cool. I'll watch that when I can find an hour...
13:11:58 <gjanssens> However one smaller topic was to promote "lowercase cmake commands"
13:12:18 <jralls> Yeah, that does make for better readability.
13:12:44 <jralls> The all-caps things gives me flashbacks to Fortran in college.
13:13:11 <gjanssens> I'd like to convert our cmakelist files to lowercase as one of the first things after 2.8 is out for the very same reason :)
13:13:22 <jralls> At least we don't have to put our CMakeLists.txt on punch cards! ;-)
13:13:35 <gjanssens> LOL
13:13:38 <gjanssens> I just wanted to check how you guys felt about that
13:14:33 <gjanssens> And with that final comment, I'm leaving :)
13:14:36 <gjanssens> See you later!
13:15:17 <codesmythe> gjanssens: I don't mind the UPPER_CASE, but am fine with lower case. I think I just adapted to whatever style cstim started with.
13:16:51 <jralls> codesmythe: Slightly related subject: You said you'd have a look at the dependency issues that were causing make -j4 to sometimes fail. Have you?
13:16:55 <gjanssens> codesmythe: ok
13:17:32 *** gjanssens has quit IRC
13:19:17 *** reactormonk has quit IRC
13:20:25 <codesmythe> Not really. The failure mode I was looking at didn't really break anything. It had to do with opening dynamic libs during guile compiles that are not fully formed.
13:20:42 <codesmythe> But I haven't run into a case where the build actually breaks.
13:21:18 <codesmythe> Do these failures show up in Travis?
13:25:43 <jralls> Not recently.
13:26:57 <jralls> Nor have I seen them on my own builds lately, so maybe it's fixed.
13:31:15 <codesmythe> Does Travis do multcore builds? I don't know why it would take 12 minutes to build and test using cmake
13:37:45 *** fbruetting has joined #gnucash
13:38:05 <jralls> Good question, and it's hard to tell from the output. It doesn't look like it.
13:43:48 <jralls> I just tried a make -j16 and it went all the way through. I think we can declare victory. Oh, it took about 4 minutes.
13:44:42 <jralls> @tell gjanssens I think we can drop autotools now if you're ready.
13:44:42 <gncbot> jralls: The operation succeeded.
13:47:12 <codesmythe> jralls: Woohoo!
13:47:35 <jralls> ;-)
13:47:59 <codesmythe> Is that make -j16 with ninja or make? Is the 4 minutes just to build, or to run the tests also?
13:49:27 <codesmythe> I'm working on fixes for https://bugzilla.gnome.org/show_bug.cgi?id=787497, which I think was one of the last things on my list.
13:51:06 <jralls> That was with make because ninja is too good at figuring out dependencies on its own. 4 minutes including the tests and about 20 seconds for me to decide to run them after running make,
13:52:59 <jralls> So we need to find some new things for your list? ;-)
13:57:06 <codesmythe> On my list of blockers for dropping autotools? No, no more of those please. :-)
13:58:23 <codesmythe> next on my non-cmake list if figuring out why I can't get a good mac build going
13:59:42 <jralls> codesmythe: I already fixed the python bit, but on unstable instead of maint: 961cb5a.
14:00:04 <jralls> Are you doing the Mac build my way, i.e. with gtk-osx?
14:04:20 *** frakturfreak has joined #gnucash
14:04:55 <codesmythe> jralls: Yes, gtk-osx. I had some questions for you, but I'll have to refresh my memory.
14:05:43 <jralls> OK.
14:05:51 <codesmythe> On that bug, I have local fixes for WITH_{OFX,AQBANKING,SQL}. I did notice that WITH_PYTHON worked.
14:05:53 *** bitminer has joined #gnucash
14:06:24 <codesmythe> I'm leaning to not fixing WITH_GNUCASH, because that would be a large change that I don't think is worth it.
14:06:24 *** Cuare has joined #gnucash
14:06:47 <jralls> Are you working on maint or unstable? The bug is against maint... or at least it should be.
14:07:49 <codesmythe> unstable, but you're right. I should switch to maint. I can backport the python fix.
14:08:20 <jralls> Frankly I think only Python is an issue as the others default to ON. For WITH_GNUCASH I think it would be fine to error out.
14:11:42 <codesmythe> I can't build maint on Fedora 27 because webkit1 is already gone. :-( Gotta get a VM going.
14:13:04 <codesmythe> back in a bit
14:14:11 *** bitminer has left #gnucash
14:30:44 *** mikee_ has joined #gnucash
14:32:32 *** mikee has quit IRC
14:37:12 <Mechtilde> I don't whether anyone read it
14:37:15 <Mechtilde> I use version 2.6.18 from Debian. I try to do my monthly transaction. I get the message "Your local ban account has no SEPA information .." I execute the stated line there but no success.
14:37:22 <Mechtilde> collecting account data works
14:37:26 <Mechtilde> but I can't start any SEPA transactions
14:38:17 <Mechtilde> does someone have an idea
14:38:39 <Mechtilde> s/ban/bank
14:53:06 *** Mechtilde has quit IRC
15:07:57 <jralls> Mechtilde: I think only fell can help with that, the rest of us don't have SEPA.
15:08:12 <jralls> Rats.
15:08:37 <jralls> @tell Mechtilde I think only fell can help with that, the rest of us don't have SEPA.
15:08:37 <gncbot> jralls: The operation succeeded.
15:15:48 *** gncbot sets mode: +o fell
15:16:11 *** reactormonk has joined #gnucash
15:16:36 *** fbruetting has quit IRC
15:18:42 *** fbruetting has joined #gnucash
15:22:00 *** fbruetting has quit IRC
15:22:17 <fell> @tell Mechtilde I am currently not using the banking stuff. So you should ask on gnucash-de or aqbanking-user with more sufficient infos (Bank, anonymized logs, ...). See https://wiki.gnucash.org/wiki/De/HBCI
15:22:17 <gncbot> fell: The operation succeeded.
15:36:48 *** codesmythe has left #gnucash
15:42:47 *** codesmythe has joined #gnucash
15:56:16 *** tuxd00d has joined #gnucash
16:07:02 *** fbruetting has joined #gnucash
16:23:26 *** fbruetting has quit IRC
16:46:51 *** hoijui has joined #gnucash
17:21:52 *** fbruetting has joined #gnucash
17:28:11 *** reactormonk has quit IRC
17:42:31 *** tuxd00d has quit IRC
17:42:46 *** hoijui has quit IRC
18:36:27 *** chris has joined #gnucash
18:40:53 <chris> question for core devs - I wish to access an account's last reconcile date- will be useful for Reconciliation Report - there's C api https://wiki.gnucash.org/docs/MASTER/group__Engine.html#gaadfb3bb77e05c23830473dc2ae9ea3ec but I guess it wouldn't be SWIGified easily because it returns bool? would a C wrapper be essential to retrieve in scheme?
18:48:21 <jralls> chris: Why would returning a bool be a problem? libgnucash/engine/engine-common.i includes Account.h so all of Account's public API should be available. Did you try?
18:53:19 <chris> hmm will try brb
18:56:25 <chris> xaccAccountGetReconcileLastDate expects 2 arguments - account, and pointer to a time64... scheme doesn't work like that
18:56:47 <chris> ^my understanding
18:57:23 <jralls> Scheme can't mutate parameters?
19:02:13 <chris> doesn't seem to be... mutating parameters is against spirit of FP. unless my code is flawed, parameters seem unchanged when calling GetReoncileLastDate
19:03:18 <chris> I think I'm right - can't mutate args - the bool returns #t or #f to indicate if acc has a last-reconcile-date - but parameter unchanged
19:04:01 <jralls> Yeah, the wrapper in swig_engine.c creates a stack time64 and passes its ptr to xaccAccountGetReconcileLastDate() but then does nothing with it after the call.
19:06:10 <jralls> So I guess that would need an override function that returns a time64 instead of a bool.
19:06:16 <chris> well for now this is beyond me -- the draft reconcile report is an offshoot of TR and may be useful -- I've even experimented with printing, in addition to Running Balance, Cleared Balance / Reconciled Balance... but I'm not sure what would be most appropriate for a good Reconciliation Report
19:07:17 <jralls> I don't see what good the report is anyway. Gnucash has a nice interactive Reconciliation tool.
19:07:31 <chris> ^true
19:08:32 <chris> hence my view to gjanssens the other day, the draft will sort by reconcile-status, which means 1 sortkey is used up for sorting by reconcile-status and will divide report into 2 sections 'unreconiled' 'reconciled' - but this is what they seem to like
19:10:02 <jralls> Why is the number of sort keys limited?
19:10:30 <chris> we can only have 2 sortkeys done
19:10:34 <chris> don't we -
19:10:59 <chris> for my draft reconcile-report prime-sortkey is 'reconciled status', sec-sortkey='date
19:11:21 <chris> the result is https://imgur.com/a/a4fDT
19:11:33 <jralls> Ah,, you mean there are only two in the options dialog.
19:13:11 <chris> or https://imgur.com/a/v4g3l
19:13:27 <chris> i understand this is potentially useful
19:15:47 <jralls> In both examples sorting by reconcile status is redundant because all of the unreconciled txns are after the reconciled ones.
19:16:34 <jralls> If that isn't true, as happens when one uses a paper check, don't the balances get weird?
19:17:49 <jralls> I suppose you're pulling the balances from the splits rather than calculating them on the fly so they look weird instead of being wrong.
19:18:07 <chris> they do, which is why we'd use xaccSplitGetReconciledBalance
19:18:38 <chris> anyway this is just an experiment, and i don't think i use reconcile for paper checks heavily enough to understand how the numbers are matched up
19:19:17 <chris> I'm wary of formally introducing it whichmeans i'l be feeding this baby forever
19:20:58 <jralls> The balances are computed by sorting the splits for the whole account. "Balance" is the sum of debits and credits through each split. If a split hasn't been reconciled its amount is excluded from the reconciled balance; if it hasn't cleared or reconciled then it's excluded from the cleared balance.
19:22:11 <jralls> It the splits are presented in a different order from that used to calculate the balances then it looks weird because the balances don't sum up line-by-line.
19:23:55 <chris> the lifecycle of a split is of the order: unreconciled -> cleared -> reconciled, right? and believe the balances are updated in C after each split modification?
19:25:01 <chris> I'd think the desired reconciled report would mainly be worthwhile showing the 'last reconciled balance' which should match the 'last bank statement balance', so, the intermediate balances rather irrelevant
19:25:17 <jralls> That's mostly correct. "Cleared" is often skipped because many users don't check with their banks each day to see what's been processed and then update GnuCash with the info.
19:27:40 <jralls> Right. So I'd think a reconciliation report would show last reconciliation date and balance, followed by cleared transactions with amounts and maybe cleared date and a total amount followed by uncleared transactions with amount and a total, and the account balance at the end of the last day of the report at the bottom.
19:28:42 <chris> ^ hence my quest for xaccSplitGetReconciledBalance :)
19:29:29 <jralls> One might sort the cleared splits by date cleared to make them show up in about the same order as on the bank statement.
19:29:55 *** DataWraith has quit IRC
19:31:43 <jralls> Actually your quest was for xaccAccountGetLastReconcileDate, and you really want xaccAccountGetReconciledBalance so you don't have to loop through the account split list looking for the last reconciled one.
19:31:44 <chris> yups - prime-sortkey='reconciled-status (in order 'r' 'c' 'n'), sec-sortkey='date.... startdate=last-reconcile-date.... enddate=today... running-balance #t... also potentially display cleared-balance or reconciled-balance... and TADA reconcile report
19:33:18 <jralls> Running balance isn't useful unless all of the unreconciled splits are presented in the right order on the statement. Enddate should be the date of the statement, not today.
19:33:41 <chris> brb breakfast
19:35:59 <chris> here's one i prepared earlier : https://github.com/Gnucash/gnucash/pull/229/commits/57d6021adad4a15c83a99b21db35780565230894
19:36:12 <chris> and https://github.com/Gnucash/gnucash/pull/229/commits/4171e8b0bf90630a19a37fd1286ea28dced09db8
19:36:18 <chris> ok genuinely breakfast now
19:37:23 <jralls> That PR is getting really messy.
19:41:07 <chris> yeah I intend to remove any experiments eventually
19:41:45 <chris> and merge all intermediate early work
19:42:30 <jralls> I'd really like to do code freeze at the end of this month, so it would be great if you could pull out the changes that are ready to go and make a new PR with them.
19:42:54 <jralls> And *just* them!
19:44:46 <chris> Ok, how about I merge all the boring early work, and will separate bugfixes and commenting in the same PR
19:45:18 <chris> or maybe I can do it in another branch
19:45:21 <chris> clean up all git history
19:46:51 <chris> delete experimental and reversed work (eg scheme sorter)
19:47:56 <chris> will be ready before month end
19:49:14 <jralls> Yes, do a new branch and cherry-pick over the commits.
19:49:45 <chris> well gentlemen, after this I'm off getting hitched today
19:49:57 <chris> :-o
19:51:52 <jralls> Oh, yeah. Well, so much for getting anything in before code freeze... unless you want a much worse freeze! ;-)
19:52:16 <jralls> Bon chance and enjoy your honeymoon!
20:13:53 *** jralls has quit IRC
21:00:19 *** xi has quit IRC
21:26:46 *** frakturfreak has quit IRC
22:03:19 *** fbruetting has quit IRC
22:31:00 *** fbruetting has joined #gnucash
22:38:00 *** anon has quit IRC
23:01:21 *** fbruetting has quit IRC
23:29:06 *** fbruetting has joined #gnucash