2017-10-28 GnuCash IRC logs
01:20:31 *** carwynnelson has joined #gnucash
01:23:31 *** carwynnelson has quit IRC
02:07:01 *** carwynnelson has joined #gnucash
02:07:23 *** gjanssens has joined #gnucash
02:07:24 *** ChanServ sets mode: +o gjanssens
02:07:33 <gjanssens> .
02:10:08 *** carwynnelson has quit IRC
02:18:58 *** Mechtilde has joined #gnucash
02:53:39 *** O01eg has quit IRC
02:55:58 *** O01eg has joined #gnucash
04:19:21 *** pilotauto has quit IRC
04:46:15 *** carwynnelson has joined #gnucash
04:58:29 *** Mechtilde has quit IRC
05:03:30 *** gjanssens has quit IRC
05:04:21 *** gjanssens has joined #gnucash
05:04:21 *** ChanServ sets mode: +o gjanssens
05:09:50 *** O01eg has quit IRC
05:33:54 *** Mechtilde has joined #gnucash
05:35:32 *** rietta has joined #gnucash
05:49:25 *** storyjesse has joined #gnucash
05:52:37 *** jwhitmore has joined #gnucash
06:31:12 *** jwhitmore has quit IRC
06:37:27 *** gjanssens has quit IRC
06:38:25 *** gjanssens has joined #gnucash
06:38:25 *** ChanServ sets mode: +o gjanssens
06:49:52 *** jwhitmore has joined #gnucash
06:54:17 *** carwynnelson has quit IRC
07:01:34 *** fekepp has quit IRC
07:04:50 *** carwynnelson has joined #gnucash
07:39:00 <lmat> @tell jralls So, the reproduction steps are pretty simple: KvpFrame f; f.set("/", nullptr); I can think of three solutions: fail silently (don't put anything into the frame, change the key to something inocuous, or modify kvp-frame to allow delimiters in keys. What are your thoughts?
07:39:00 <gncbot> lmat: The operation succeeded.
08:44:46 *** montezuma has quit IRC
08:52:00 *** tuxd00d has quit IRC
08:56:25 *** User has joined #gnucash
08:58:02 *** mrklintscher11114 has joined #gnucash
09:00:29 *** fbruetting has joined #gnucash
09:07:14 *** karelk has quit IRC
09:24:10 *** jwhitmore has quit IRC
09:26:50 *** Jimraehl1 has joined #gnucash
09:27:29 *** Jimraehl1 has quit IRC
09:43:56 *** Mechtilde has quit IRC
09:52:19 *** Mechtilde has joined #gnucash
09:58:59 *** tuxd00d has joined #gnucash
10:05:11 *** storyjesse has quit IRC
10:21:29 *** Mechtilde has quit IRC
10:27:51 *** Mechtilde has joined #gnucash
10:47:40 <carwynnelson> What was the TZ= prefix for tests again? Can't remember it.
11:06:22 <gjanssens> carwynnelson: TZ=America/Los_Angeles
11:07:08 <gjanssens> As I'm building quite frequently, it remains in my bash history
11:07:42 <gjanssens> So I can always retrieve it with <ctrl>-R and then typing TZ=
11:08:08 <carwynnelson> thanks :)
11:14:50 <carwynnelson> is there a way to run specific test functions in these tests?
11:22:32 *** howard has joined #gnucash
11:23:58 <howard> has anyone been able to set up online banking with Capital One (NOT CREDIT CARDS). i have tried multiple times and keep getting warnings that Certificante is not trusted
11:24:25 <howard> Thanks in advance for any help. Never used irc, so this is all new to me
11:27:16 *** spacefan has joined #gnucash
11:30:03 *** spacefan has quit IRC
11:31:47 *** spacefan has joined #gnucash
11:34:28 <carwynnelson> Hi howard, I'm not familiar with hooking gnucash up to online banking (this isn't a feature we have in the UK)
11:34:47 <carwynnelson> But have you found any documentation saying that it is possible to hook up to Capital One bank?
11:35:19 <carwynnelson> "Certificante is not trusted" sounds like a network error to me, or a problem on the banks end
11:41:23 <howard> I have found information online that give me the information to enter as I am setting up OFXDirect Connnect. I have been trying for months to set it up, but have never been sucessful. I get to the point where i am trying to download my accounts, and NOTHING happens
11:41:55 <howard> Currently using Quicken, but they are forcing a subscription based system that i dont want
11:42:38 <howard> I was hoping to find someone who sucessfully set up Capital One, and was downloading data - just want to at least know that it IS possible
11:43:52 *** Cuare has joined #gnucash
11:44:55 <howard> so, yes, it should be possible to set up capital one bank (just not for credit cards
11:53:46 *** mrklintscher11114 has quit IRC
11:55:27 *** Mechtilde has quit IRC
11:56:04 *** Mechtilde has joined #gnucash
12:00:15 *** jwhitmore has joined #gnucash
12:08:18 <carwynnelson> just a shot in the dark but are you certain the ofxdirect connection information is up to date? It could be that the bank has changed the connection information?
12:08:38 <carwynnelson> Might be worth contacting capital one and asking if they can provide you with that information to check if it is up to date.
12:09:52 *** howard has quit IRC
12:14:33 *** fbruetting has quit IRC
12:26:54 *** fekepp has joined #gnucash
12:36:35 *** jralls has joined #gnucash
12:36:35 *** ChanServ sets mode: +o jralls
12:53:05 <lmat> carwynnelson: gtest allows specific test functions. Try ./kvp-value-test --help; or, if that doesn't work, ./test-import-map --help; This works with gdb (and cgdb) with cgdb --args ./test-import-map --gtest-....
12:54:03 <carwynnelson> I think the test i'm running is an old style glib test? I realised they are just executables so I'm just running them in a debugger :)
12:54:10 <carwynnelson> Thanks for the note on gtest
13:04:19 <jralls> .
13:04:19 <gncbot> jralls: Sent 13 hours and 32 minutes ago: <lmat> Here's a fun bug: in gnucash 2.6.11, it was possible to have kvp delimiters in keys. Now, when opening such a file with a key just / , after making a Path (std::vector<std::string>), it's an empty path, so popping the last item on that vector breaks. Exciting!
13:04:20 <gncbot> jralls: Sent 5 hours and 25 minutes ago: <lmat> So, the reproduction steps are pretty simple: KvpFrame f; f.set("/", nullptr); I can think of three solutions: fail silently (don't put anything into the frame, change the key to something inocuous, or modify kvp-frame to allow delimiters in keys. What are your thoughts?
13:08:41 <jralls> lmat: That's an unstable bug, right?
13:09:34 <jralls> lmat: IOW, even though you said 2.6.11 the old behavior applies to current maint and the new problem is just in unstable/master.
13:10:24 <jralls> lmat: Doesn't your KVP-flattening PR do the third choice?
13:11:29 <lmat> jralls: I'm talking about opening a 2.6.11 file using gnucash unstable (backwards compatibility). No, my PR doesn't modify the way kvp works, only how the bayes import map uses kvp.
13:11:52 <lmat> jralls: It uses a flat import map by making sure no delimiters make it to kvp.
13:15:28 <jralls> lmat: Sorry, we'd discussed changing the delimiter in the context of imap-bayes so I thought you were heading down that route. IIRC Bob F.'s original bug was exactly that: imap-bayes can decide that "/" can be a token or part of one and the new implementation doesn't like that.
13:16:37 <jralls> So making sure that no delimiters are inserted into KVP helps going forward but as you now observe doesn't solve the problem when delimiters are already there.
13:17:29 <lmat> jralls: Bob reported that tokens with embedded "/" got divided in kvp. I don't think he mentioned that this frustrates bayes matching, but it does. My PR replaces all '/' with '-' in tokens for bayes import map.
13:19:04 <lmat> yes, existing delimiters... hmm
13:19:07 <jralls> Which is why I suggested changing the delimiter from a normal character to one of the ASCII control characters and suggested FS, GS, RS, or US (0x1c - 0x1f).
13:20:31 <lmat> jralls: We could do that...it's a large change, and hard to detect (searhing for '/' across the whole codebase? ouch), and I think it could be doable with a run-once conversion...
13:21:14 <lmat> jralls: There would still be the difficulty of initially loading the older gnucash file with '/'es.
13:22:54 <lmat> When 2.7 loads a file to convert it, it will be treating '/' as a delimiter (just before converting everything), and there will still be kvp keys with just "/". At least imap bayes can expect to have this.
13:25:07 <jralls> lmat: That difficulty exists only because '/' is used as a delimiter in the KVP path functions. You need search only for those functions then grep the result for '/'. There are very few instances. There should be no delimiters at all in data, KVPFrames are stored hierarchically in both XML and SQL. That it's a problem for SQL is a separate issue.
13:29:43 <jralls> In fact we could just replace the char* path args with a std::vector<std::string>, no delimiters at all.
13:32:24 <jralls> I'm going to go for my weekly bike ride, back in a couple of hours.
13:32:30 *** jralls is now known as jralls_afk
13:41:49 *** carwynnelson has quit IRC
13:49:56 *** carwynnelson has joined #gnucash
14:04:47 *** User has quit IRC
14:34:56 *** carwynnelson has quit IRC
14:41:56 *** Mechtilde has quit IRC
15:00:18 *** Mechtilde has joined #gnucash
15:03:39 *** Mechtilde has quit IRC
15:07:31 *** frakturfreak has joined #gnucash
15:23:01 <jralls_afk> gjanssens: Are you happy with Bob's changes on https://github.com/Gnucash/gnucash/pull/210?
15:27:27 <jralls_afk> lmat: Something is seriously borked in the Travis arch autotools build: "ERROR: In procedure make_objcode_from_file: bad header on object file: "\x7fELF\x02\x01\x01�\x00\x00\x00\x00\x00\x00\x00\x00""
15:58:07 <jralls_afk> lmat: And https://travis-ci.org/Gnucash/gnucash/jobs/294174797 is reporting failure when it appears that everything built and passed.
16:01:56 *** User has joined #gnucash
16:06:11 *** carwynnelson has joined #gnucash
16:15:19 *** carwynnelson has quit IRC
16:40:52 <warlord> .
16:47:00 <gjanssens> jralls_afk: I'll check the PR better tomorrow. It looks ok at first sight.
16:49:18 *** gjanssens has quit IRC
16:58:34 *** MrBusiness2 has joined #gnucash
16:59:15 *** MrBusiness has quit IRC
17:39:38 *** carwynnelson has joined #gnucash
17:48:54 <lmat> jralls_afk: "bad header on object file" is common. I think it means that the object file wasn't finished being written when it was accessed (dependency problem/race condition).
17:50:47 <lmat> jralls_afk: Concerning "appears that everything built and passed", that happened on Ubuntu and Arch linux. A page or two up from the bottom, I see several "warning: possibly unbound variable". I have been taking this, too, as a dependency problem: an object file wasn't completed before it was needed. It does seem that by that point in the build, the libraries should have been built though.
17:51:27 *** rietta has left #gnucash
17:51:29 *** kael has joined #gnucash
17:51:44 <lmat> In both cases, rebuilding is a usable workaround. I remember a commit a few weeks ago seeking to address these dependency problems, but perhaps it was too little or incorrect; I didn't take a close look at that.
17:52:13 *** mrklintscher11114 has joined #gnucash
18:00:34 *** kael has quit IRC
18:01:07 *** mrklintscher11114 has quit IRC
18:07:31 *** jralls_afk is now known as jralls
18:12:54 *** luciano_santos has joined #gnucash
18:15:02 <jralls> lmat: The workaround is getting tiresome and isn't always successful: Sometimes it takes more than one try. You may be right that there's a dependency problem as the tests are being run in the wrong order.
18:38:54 *** carwynnelson has quit IRC
18:55:52 *** jwhitmore has quit IRC
19:06:48 <luciano_santos> hi jralls, remember me? I may have found the source of that problem I showed you. The Problem is not with X11, it appears that the 2.7.0a doesn't have a direct link to libX11.so and another library is linking to it. The openSUSE gnome maintainer made me a patch which passes -lX11, but I still get problems at the same point before (about 60%) when linking libgncmod-gnome-utils.so or later (about 67%) when linking libgncmod-register-core
19:06:48 <luciano_santos> .so -- if I'm not mistaken. I'm trying to use autotools as well, but I still got linking problem.
19:09:50 *** fbruetting has joined #gnucash
19:11:10 <luciano_santos> We use macros that pass commands and the most common flags to the compiler, they're pretty consistent, so if an application is not compiling with macros something is wrong almost for sure.
19:13:33 <lmat> jralls: I'll be happy to take a look at this in a bit; I may ask for comments on the mailing list, too.
19:15:11 <jralls> lmat: The docker problem or luciano_santos's?
19:16:33 <jralls> On luciano_santos's problem I think the solution is to remove the code. Any X11 errors should be handled by the X11 Gdk backend.
19:17:56 <luciano_santos> I have logs of the compilations, both cmake's and autotool's
19:19:38 <lmat> jralls: docker.
19:20:18 <jralls> OK. FWIW I just restarted the latest Ubuntu one for the 3rd time.
19:20:26 <lmat> yuck
19:20:51 <lmat> On the other hand, we have lots of forensic evidence...
19:22:48 <luciano_santos> if it helps, here they are. Cmake's: https://build.opensuse.org/build/home:luc14n0:branches:GNOME:Apps/openSUSE_Tumbleweed/x86_64/gnucash/_log and autotools: https://build.opensuse.org/build/home:luc14n0:branches:home:luc14n0:branches:GNOME:Apps/openSUSE_Tumbleweed/x86_64/gnucash/_log
19:23:37 <lmat> aha! https://github.com/Gnucash/gnucash/pull/178 "I'm going to withdraw this and think about it some more."
19:30:48 <jralls> lmat: And it failed...
19:31:28 <jralls> luciano_santos: Could you please file a bug and attach those logs to it?
19:31:54 <luciano_santos> jralls: sure!
19:33:51 <luciano_santos> jralls: I'll just remove the patch before to show the original problem with cmake's building.
19:34:24 <luciano_santos> original output*
19:34:32 <jralls> luciano_santos: The more information on the bug, the better, so attach the patch and before and after logs.
19:34:52 <luciano_santos> alright!
19:35:03 <jralls> lmat: The discussion codesmythe refered to begins at https://wiki.gnucash.org/logs/2017/09/01.html#T12:08:17.
19:39:10 *** carwynnelson has joined #gnucash
19:39:16 <luciano_santos> jralls: another thing I noticed is that CMakeLists doesn't mentioned libsecret at all.
19:40:09 <jralls> I don't think GnuCash uses libsecret, though AQBanking and WebKit do.
19:41:10 <jralls> Nope, I'm mistaken: gnc-keyring uses it on gnome.
19:44:15 <luciano_santos> jralls: there's another patch that I had to use too, should I put it too? https://build.opensuse.org/package/view_file/home:luc14n0:branches:GNOME:Apps/gnucash/gnucash-fix-changelog-path.patch?expand=1 but I'm not sure if it was the right fix
19:45:21 <jralls> I just fixed that a couple of hours ago.
19:45:44 <luciano_santos> oh, nice.
19:49:55 <jralls> Chris: Did your transaction report PR include any of Doug Doughty's changes?
20:03:27 *** Cuare has quit IRC
20:05:13 <luciano_santos> jralls: Can I attach more than 1 file? because it doesn't appear so
20:06:00 <jralls> You can attach only one file while creating the report. Once it's created you can edit it to add as many as you like.
20:12:00 <luciano_santos> It's done.
20:12:15 *** carwynnelson has quit IRC
20:13:22 <jralls> luciano_santos: I see it, thanks.
20:15:11 <luciano_santos> jralls: you're welcome, it's for the sake of all of us
20:18:26 <luciano_santos> jralls: have you guys thought in making a check for inspecting for the libraries needed by X11 to ensure it's being linked, instead of just checking Xlib.h?
20:22:30 <jralls> luciano_santos: Like I said, I don't think we should be using X11 directly at all. That's Gdk's job.
20:23:50 <luciano_santos> jralls: I see.
20:27:55 <luciano_santos> Well, every now and then I'll be sticking around and giving one or two feedbacks, since the 2.7.0 is important to us cause it drops the use of the old webkitgtk.
20:28:36 <jralls> luciano_santos: Excellent!
20:29:08 <jralls> BTW, I'm releasing 2.7.1 tomorrow.
20:29:48 <jralls> Though there's not a lot different for Linux. The main fix is that it doesn't crash on Windows on startup.
20:30:22 <luciano_santos> Awesome, but I'll have a look at it anyways
20:35:40 <lmat> jralls: Yes, I see. I am hopeful that the codesmyth (who seems to know a good deal about the build system -- he did say: "I'm the primary author of the cmake build system...") will respond sooner than later.
20:37:06 <lmat> I stumbled upon this quote, too, Nov 3, 2015: "you mentioned the idea of 'switching to cmake'. Is than an active effort? I'd be interested in helping out."
20:37:36 <jralls> Which he did.
20:38:14 <jralls> Note, however, that it's the *autotools* builds that are failing on Travis, not the CMake ones.
20:38:47 <lmat> Oh yeah
20:40:10 <lmat> jralls: I'm considering changing kvp back so that delimiters are allowed in keys. What do you think? Do you remember why it was changed to disallow that? Was it principle, or was there an emperical problem?
20:40:23 <lmat> (I think that may be the best of the three options I mentioned earlier)
20:41:55 <jralls> As I said earlier, I think the best solution is to get rid of delimiters altogether and pass a list/vector of keys to the path functions. But keeping them and allowing them in keys is second-best.
20:43:10 <lmat> jralls: right. So C code would send a GList.
20:43:22 <jralls> Yeah.
20:43:53 <jralls> Or varargs.
20:44:18 <lmat> oh yes, that may be easier on the caller side, and memory management, too.
20:45:17 <luciano_santos> I almost forgot, I've tried using the 2.7.0a in the /archive and a tarball made out of the master branch. Later when I already have had dinner I'll register here the results I got.
20:45:18 <jralls> Way better on memory management. The only issue is if we need to send a compound path through g_object_[sg]et/qof_instance_[sg]et.
20:46:03 <lmat> A lot of them are formed with 'kvp_path = g_strdup_printf (IMAP_FRAME "/%s/%s", category, key);' so that would be straightforward to rewrite with varargs.
20:46:30 <luciano_santos> it's just for the purpose of clarifying some things, if that's ok
20:46:34 <lmat> jralls: Oh...I don't know what to expect out of that, so I'll have to make sense of that when I see it...
20:47:37 <jralls> luciano_santos: The 2.7.0 tarballs were made from the 2.7.0a tag. Don't try to use tarballs unless they're made with "make dist" like our release tarballs. Tarballs made directly from git (like the ones Github makes) don't work because we decide wether to run SWIG based on the presence of .git/
20:47:54 <jralls> Release tarballs are pre-swigged.
20:52:42 <luciano_santos> jralls: swig is used even by cmake?
20:53:26 <jralls> Yes, of course. It's how we build the interface libraries to communicate between C and Guile.
20:54:32 <luciano_santos> hm, I should've dug about it.
20:56:38 <luciano_santos> So when you use Travis CI to build against a branch you switch .git/ on/off?
20:57:07 <jralls> Travis builds against a git clone. It would be pretty pointless to run CI against tarballs.
20:58:11 <luciano_santos> oh, of course, I completely forgot about git clone
20:59:37 <jralls> Time for me to go. See you tomorrow.
20:59:57 *** jralls has quit IRC
21:06:46 <lmat> @tell jralls Removing delimiters: sqlite3 books.sqlite <<< "select * from slots;"; returns http://sprunge.us/BePC. In xml, delimiters aren't part of the backend, but SQL uses them. Earlier you said, "KVPFrames are stored hierarchically in both XML and SQL. That it's a problem for SQL is a separate issue." It looks like SQL does not store them hierarchically. What do you recommend?
21:06:46 <gncbot> lmat: The operation succeeded.
21:07:28 *** jwhitmore has joined #gnucash
21:14:58 *** jwhitmore has quit IRC
22:07:53 *** sefnot has quit IRC
22:08:24 *** frakturfreak has quit IRC
22:28:50 <Chris> jralls: hm not exactly; i've mainly lifted the idea of string-matching; I need to go out now; but can summarise my views about all of his reports later
22:29:52 <Chris> @tell jralls hm not exactly; i've mainly lifted the idea of string-matching; I need to go out now; but can summarise my views about all of his reports later
22:29:52 <gncbot> Chris: The operation succeeded.
22:49:50 *** fbruetting has quit IRC
23:08:15 *** luciano_santos has quit IRC
23:40:09 *** Kaell has quit IRC
23:42:21 *** User has quit IRC