2017-05-05 GnuCash IRC logs

00:10:50 *** sixwheeledbeast has joined #gnucash
00:52:03 *** Mechtilde has joined #gnucash
00:55:32 *** kael has quit IRC
01:03:56 *** fell_ has joined #gnucash
01:06:11 *** fell has quit IRC
01:13:24 *** O01eg has quit IRC
01:50:26 *** Mechtilde has quit IRC
02:10:54 *** gjanssens has joined #gnucash
02:10:54 *** ChanServ sets mode: +o gjanssens
02:13:55 <gjanssens> .
02:56:06 *** fabior has joined #gnucash
03:03:30 *** mrklintscher has quit IRC
03:26:21 *** mrklintscher has joined #gnucash
03:37:53 *** Mechtilde has joined #gnucash
03:44:40 *** mrklintscher2 has joined #gnucash
03:45:01 *** mrklintscher has quit IRC
03:46:33 *** mrklintscher2 has quit IRC
03:46:57 *** mrklintscher has joined #gnucash
03:52:21 *** fekepp has quit IRC
03:52:35 *** mrklintscher2 has joined #gnucash
03:54:55 *** mrklintscher has quit IRC
03:56:12 *** Mechtilde has quit IRC
04:09:41 *** fekepp has joined #gnucash
04:27:04 *** Jacques has joined #gnucash
04:53:34 *** Jacques has quit IRC
05:00:38 *** pilotauto has quit IRC
05:17:43 *** Mechtilde has joined #gnucash
05:18:02 *** jotrago has quit IRC
05:18:08 *** jotrago has joined #gnucash
05:23:06 *** Mechtilde has quit IRC
06:35:48 *** Jimraehl1 has joined #gnucash
06:37:05 *** Jimraehl1 has left #gnucash
06:48:40 *** Mechtilde has joined #gnucash
07:14:33 *** fabior has quit IRC
07:16:28 *** Mechtilde has quit IRC
07:36:52 *** jonas has quit IRC
07:38:04 *** jonas has joined #gnucash
07:57:00 *** Mechtilde has joined #gnucash
07:57:54 *** rickoehn has joined #gnucash
08:15:50 *** jchonig has quit IRC
08:17:00 *** jchonig has joined #gnucash
08:42:09 *** User__ has joined #gnucash
08:42:34 *** fabior has joined #gnucash
09:26:10 *** codesmythe has joined #gnucash
09:28:52 <warlord> @tell Robert you are correct, the link changed from logs to build-logs
09:28:52 <gncbot> warlord: The operation succeeded.
10:02:46 *** mrklintscher2 has quit IRC
10:06:02 *** kael has joined #gnucash
10:16:16 *** mlncn has quit IRC
10:18:04 *** Mechtilde has quit IRC
10:18:21 *** kael has quit IRC
10:48:16 *** Mechtilde has joined #gnucash
10:58:52 *** KaiForce has quit IRC
10:59:14 *** KaiForce has joined #gnucash
11:13:48 *** Mechtilde has quit IRC
11:16:21 *** mrklintscher has joined #gnucash
11:18:23 <lmat> When I use cmake to make the project (gnucash/master), I get http://paste.ubuntu.com/24517378/
11:18:31 <lmat> I get a similar error using ninja.
11:18:39 <lmat> I'll try to bisect the problem...
11:19:52 <codesmythe> lmat: What OS are you using? If Linux, which distro?
11:22:00 <lmat> codesmythe: Archlinux.
11:24:53 *** zahremar5 has quit IRC
11:25:26 <warlord> lmat: are you sure you started with a clean checkout?
11:25:55 <codesmythe> lmat: One I don't use. :-) FWIW, I just built master on Ubuntu 16.04 without issue. Did you clear out the guile caches?
11:25:58 *** ramkumar has joined #gnucash
11:39:41 <gjanssens> lmat: are you building in parallel ? It sometimes happens a .go file the current target depends on is not yet built.
11:39:56 <gjanssens> Rerunning (in my case ninja) usually gets passed it
11:41:24 <gjanssens> At least on my F25 box
11:50:19 <lmat> warlord: I'm pretty sure; I ran git clean -fdx; first.
11:51:06 <lmat> codesmythe: If they're in the project, I'm pretty sure git clean -fdx; would take care of that. If they're somewhere else, please let me know what I should do.
11:51:49 <lmat> gjanssens: The error I'm getting is segmentation fault. Is that the error you see? I tried parallel and not parallel. I tried with ninja, and with cmake ..; make;
11:52:13 <lmat> I do an out-of-tree build ( mkdir build; cd build; cmake ..; ...)
11:52:23 <lmat> And I delete that build directory each time.
11:54:20 <gjanssens> lmat: when it happens these are segmentation faults as well yes.
11:55:55 <codesmythe> lmat: There are also usually caches in $HOME/.cache/guile. I suspect gjanssens has the right answer. There are known issues with parallel cmake builds that I plan to fix once my distcheck stuff is done.
11:57:10 <lmat> codesmythe: I'm not sure how parallel builds can be possible with recursive make, but I'm thrilled you think it can be done! I know very little about the problem domain, so I'm hopeful for you!
11:58:44 <codesmythe> lmat: cmake generated build files (make or ninja) don't use recursive builds.
11:59:18 <lmat> I keep running it over and over, and ninja reports less and less things to do each time. although now it seems the number isn't going down from 24...
11:59:21 <lmat> codesmythe: Very encouraging indeed!
11:59:35 *** mlncn has joined #gnucash
11:59:58 <codesmythe> lmat: The scheme compile though does expect certain compiled shared libraries to be available at 'compile' time (runtime for the compiler). If those are missing or half-built, seg faults and other errors can occur.
12:00:27 <gjanssens> Still it's odd you keep having the same issue over and over
12:00:53 <lmat> codesmythe: https://www.mail-archive.com/cmake@cmake.org/msg24116.html suggests that cmake only does recursive builds as of 2004. That's changed then?
12:01:04 <lmat> codesmythe: (It's such good news, that I dare not believe it ^_^)
12:01:07 <gjanssens> It has happened I get 3 consecutive builds to segfault, but no more than that.
12:01:41 <gjanssens> Is the segfault always on the same target
12:01:43 <gjanssens> ?
12:01:55 <lmat> gjanssens: I have 8 processors... ;-) I'll try with cmake ..; make; and try it a couple times
12:02:08 <lmat> gjanssens: It's hard for me to tell which target has the problem since there are so many going on at once.
12:02:34 <gjanssens> So far the message has always been for the target right above it in my case
12:03:10 <gjanssens> Which suggests test-extras in your log
12:03:10 <lmat> gjanssens: How many cores?
12:04:59 <lmat> Using non-recursive, it's always test-extras.go. Once it wasn't a seg-fault; I got a stack trace. I'll paste that presently.
12:05:29 <gjanssens> 4 cores, 8 threads
12:05:34 <lmat> http://paste.ubuntu.com/24517565/
12:06:02 <lmat> gjanssens: That should be comparable then.
12:06:16 <codesmythe> time zone issues?
12:06:55 <gjanssens> Wow, never seen that one before...
12:07:04 <lmat> removing ~/.cache/guile. trying again.
12:07:11 *** ramkumar has quit IRC
12:07:17 <lmat> codesmythe: I don't think so... I set my /etc/localtime properly.
12:07:39 <gjanssens> The "invalid timezone" message is not unusual. I see it as well in my builds.
12:08:26 <lmat> I wouldn't be surprised if my cache was screwed. I was working on timespec a while back and ran into copious guile compilation issues...
12:08:32 <lmat> I think I really made a wreck of it!
12:08:33 *** Simon has quit IRC
12:10:08 *** Simon has joined #gnucash
12:10:09 *** mrklintscher has quit IRC
12:10:36 <lmat> I think the reason ninja gets more done each time is because it starts several jobs in parallel. One of them fails, but the others succeed.
12:11:20 <lmat> Okay, using ninja, when I get it backed into a wall (cache is cleared now), I get http://sprunge.us/cfTb
12:12:02 *** mrklintscher has joined #gnucash
12:12:50 <lmat> So I'm using guile 2.2.1 ...
12:13:12 <gjanssens> Ok I was wondering already... We never tested against 2.2
12:13:22 <gjanssens> Do you have access to guile 2.0 ?
12:14:20 <gjanssens> All the failures seem to be missing the app-utils moduls.
12:14:28 <gjanssens> module*
12:14:39 <gjanssens> Can you check if this has already been built ?
12:14:56 <lmat> sure
12:15:31 <gjanssens> It should be in ../../../lib/gnucash/scm/ccache/2.0/gnucash or a subdirectory IIUC
12:15:32 <lmat> I found <builddir>/lib/gnucash/scm/ccache/2.0/gnucash/app-utils.go
12:15:41 <lmat> jackpot :-)
12:16:48 <lmat> I have guile 2.0 at /usr/bin/guile2.0
12:17:26 <gjanssens> That's less relevant. It's more important which library gnucash builds against.
12:17:45 <gjanssens> Or put differently which guile*-dev(el) packages are installed
12:18:24 <lmat> gjanssens: I see. There are no "-dev" package in archlinux; they package them together (guile comes with development files).
12:18:59 <lmat> Looks like I have packages "guile", "guile1.8", and "guile2.0" (which come with their development libraries, etc.) installed.
12:19:29 <lmat> gjanssens: I assume that if gnucash build is invoking "guile", it's getting the 2.2 executable and its libraries.
12:20:22 <codesmythe> lmat: what does 'pkg-config --cflags guile-2.0' return?
12:20:34 <lmat> gjanssens: You can see the file list here: https://www.archlinux.org/packages/extra/x86_64/guile2.0/
12:20:56 <lmat> codesmythe: -pthread -I/usr/include/guile/2.0
12:21:02 <gjanssens> lmat: gnucash is not using the guile command directly. It builds its own wrapper around libguile
12:21:19 <lmat> gjanssens: I see!
12:22:20 <gjanssens> At least that what it does for autotools. I should verify for cmake
12:22:42 <codesmythe> For cmake, we do use the guile command directly.
12:23:02 <lmat> So maybe I'll change line:q
12:23:04 <lmat> oops
12:23:34 <lmat> So maybe I'll change line 239 and remove "QUIET" from the guile2 check, and see what it finds...
12:24:38 <lmat> Found guile-2.0, version 2.0.14
12:25:03 <lmat> oh, line 239 in CMakeLists.txt!
12:27:24 <lmat> That's what guile2.0 --version; returns, so I guess it's finding the right one...
12:27:54 <gjanssens> Indeed.
12:28:11 <gjanssens> My guile version is 2.0.13
12:28:51 <codesmythe> lmat: Line 266 could be picking up version 2.2 of the guile execute, creating a bad mix of guiles.
12:29:39 <gjanssens> It probably is
12:29:56 <gjanssens> What does guile --version on your system return ?
12:30:08 <codesmythe> lmat: put this as line 267 and let me know what it says: MESSAGE("GUILE_EXECUTABLE = ${GUILE_EXECUTABLE}")
12:30:08 <codesmythe> '
12:31:58 <lmat> codesmythe: I changed line 247, but yeah, I should change 266, too!
12:32:11 <lmat> gjanssens: 2.2.1
12:32:55 <lmat> codesmythe: Hold on, let me get a paper-weight to put on my shift key...
12:33:05 <lmat> codesmythe: It says "/usr/bin/guile"
12:33:24 <gjanssens> jralls: why did we change to a self built guile executable again in the autotools build ?
12:33:54 <gjanssens> And more importantly, is that reason enough to do the same in our cmake based system ?
12:34:11 <lmat> codesmythe: I changed line 266 to (GUILE_EXECUTABLE guile2.0), and it shows the desired output now.
12:34:17 <lmat> makeing.
12:34:18 <gjanssens> lmat: so yes, your executable is 2.2.1 while the libraries are 2.0
12:34:19 <codesmythe> lmat: :-) Do you have /usr/bin/guile-2.0 ?
12:34:40 <codesmythe> lmat: ok
12:36:28 <lmat> I think this is further than it went before... :-)
12:39:33 <lmat> built successfully. Thanks!
12:39:43 <gjanssens> Yay! \o/
12:39:56 <codesmythe> excellent
12:40:12 <gjanssens> Another interesting test would be to switch to guile 2.2 completely :)
12:40:20 <gjanssens> Can be done at a later time though
12:40:49 <gjanssens> Anyway it's almost time to leave for me
12:41:20 <gjanssens> Just a quickie. lmat: how is your timespec work going ?
12:44:03 <codesmythe> lmat: What is the exact name of the guile 2.0 executable on your system? I can tell FIND_PROGRAM to look for the 2.0 specific version first.
12:45:40 *** Mechtilde has joined #gnucash
12:48:37 *** gjanssens has quit IRC
13:20:13 <lmat> @tell gjanssens "how is your timespec work going?" Completely stalled. I ran into a few walls, and could not see my way out. In fact, at this point, I would probably start over and make smaller incremental changes.
13:20:13 <gncbot> lmat: The operation succeeded.
13:20:56 <lmat> codesmythe: /usr/bin/guile2.0; (/bin, /sbin, and /usr/sbin are all symbolic links to /usr/bin)
13:23:17 <lmat> codesmythe: (so I can find it in any of those dirs...)
13:27:53 *** mrklintscher has quit IRC
13:29:06 *** mrklintscher has joined #gnucash
13:31:04 *** KaiForce has quit IRC
13:33:45 *** mrklintscher has quit IRC
13:35:09 *** mrklintscher has joined #gnucash
13:48:34 <jralls> lmat: *Always* do small changes! Commit early and often. One can always squash commits together later, but it's a real PITA to tease out separate commits when you've made too big a change.
13:50:46 <jralls> @tell gjanssens lmat codesmythe Ninja takes -j just like make does.
13:50:46 <gncbot> jralls: The operation succeeded.
13:54:20 <jralls> lmat: This isn't school, you don't have to do your work in isolation. Quite the contrary: It's a team, so when you get stuck ask for help! Push often to your personal repo and tell us when you do.
13:58:20 *** mrklintscher has quit IRC
13:59:32 *** mrklintscher has joined #gnucash
14:03:53 <jralls> @tell gjanssens We build our own Guile on autotools because Guile-1.8 and Guile-2.0 have different autoconf macros and we couldn't get them to do the right thing. That's probably not a problem for CMake.
14:03:53 <gncbot> jralls: The operation succeeded.
14:12:16 *** fekepp has quit IRC
14:16:48 *** mrklintscher has quit IRC
14:16:57 *** frakturfreak has joined #gnucash
14:18:15 *** mrklintscher has joined #gnucash
14:43:24 *** karelk has quit IRC
14:48:42 *** Mechtilde has quit IRC
14:56:35 *** karelk has joined #gnucash
14:59:30 *** fabior has quit IRC
15:06:43 *** karelk has quit IRC
15:15:53 *** karelk has joined #gnucash
15:23:17 *** mrklintscher has quit IRC
15:24:39 *** mrklintscher has joined #gnucash
15:32:23 *** karelk has quit IRC
15:48:20 *** karelk has joined #gnucash
16:06:21 *** fabior has joined #gnucash
16:55:56 *** fell_ is now known as fell
16:56:22 *** gncbot sets mode: +o fell
16:58:45 <fell> jralls, no I have no frequent communication with Martin, but my patch for his Readme regarding bank data he committed the next day.
16:59:46 <fell> But his last activity, I see, is from 2017-04-23 on his new 5.8 branch.
17:00:15 <jralls> OK. I'll see if that fixes the crashing problems on Windows and Macs.
17:00:29 <jralls> Thanks.
17:02:44 <fell> e.g. "
17:02:45 <fell> GWEN allows for a callback after creating a GWEN_SYNCIO object to be used
17:02:47 <fell> with a http session. AqBanking uses that to set its own user-based
17:02:48 <fell> certification check function.
17:03:50 <jralls> That's not where the crash is. It's in the setup window. Windows crashes as soon as you push the launch button, Mac crashes when you try to create a new user.
17:04:35 <jralls> I got a debug build yesterday on Windows and it didn't crash at all, so probably an optimization issue. But then the stupid build system stopped cooperating.
17:05:25 <fell> Ah, the othre issue.
17:08:12 *** User__ has quit IRC
17:24:58 *** fabior has quit IRC
17:55:25 *** frakturfreak has quit IRC
18:00:41 *** User_ has joined #gnucash
18:32:34 <codesmythe> jralls: In commit 582edc1b, you removed '-arch i386' from the flags for CMake, saying this should be part of CFLAGS, etc. Is there a second part to this that you need to commit? Without that flag, the macOS maint build will default to 64 bits on recent OS versions.
18:36:04 <jralls> codesmythe: Actually it defaults to the build hardware architecture unless you pass -arch C/CXX flags and always has. It's really rude to dictate build parameters like arch, optimization level, or debug flags. That's exactly why CMake automatically pulls $CFLAGS and CXXFLAGS from the environment, so that the builder can set it the way he wants.
18:37:35 <jralls> So, no, there isn't a second part of the commit. If you want a 32-bit build on a 64-bit system, add -arch i386 to $CFLAGS and $CXXFLAGS.
18:40:04 *** rickoehn has quit IRC
18:42:34 <codesmythe> jralls: OK. I had the impression we wanted to force the macOS build to 32 bits always.
18:45:06 <jralls> Why would we want to do that? The 2.6.x bundles are 32-bit because they support MacOS X 10.5 & 6 and those ran on 32-bit, but the gnucash-on-osx build scripts take care of that. There's no need for GnuCash's CMakeLists.txt to set it.
18:47:13 <jralls> I discovered the problem when I reconfigured the build system to get ready for 2.7, which supports only 10.9 and later (because earlier doesn't support C++11). Since 10.9 runs only on 64-bit hardware I set up for that, and then GC wouldn't build because all of the dependencies were x86_64 and i386 binaries wouldn't link.
18:52:27 <codesmythe> ISTR when I first started doing the CMake stuff that 64 bit builds did not work because a conflict between Apple system headers and GTK headers around the definition of int64 as unsigned long vs unsigned long long or something like that. But I'll have to go back and look.
19:02:16 <jralls> We'd have had to fix that because Mike Alexander builds 64-bit on top of MacPorts.
19:02:51 <jralls> Anyway, don't worry about it. It works fine now.
19:03:13 <codesmythe> OK. Thanks for setting me straight. :-)
19:29:18 *** mlncn has quit IRC
19:29:19 <jralls> codesmythe: I've encountered a serious weirdness on Windows yesterday and today. It looks like passing -D CMAKE_BUILD_TYPE=Release somehow causes swig to insert calls to pthreads_setspecific, which causes link failures because we're not using -lpthread. Setting -D CMAKE_BUILD_TYPE=Debug or leaving it unset doesn't create the problem.
19:40:13 <codesmythe> jralls: That is seriously weird indeed. Can't think of why that would happen.
19:49:49 <jralls> Even weirder, pthread_setspecific appears nowhere in the swig, cmake, gnome, or gnucash directories and only in threading-specific headers in mingw itself.
19:52:00 <codesmythe> jralls: so do calls to pthreads_specific show up in the generated C files?
19:52:40 <jralls> No. It just shows up at link time as a missing symbol.
19:57:53 <jralls> Eh, time to go make dinner. TTYL.
20:00:13 <codesmythe> See you later. I'm planning on firing up windows tomorrow to check my distcheck stuff, so I'll take a look then and see if I can come up with something.
20:05:38 *** User__ has joined #gnucash
20:08:53 *** User__ has quit IRC
20:32:58 *** federvie1 has joined #gnucash
20:35:02 *** federvieh has quit IRC
20:57:08 *** User_ has quit IRC
21:09:26 *** User has joined #gnucash
21:23:12 *** mlncn has joined #gnucash
22:10:20 *** mlncn has quit IRC
22:11:46 *** jotrago has quit IRC
22:16:59 *** codesmythe has left #gnucash
23:09:26 *** User has quit IRC