2008-09-13 GnuCash IRC logs
01:45:59 *** martincleaver has joined #gnucash
02:24:42 *** esperegu has joined #gnucash
03:55:10 *** ErKa has joined #gnucash
04:18:11 *** ErKa has quit IRC
05:19:33 *** martincleaver has quit IRC
05:21:05 *** cortana has joined #gnucash
07:22:55 *** andi5 has joined #gnucash
07:22:55 *** gncbot sets mode: +o andi5
07:42:26 *** micha has joined #gnucash
07:43:38 <micha> andi5: When does http://bugzilla.gnome.org/show_bug.cgi?id=549595 get commited?
07:44:44 <andi5> hehe
07:44:53 <andi5> today?
07:45:13 <micha> before 2.2.7 gets released would be just fine :o)
07:46:05 <andi5> if it solves the problem... let me check ... there has been discussion on the ml as well, right?
07:46:31 <micha> yes, Thomas Bushnell added some notes
07:47:01 <andi5> micha: fyi, i am no active ubuntu user anymore, so i cannot serve as alpha tester for that system anymore (not that i have been before ;-))
07:47:29 <micha> it definitely solves the problem that it returns successfully when it actually wasn't
07:47:57 <andi5> yes, the question is more about what it might break :)
07:48:04 <micha> nothing
07:48:14 <andi5> hehe :)
07:48:24 <micha> additionally it solves the problem link() returning ENOSYS
07:49:50 <micha> look precisely at the current logic: It's completely broken for the special case link() fails and is not returning EOPNOTSUPP
07:53:13 <micha> broken means here: link() fails but copy_file() does not get called *AND* 396 gnc_int_link_or_make_backup() returns TRUE
07:54:56 <andi5> why should it return TRUE?
07:55:04 <andi5> and why did you rename the variable?
07:55:26 <andi5> oh
07:55:43 <andi5> you are right :)
07:55:43 <micha> I added one, not renamed it...
07:56:18 <micha> now, consider Thomas Bushnells arguments - I think he is right...
07:57:04 <micha> but even if you disagree: My minimal patch would at least return consistently FALSE in case the purpose of this function has not been acomplished
07:57:05 <andi5> can you give me a link?
07:57:11 <micha> wait...
07:57:38 <andi5> i do not plan to disagree... i have just become a little more sceptic, trying to understand :)
07:57:41 <andi5> and i am damn slow =)
07:58:39 <micha> http://www.mail-archive.com/gnucash-devel@gnucash.org/msg21247.html
07:58:50 <andi5> dankew
07:59:15 <micha> it's just okay, for ensuring we don't break things...
08:00:45 <andi5> why should one copy on ENOSPC?
08:01:27 <andi5> but let me read first :)
08:02:54 <andi5> or ENAMETOOLONG :)
08:03:44 <micha> I suggest to skip the check on the link() error code and just stupidly *try* to run copy_file() - it really wouldn't hurt...
08:05:16 <andi5> i tend to agree with derek
08:05:49 <andi5> and i suppose the patch is ok (will try soon), so this is the one to go in the near future :)
08:05:57 <micha> but then you should at least consider to turn the logic around and skip copy_file() only for *known* error codes of link()
08:06:27 <micha> the patch is the minimum I agreed upon with derek
08:07:10 <andi5> puh... that will make that code even more unreadable
08:07:47 <micha> ok, at least a lousy alike bug wouldn't loose data anymore with this patch...
08:08:14 <micha> or should I make a suggestion?
08:09:33 <micha> it would make the code more failsafe
08:11:08 <andi5> i am not sure whether saving files on file systems that return weird errors is actually a wise idea
08:11:32 <andi5> they may as well delete your data on their own, just because they are buggy ;-)
08:11:33 <micha> yes, but consider the case with sshfs
08:11:53 <andi5> i suppose the actual bug was return TRUE, right?
08:12:08 <micha> nobody ever thought about link() returning ENOSYS just because its not documented for link()
08:12:45 <micha> and trying a copy_file() in this case would have helped...
08:14:42 <andi5> i am not in the mood to discuss potential breakages based on undocumented return values, sorry
08:15:28 *** micha has quit IRC
08:16:09 *** warlord-afk is now known as warlord
08:17:42 <warlord> good morning andi5
08:17:48 <andi5> hi warlord
08:17:57 <warlord> Fun talk with micha I see.
08:22:37 <andi5> warlord: i have recently added a draft patch to bug 105669 (saving file to a full partition results in unsaved file but no error message) ... would be interesting to know whether that is a possible way to solve this issue... but regarding that copying is harmless, this just reminds me how long it can take to try to save a big file to a full disk again and again until it finally fails...
08:23:35 <warlord> Well... Link() is quick, so I think it's reasonable to try to create a copy backup in this particular case.
08:24:22 <andi5> do you have any idea how to avoid all those "libtool: $lib seems to be moved warnings" ... right now it seems that probably one third of my overall compilation time is spent inside libtool trying to determine what should be obvious
08:24:41 <warlord> I'm afraid I do not know.
08:24:47 <warlord> I'm not sure what's causing it, honestly.
08:25:44 <andi5> well, i can tell you, at least what it is here :)
08:25:51 <warlord> Okay...
08:26:29 <andi5> suppose libglib-2.0.la is in /Programs/GLib/2.16.5/lib/libglib-2.0.la and /System/Links/Libraries/libglib-2.0.la -> /P/G/$v/lib/libglib-2.0.la as well
08:27:29 <andi5> there can be only one libdir in the .la file and that may differ from the dirname of the filename of the file as included
08:28:10 <andi5> well, /S/Links/Libraries is no symlink to /P/G/$v/lib, of course
08:28:38 <andi5> the only intelligence libtool uses here is to remove .. directory items
08:28:59 <warlord> So you're telling libtool that -lglib-2.0 is in /S/L/L but the .la thinks it lives in /P/G/$v/lib
08:29:07 <andi5> right
08:29:18 <warlord> Hmm.
08:29:34 <andi5> some library may depend on it that way... i do not do that on my own
08:29:37 <warlord> Well, this is why installing .la files is "broken" and you shouldn't do it ;)
08:30:08 <andi5> guess what we do on windows :)
08:30:36 <andi5> at least i think we do something like that
08:31:07 <warlord> We probably do, but it's not all that important.
08:33:58 <warlord> It's when "system" libraries do it that trouble happens.
08:47:40 *** ErKa has joined #gnucash
09:01:25 *** JimRaehl has left #gnucash
09:03:17 *** _gunni_ has joined #gnucash
09:05:11 <andi5> the other problem is that libtool is too intelligent and first searches /lib, then /usr/lib, then the contents of /etc/ld.so.conf... unfortunately, this will almost always make it use /lib/$deplib, because /lib and /usr/lib both link to /S/L/L... ah man
09:05:27 *** JimRaehl has joined #gnucash
09:11:09 <warlord> Fun
09:11:18 *** |gunni| has quit IRC
09:23:21 <andi5> btw, i think using unionfs you can split a directory across several partitions
09:23:53 <warlord> Probably
11:01:53 *** greg has joined #gnucash
11:07:06 <greg> Wilddev ever around anymore?
11:13:52 <warlord> not really
11:31:45 *** greg has quit IRC
12:57:08 *** marnanel has joined #gnucash
12:57:55 <marnanel> If I look at my checking account, why do expenses show up in a column called "Credit", even though they do make the balance go down?
12:58:18 * marnanel loves this program, btw, even though I am clearly still not scratching the surface.
13:00:28 <marnanel> (I know they're credits to, say, Expenses:Dining since they're debits to Assets:Checking, but I'm *looking* at Assets:Checking, so shouldn't they be in the debit column there?)
13:02:00 <jsled> hmm. The column labels in those registers should be the "user friendly" forms.
13:02:22 <jsled> but, yes, in Asset accounts, Credits are decreases. :)
13:02:29 <jsled> http://en.wikipedia.org/wiki/Double-entry_accounting#Examples_of_debits_and_credits
13:03:44 <marnanel> So it's just the effect of looking at the double-entry stuff from the wrong side?
13:04:11 * marnanel is determined to get my head around this
13:04:13 <jsled> "wrong"?
13:04:44 <marnanel> um, "wrong" being "other than what I was expecting", which is not really what the word means, is it
13:04:49 <jsled> The labels "debit" and "credit" can have counter-intuitive meanings with respect to account balances in double entry.
13:04:51 <marnanel> I mean I was wrong.
13:04:52 * marnanel nods.
13:04:57 *** greg has joined #gnucash
13:05:29 <jsled> But, really, there is a preference – which should be enabled by default – for things like Asset and Expense accounts which makes the columns read "withdrawl" and "deposit" and "expense" and "rebate".
13:05:34 <jsled> (which are intuitive).
13:06:00 <warlord> it's "wrong" only in that you're used to the terms that you get from your bank statement -- but your bank sends you a statement from _their_ view, not yours.
13:07:29 <marnanel> Ohhhhh
13:07:59 <marnanel> warlord: that makes a whole ton of sense suddenly
13:08:01 <warlord> To the Bank your account is a Liability -- they OWE you that money. So when you deposit money, to them it's a credit (but to you it's a debit)
13:08:06 <marnanel> jsled: I think I turned that off by mistake.
13:08:33 <jsled> If you really want to Know double-entry, then you migth want to turn it off. But it's a lot nicer to have it on, day to day. :)
13:09:03 <marnanel> well, I would *like* to know what's going on, but not to the extent of being confused enough to mess up my accounts. :)
13:11:24 <marnanel> thank you, everyone, for your help and patience.
13:11:50 <jsled> marnanel: that wikipedia page is good; so is the gnucash tutorial and concepts guide.
13:12:27 <marnanel> I have been slowly working through the guide, but I haven't reached that yet. I'll read the WP pages too.
13:12:30 <marnanel> Thanks.
13:33:30 *** marnanel has left #gnucash
13:42:25 <greg> If I don't pick enough accounts to create when initially setting up, or pick some that I never end up using, is it easy to add or delete them?
13:43:04 <greg> I'm trying to get up and going with GnuCash without spending a whole week reading the manual. :-)
13:44:10 <jsled> yes, you can create accounts after the fact, and delete them. What's *not* easy is moving bunches of transactions into the new (say) Expenses sub-accounts.
13:44:47 <jsled> It's easier to over-categorize then reduce fidelity, vs. under-categorizing and differentiating later.
13:46:25 <greg> Thanks
13:46:31 <greg> I shall try that, then
13:49:24 <jsled> If you haven't seen them, the example account hierarchies are pretty useful.
13:51:34 <greg> I'm looking at them in the druid now
13:51:50 <greg> At least, I think I am. :)
14:27:08 *** disasm has joined #gnucash
14:28:20 <disasm> Hey everyone. My fiance and I have both been using gnucash. I need to merge the two accounts, since we'll be getting married soon, and it's just a pain to deal with 2 separate accounts files, How do I go about doing this?
14:29:49 *** greg has quit IRC
14:38:30 <warlord> disasm: the best way would be to use gnc2qif to convert one file to QIF, then import the QIF
14:42:27 <disasm> where do I get gnc2qif?
14:47:27 <warlord> http://gnucashtoqif.sourceforge.net/
15:14:19 *** warlord is now known as warlord-afk
15:18:14 *** nelt has quit IRC
16:06:04 *** sjc has joined #gnucash
16:06:10 *** JimRaehl has left #gnucash
16:13:17 *** Jimraehl has joined #gnucash
16:19:30 *** |gunni| has joined #gnucash
16:28:18 *** _gunni_ has quit IRC
16:28:28 *** disasm has quit IRC
16:31:49 *** cedayiv has joined #gnucash
16:34:56 <cedayiv> I think I've finished the register patch for bug 340041 and bug 436342. Anyone want to look it over before I commit?
16:36:01 <andi5> cedayiv: hiho
16:37:10 <cedayiv> gruss gott ;)
16:37:28 <andi5> hehe =) i just have a quick question or would like to hear your opinion regarding backports :)
16:37:35 <cedayiv> My feeble attempt at German.
16:37:37 <cedayiv> ok
16:38:01 <andi5> i have not yet done all of them, i hope to do that tomorrow or on monday (given that i am on holiday now)
16:38:22 <cedayiv> ok
16:38:51 <andi5> i wonder whether we should stop backporting yet other cool bug fixes that are not strictly critical
16:39:13 <andi5> just to minimize potential breakages and get trunk out a little bit sooner :)
16:39:16 <cedayiv> Depends how fast you want to release, I guess.
16:40:04 <cedayiv> Some can certainly wait until 2.2.8
16:40:04 <andi5> basically i do not want to decide on that... unfortunately some guys think that this is my role :(
16:40:18 <andi5> i just want to make it possible ;-)
16:40:41 <andi5> ah well, i mean do not even backport it to 2.2.x and make it one of the cool new 2.4.x "features"
16:41:12 <cedayiv> Well, since I think the aim is to get a release out quickly, just backport the ones you are comfortable with.
16:41:15 <andi5> it may sound strange, but in the end 2.2.x is called a stable branch and i alone simply cannot guarantee that given that almost all patches are backported
16:41:25 <cedayiv> What new features are you talking about?
16:41:45 <andi5> bug fix features ;-)
16:42:03 <andi5> to give you an example
16:42:48 <andi5> a lot of register fixes produce bugs on other, unanticipated code locations... the register is a beast imho...
16:42:59 <cedayiv> I thought all bug fixes were OK for backporting in 2.2.x.
16:43:27 <cedayiv> Yes, the register fix, in particular, I wouldn't include in 2.2.7
16:44:03 <cedayiv> Since it's my first attempt at a register patch, that's why I asked if someone wants to look at it before I commit.
16:45:06 <andi5> how many lines did you change, just to have a feeling?
16:46:20 <cedayiv> I'm not sure that's a good statistic to judge by; nearly all of the changes are either (a) refactoring, or (b) LEAVE and ENTER calls
16:46:40 <cedayiv> The amount of new stuff is surprisingly small
16:47:46 <cedayiv> Maybe as little as 10 lines.
16:47:53 <andi5> regarding "all bug fixes are ok for 2.2.x"... i am not sure about that and am pretty unhappy that my opinion is important at all... but i would propose to only fix major and critical bugs in 2.2.x from now on, to keep the overhead small (yes, it is not that big, but currently nobody does real auditing, just me pretending to do so)
16:49:01 <andi5> i would not care if i was not to be blamed for breakages as well ;-)
16:49:26 <andi5> i would say: just commit it
16:49:32 <cedayiv> Well I don't mean that all bug fixes should be backported, but it seems like the theoretical goal.
16:49:49 <andi5> i will not include it in 2.2.7 on your request, so you have time to repatch it if you want
16:50:32 <cedayiv> I guess you are referring to the GNCDateEdit problem. I don't know what I can say about that... it worked perfectly for me, and you and I can't test every patch on every platform.
16:51:56 <andi5> oh, well.... in my opinion the theoretical goal is to march into 2.3.x land... 2.2.x backports are needed only because development is not that fast and otherwise people start patching 2.2.x themselves or have to live with some nasty bugs a longer time
16:52:52 <cedayiv> Besides, that was a major/critical bug that the patch fixed too. Before that patch, entering an invalid date would crash on Windows. So it would still meet the criteria of "only backport major/critical patches".
16:53:07 <andi5> yep, sure
16:54:02 <andi5> e.g. the price editor changes... i am not sure, are they critical in the end?
16:54:21 <cedayiv> So in the end there are really no guarantees.
16:55:09 <andi5> i think there are 3 commits or so and i started to defer them until later first, simply because it was not sure whether all that was correct (yes, you asked me to look at it a few times already :))
16:56:09 <andi5> yep, i hate the role of a 2.2 gate keeper and i really wished warlord would continue it... i would rather like to fix bugs myself =)
16:56:30 <cedayiv> The price editor changes fix some really annoying GUI bugs in my opinion, and don't add any new features, so I would suggest backporting them. But if you prefer to wait until more testing has been done, no problem. After all, I only tested on one version of GTK.
16:58:26 <cedayiv> So I think the price editor and security editor patches all work correctly, but I can only say that they do so on my system.
16:59:11 <andi5> ok, so i will try to take a look at the remaining commits tomorrow and will ask on the mailing list if i do not understand something or want to know about this or that possible breakage, if there is anything
17:00:26 <cedayiv> Honestly, I wouldn't backport anything large to a stable branch unless someone besides the patch author has tested it.
17:01:36 <andi5> i will try as much as possible myself as well.... my dream is to get more test coverage, maybe by getting the dogtail branch up-to-date and merge it eventually
17:01:48 <andi5> that would give me a better feeling, actually
17:02:15 <andi5> someday we could eventually fix a bug and add a corresponding test case.... but we are not there yet
17:02:38 *** Jimraehl has left #gnucash
17:02:57 <andi5> oh, i took a look at those decimal() functions already, but have you thought about adding them to the test suite?
17:03:13 <cedayiv> I will commit the register patch and mark it for backport... but feel free to delay backporting until you are comfortable, or at least less uncomfortable. :)
17:03:28 <andi5> hehe
17:03:57 <cedayiv> I must admit that I know nothing about the test suite. I don't even know how to compile or run those "test" subdirectories.
17:04:29 <andi5> i hope that running "make check" still works on windows, i am not sure
17:04:46 <andi5> it compiles the tests and runs them
17:05:31 <cedayiv> I have never tried "make check". If configure.in changes, I just blow away build and inst and recompile everything.
17:05:35 <andi5> another short-term issue for me is to have a cross-compiler for me, so that i need to reboot to test something
17:06:18 <cedayiv> Oh, maybe I have misunderstood "make check". I will have to try it out.
17:06:24 *** JimRaehl has joined #gnucash
17:08:46 <andi5> ok... i gotta leave again... see you cedayiv
17:09:04 *** andi5 is now known as andi5|afk
17:09:09 <cedayiv> OK, good typing to you
17:34:26 *** cedayiv has quit IRC
18:43:29 *** greg has joined #gnucash
18:46:05 *** andi5|afk is now known as andi5
19:30:22 <greg> The online banking stuff is a bit confusing
19:35:53 *** greg has quit IRC
19:40:09 *** cortana has quit IRC
20:14:39 *** zzerxsd has joined #gnucash
20:14:44 <zzerxsd> hi
20:16:15 <zzerxsd> am trying to install gnucash from sources in debian, and i get this error at `./configure` checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
20:16:54 <andi5> zzerxsd: sudo apt-get build-dep gnucash
20:17:07 <zzerxsd> andi5, thanks
20:20:06 *** ErKa has quit IRC
20:35:52 *** greg has joined #gnucash
20:36:00 <greg> 'evening
20:36:32 <andi5> zzerxsd: did it wokr
20:41:13 <greg> Is there a way to input an opening balance after I finish with the new account wizard?
20:41:13 *** zzerxsd has quit IRC
20:42:22 <andi5> yep, that wizard, as well as the new account dialog just create a normal transaction from Equity:Opening Balances to your account
20:42:29 <andi5> you can do the same whenever you want
20:42:38 <greg> Ah, thanks
20:42:56 <greg> That means I don't have to go dig up my brokerage statements until tomorrow. :-)
20:43:21 <andi5> i do not know ;-)
20:55:11 *** zzerxsd has joined #gnucash
21:37:28 *** greg has quit IRC
21:51:02 *** sjc has quit IRC
22:00:13 *** cedayiv has joined #gnucash
22:18:07 *** cedayiv has quit IRC
22:42:59 *** zzerxsd has quit IRC