GNOME Bugzilla – Bug 790845
2.7.3: massive test failures on some architectures
Last modified: 2018-06-30 00:01:11 UTC
Many tests fail in 2.7.1 on Debian: ~~~~ 20% tests passed, 85 tests failed out of 106 Total Test time (real) = 17.19 sec The following tests FAILED: 1 - test-exp-parser (Not Run) 2 - test-link-module-app-utils (Failed) 3 - test-print-parse-amount (Not Run) 4 - test-scm-query-string (Failed) 5 - test-sx (Not Run) 7 - test-app-utils (Failed) 8 - test-date-converting (Not Run) 9 - test-dom-converters1 (Not Run) 10 - test-kvp-frames (Not Run) 11 - test-load-backend (Not Run) 12 - test-load-xml2 (Failed) 13 - test-load-example-account (Failed) 14 - test-string-converters (Not Run) 15 - test-xml-account (Not Run) 16 - test-xml-commodity (Not Run) 17 - test-xml-pricedb (Not Run) 18 - test-xml-transaction (Not Run) 19 - test-xml2-is-file (Failed) 20 - test-real-data (Failed) 21 - test-backend-dbi (Not Run) 22 - test-column-types (Not Run) 23 - test-sqlbe (Not Run) 24 - test-gnc-glib-utils (Not Run) 25 - test-resolve-file-path (Not Run) 26 - test-userdata-dir (Not Run) 27 - test-userdata-dir-invalid-home (Not Run) 28 - test-link (Not Run) 29 - test-load-engine (Not Run) 30 - test-guid (Not Run) 31 - test-date (Not Run) 32 - test-object (Not Run) 33 - test-commodities (Not Run) 34 - test-qof (Not Run) 35 - test-engine (Not Run) 36 - test-account-object (Not Run) 37 - test-group-vs-book (Not Run) 38 - test-lots (Not Run) 39 - test-querynew (Not Run) 40 - test-query (Not Run) 41 - test-split-vs-account (Not Run) 42 - test-transaction-reversal (Not Run) 43 - test-transaction-voiding (Not Run) 44 - test-recurrence (Not Run) 45 - test-business (Not Run) 46 - test-address (Not Run) 47 - test-customer (Not Run) 48 - test-employee (Not Run) 49 - test-job (Not Run) 50 - test-vendor (Not Run) 51 - test-numeric (Not Run) 52 - test-gnc-guid (Not Run) 53 - test-kvp-value (Not Run) 54 - test-qofsession (Not Run) 55 - test-gnc-int128 (Not Run) 56 - test-gnc-rational (Not Run) 57 - test-gnc-numeric (Not Run) 58 - test-gnc-timezone (Not Run) 59 - test-gnc-datetime (Not Run) 60 - test-import-map (Not Run) 61 - test-scm-query (Failed) 66 - test-load-c (Failed) 68 - test-load-deps (Failed) 70 - test-scm-multi (Failed) 72 - test-modsysver (Failed) 73 - test-incompatdep (Failed) 74 - test-agedver (Failed) 75 - test-dynload (Failed) 76 - test-gwrapped-c (Failed) 77 - test-scm-module (Failed) 78 - test-link-module-tax-us (Not Run) 79 - test-link-module-gnome-utils (Failed) 81 - test-import-parse (Failed) 82 - test-link-generic-import (Not Run) 83 - test-import-pending-matches (Not Run) 84 - test-aqb (Failed) 85 - test-tokenizer (Failed) 86 - test-tx_import (Not Run) 87 - test-link-ofx (Not Run) 88 - test-link-qif-imp (Not Run) 89 - test-link-module-ledger-core (Not Run) 90 - test-link-module-register-core (Not Run) 91 - test-link-module-register-gnome (Not Run) 92 - test-link-module-report-locale-specific-us (Not Run) 93 - test-link-module-report-gnome (Failed) 95 - test-link-module-report-system (Failed) Errors while running CTest ~~~~ Most tests fail wish "Unable to find executable", for example /build/gnucash-2.7.1/obj-x86_64-linux-gnu/bin/test-exp-parser and indeed test executables are missing... Please advise.
I think you had an error earlier in the test. Perhaps run the build again then run the tests? There is currently a race condition in the build so that the build steps sometimes fail without good cause. It works best if you can rebuild without starting from scratch. That is, run make || make || make (or something like that). I think this pull request fixes the problem: https://github.com/Gnucash/gnucash/pull/178 but it was withdrawn because it wasn't a good design.
Also make sure to run `make check` rather than `make test`.
Thanks but none of those advises helped... I could not find an earlier error. Running tests again does not help (exactly the same number of tests fail for the same reason). Pull request needs some work since it causes FTBFS... I'll see if I can improve the patch. As for `make check` versus `make test` it makes no difference and I think the latter is the common way to test (at least this is what `dh_auto_test` uses by default). I hope you have more ideas. ;)
`make check` is the build target that builds all of the tests and dependencies and runs the tests. `make test` only runs some of the tests and doesn't make sure that they're all built. We followed autotools convention there; `make test` has never worked. N.B. Every single commit is built and tested on Travis, see https://travis-ci.org/Gnucash/gnucash/builds. It's possible that something is missing from the tarball that's causing trouble, but in general if Travis can do it you should be able to as well. Please do a clean build redirecting stdout and stderr into a file and attach the file after pasting your cmake, build, and test commands at the top of the file.
Based on comments on Bug 790550 this is mostly fixed with GnuCash 2.7.2, with only a couple of issues on python tests that I can duplicate and am working on. Is that correct?
Try http://downloads.sourceforge.net/gnucash/Development/gnucash-2.7.2.tar.bz2 It fixes for me the python testing problems on Debian 9.
Python testing is just a (small) part of the problem... There are still many tests failures on 2.7.2 just like on 2.7.1... Please see build log (mistakenly) attached to bug 790550. Thanks.
And here's the problem: "make -j1 test ARGS\+=-j1" I told you that that won't work. It hasn't worked on GnuCash at least since I began working on the project in 2009, and has probably *never* worked. I also see that you're trying to build GnuCash using your automated packaging tool. While that's no doubt your end goal, it's not something that we can help you with and it's greatly complicating your problems. Take this one step at a time. To convince yourself that GnuCash does in fact build and test, please start with a current Debian stable machine, run the apt-get commands that you'll find in util/ci/ubuntu-14.04-docker, untar the tarball, cd to your build directory, and run cmake -DWITH_PYTHON=ON /path/to/sourcedir && make && make check Once that works, do the same on Debian unstable to see if there are any more dependency incompatibilities. Once you have it building by hand *then* you're ready to try integrating it with your packaging tool... and beyond what we can help you with.
Please trust me, I did follow your advise and tried "make check" (and "make check" twice) which makes no difference whatsoever. Just gave you most recent build log. As for "never worked" I'm a bit sceptical since that's what we used since 2015 and exposed quite a few bugs. Regardless I'm happy top switch to "make check" but at the moment it is no better. It is not the "automated packaging tool" that I use to build GnuCash but Docker-like pristine environment (pbuilder) that allows me to produce reproducible builds and compare logs from different environments (e.g. stretch versus unstable). Also we use pbuilder to prepare official Debian packages. Problem is not in our tools but in new GnuCash build system...
> To convince yourself that GnuCash does in fact build and test... I do not know how to deal with denial... It builds but does not pass tests neither on "stable" nor on "unstable". Building "by hand" does not help. Attached build log _is_ from "stable". Building from checkout (instead of tarball) fails just the same. It is taking far too long to try building GnuCash in its current state... Maybe you could try to reproduce? Can you build and successfully test GnuCash 2.7.2 from tarball on Debian?
Please attach a build log, done by hand the way I instructed you, and showing that it fails when you run "make check". Yes, it builds and test for me on Debian 9. I made sure of that before I uploaded the tarball to SourceForge the other day. I also used Debian 9 to generate the release tarball (part of that process is to run check on the extracted tarball, but it doesn't turn on python bindings to do so, so I missed the Python failures. It also builds and tests on Fedora 26 and MacOS, and Travis builds and tests it successfully in Arch and Ubuntu dockers. Perhaps if you examine the build logs at https://travis-ci.org/Gnucash/gnucash/builds/307548781 you can see a difference with what you're doing. Although you might not be able to use it for your automated environment, ninja affords a several-x speedup over make, and CMake is about 3x faster than autotools. Your pbuilder setup spews a lot into the log (particularly compared to the docker environment on Travis) so I'd expect that to be a significant time sink as well.
Created attachment 364707 [details] Log file showing successful build and test on Debian 9 To show that GnuCash does build and test correctly on Debian 9 I've attached a build log. I built using the same CMake arguments I found in your earlier logfile. For testing I first ran "make test" to show that I get the same results you do when passing the wrong target, then ran "make check" to show successful compilation of all the test targets and a fully successful test suite.
Thanks. I much appreciate your continuous effort to address all the problems. I had a look at your build log but it is not very useful as there is no information about versions of installed packages or how build environment is configured. Your CI is not useful to me because there is no information how build environment is set. Anyway building on Ubuntu is like building on outdated Debian -- maybe it _was_ working in older environment but I need to deal with challenges of current environment... Why would one choose Ubuntu (Debian derivative) instead of Debian for CI environment I can not explain... We use verbose logs intentionally as they are useful for troubleshooting and log analysis software. Also comparing build logs are occasionally useful in which case the more information is captured the better. Anyway, I'm attaching verbose build log with complete commands including those that are required to prepare build environment. I hope you can make sense of it. I suspect that the culprit may be version of "googletest" package that provides "gtest" and "gmock" sources. We are using v1.8.0 which is most certainly newer than what you are using. One of the problem I've spotted is that some files are incorrectly installed to "/usr/libexec": * /usr/libexec/gnucash/libgnucash/engine/test/* * /usr/libexec/gnucash/overrides/gnucash-env * /usr/libexec/gnucash/overrides/gnucash-make-guids Also "make check" hilariously failed with "No rule to make target 'check'"...
Created attachment 364741 [details] more verbose build log
OK, I've made some progress by manually setting build directory for "make check": "make -C _build check" and it failed as follows even before tests: ~~~~ Scanning dependencies of target check-po make[5] Leaving directory '/build/gnucash-2.7.2/_build' /usr/bin/make -f po/CMakeFiles/check-po.dir/build.make po/CMakeFiles/check-po.dir/build make[5] Entering directory '/build/gnucash-2.7.2/_build' cd /build/gnucash-2.7.2/po && /usr/bin/cmake -D INTLTOOL_UPDATE=/usr/bin/intltool-update -D PO_DIR=/build/gnucash-2.7.2/po -P check-po.cmake The usage of POTFILES.ignore is deprecated. Please consider moving the content of this file to POTFILES.skip. The following files contain translations and are currently not in use. Please consider adding these to the POTFILES.in file, located in the po/ directory. __gtest/googlemock/src/gmock-spec-builders.cc __gtest/googlemock/test/gmock-matchers_test.cc __gtest/googletest/include/gtest/internal/gtest-filepath.h __gtest/googletest/src/gtest.cc __gtest/googletest/test/gtest-filepath_test.cc __gtest/googletest/test/gtest_catch_exceptions_test.py __gtest/googletest/test/gtest_unittest.cc share/gnucash/gtkbuilder/assistant-ab-initial.glade share/gnucash/gtkbuilder/assistant-acct-period.glade share/gnucash/gtkbuilder/assistant-csv-account-import.glade share/gnucash/gtkbuilder/assistant-csv-export.glade share/gnucash/gtkbuilder/assistant-csv-trans-import.glade share/gnucash/gtkbuilder/assistant-hierarchy.glade share/gnucash/gtkbuilder/assistant-loan.glade share/gnucash/gtkbuilder/assistant-qif-import.glade share/gnucash/gtkbuilder/assistant-stock-split.glade share/gnucash/gtkbuilder/assistant-xml-encoding.glade share/gnucash/gtkbuilder/business-prefs.glade share/gnucash/gtkbuilder/dialog-ab-pref.glade share/gnucash/gtkbuilder/dialog-ab.glade share/gnucash/gtkbuilder/dialog-account-picker.glade share/gnucash/gtkbuilder/dialog-account.glade share/gnucash/gtkbuilder/dialog-bi-import-gui.glade share/gnucash/gtkbuilder/dialog-billterms.glade share/gnucash/gtkbuilder/dialog-book-close.glade share/gnucash/gtkbuilder/dialog-choose-owner.glade share/gnucash/gtkbuilder/dialog-commodities.glade share/gnucash/gtkbuilder/dialog-commodity.glade share/gnucash/gtkbuilder/dialog-custom-report.glade share/gnucash/gtkbuilder/dialog-customer-import-gui.glade share/gnucash/gtkbuilder/dialog-customer.glade share/gnucash/gtkbuilder/dialog-date-close.glade share/gnucash/gtkbuilder/dialog-employee.glade share/gnucash/gtkbuilder/dialog-file-access.glade share/gnucash/gtkbuilder/dialog-fincalc.glade share/gnucash/gtkbuilder/dialog-find-account.glade share/gnucash/gtkbuilder/dialog-imap-editor.glade share/gnucash/gtkbuilder/dialog-import.glade share/gnucash/gtkbuilder/dialog-invoice.glade share/gnucash/gtkbuilder/dialog-job.glade share/gnucash/gtkbuilder/dialog-lot-viewer.glade share/gnucash/gtkbuilder/dialog-new-user.glade share/gnucash/gtkbuilder/dialog-object-references.glade share/gnucash/gtkbuilder/dialog-options.glade share/gnucash/gtkbuilder/dialog-order.glade share/gnucash/gtkbuilder/dialog-payment.glade share/gnucash/gtkbuilder/dialog-preferences.glade share/gnucash/gtkbuilder/dialog-price.glade share/gnucash/gtkbuilder/dialog-print-check.glade share/gnucash/gtkbuilder/dialog-progress.glade share/gnucash/gtkbuilder/dialog-query-view.glade share/gnucash/gtkbuilder/dialog-report.glade share/gnucash/gtkbuilder/dialog-reset-warnings.glade share/gnucash/gtkbuilder/dialog-search.c share/gnucash/gtkbuilder/dialog-search.glade share/gnucash/gtkbuilder/dialog-sx.glade share/gnucash/gtkbuilder/dialog-tax-info.glade share/gnucash/gtkbuilder/dialog-tax-table.glade share/gnucash/gtkbuilder/dialog-totd.glade share/gnucash/gtkbuilder/dialog-trans-assoc.glade share/gnucash/gtkbuilder/dialog-transfer.glade share/gnucash/gtkbuilder/dialog-userpass.glade share/gnucash/gtkbuilder/dialog-vendor.glade share/gnucash/gtkbuilder/gnc-date-format.glade share/gnucash/gtkbuilder/gnc-frequency.glade share/gnucash/gtkbuilder/gnc-plugin-page-budget.glade share/gnucash/gtkbuilder/gnc-plugin-page-register.glade share/gnucash/gtkbuilder/gnc-plugin-page-register2.glade share/gnucash/gtkbuilder/gnc-recurrence.glade share/gnucash/gtkbuilder/gnc-tree-view-owner.glade share/gnucash/gtkbuilder/search-account.c share/gnucash/gtkbuilder/search-date.c share/gnucash/gtkbuilder/search-double.c share/gnucash/gtkbuilder/search-int64.c share/gnucash/gtkbuilder/search-numeric.c share/gnucash/gtkbuilder/search-reconciled.c share/gnucash/gtkbuilder/search-string.c share/gnucash/gtkbuilder/window-autoclear.glade share/gnucash/gtkbuilder/window-reconcile.glade share/gnucash/scm/gnucash/report/aging.scm share/gnucash/scm/gnucash/report/balsheet-eg.scm share/gnucash/scm/gnucash/report/customer-summary.scm share/gnucash/scm/gnucash/report/easy-invoice.scm share/gnucash/scm/gnucash/report/fancy-invoice.scm share/gnucash/scm/gnucash/report/hello-world.scm share/gnucash/scm/gnucash/report/invoice.scm share/gnucash/scm/gnucash/report/job-report.scm share/gnucash/scm/gnucash/report/owner-report.scm share/gnucash/scm/gnucash/report/payables.scm share/gnucash/scm/gnucash/report/receipt.scm share/gnucash/scm/gnucash/report/receivables.scm share/gnucash/scm/gnucash/report/standard-reports/account-piecharts.scm share/gnucash/scm/gnucash/report/standard-reports/account-summary.scm share/gnucash/scm/gnucash/report/standard-reports/advanced-portfolio.scm share/gnucash/scm/gnucash/report/standard-reports/average-balance.scm share/gnucash/scm/gnucash/report/standard-reports/balance-sheet.scm share/gnucash/scm/gnucash/report/standard-reports/budget-balance-sheet.scm share/gnucash/scm/gnucash/report/standard-reports/budget-barchart.scm share/gnucash/scm/gnucash/report/standard-reports/budget-flow.scm share/gnucash/scm/gnucash/report/standard-reports/budget-income-statement.scm share/gnucash/scm/gnucash/report/standard-reports/budget.scm share/gnucash/scm/gnucash/report/standard-reports/cash-flow.scm share/gnucash/scm/gnucash/report/standard-reports/cashflow-barchart.scm share/gnucash/scm/gnucash/report/standard-reports/category-barchart.scm share/gnucash/scm/gnucash/report/standard-reports/daily-reports.scm share/gnucash/scm/gnucash/report/standard-reports/equity-statement.scm share/gnucash/scm/gnucash/report/standard-reports/general-journal.scm share/gnucash/scm/gnucash/report/standard-reports/general-ledger.scm share/gnucash/scm/gnucash/report/standard-reports/income-gst-statement.scm share/gnucash/scm/gnucash/report/standard-reports/income-statement.scm share/gnucash/scm/gnucash/report/standard-reports/net-barchart.scm share/gnucash/scm/gnucash/report/standard-reports/net-linechart.scm share/gnucash/scm/gnucash/report/standard-reports/portfolio.scm share/gnucash/scm/gnucash/report/standard-reports/price-scatter.scm share/gnucash/scm/gnucash/report/standard-reports/register.scm share/gnucash/scm/gnucash/report/standard-reports/sx-summary.scm share/gnucash/scm/gnucash/report/standard-reports/transaction.scm share/gnucash/scm/gnucash/report/standard-reports/trial-balance.scm share/gnucash/scm/gnucash/report/stylesheet-easy.scm share/gnucash/scm/gnucash/report/stylesheet-fancy.scm share/gnucash/scm/gnucash/report/stylesheet-footer.scm share/gnucash/scm/gnucash/report/stylesheet-head-or-tail.scm share/gnucash/scm/gnucash/report/stylesheet-plain.scm share/gnucash/scm/gnucash/report/taxinvoice.scm share/gnucash/scm/gnucash/report/view-column.scm share/gnucash/scm/gnucash/report/welcome-to-gnucash.scm If some of these files are left out on purpose then please add them to POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list of left out files has been written in the current directory. Please report to https://bugzilla.gnome.org/page.cgi?id=browse.html&product=GnuCash CMake Error at check-po.cmake:22 (MESSAGE): POTFILES.in is missing files. See 'missing' in /build/gnucash-2.7.2/po ~~~~ Any ideas?
After adding those files to "po/POTFILES.skip" tests progressed further yet two tests failed: ~~~~ 98% tests passed, 2 tests failed out of 105 Total Test time (real) = 46.34 sec The following tests FAILED: 34 - test-qof (OTHER_FAULT) 59 - test-gnc-datetime (Failed) ~~~~ "test-gnc-datetime" fails consistently in "Stretch" and "unstable" while "test-qof" sometimes passes...
Another unstable test: 35 - test-engine (OTHER_FAULT)
Tests are time zone sensitive. For example TZ=UTC-11 faketime 2008-12-24 08:55:42 /usr/bin/make -C _build check The following tests FAILED: 21 - test-backend-dbi (OTHER_FAULT) 31 - test-date (Failed) 34 - test-qof (OTHER_FAULT) 35 - test-engine (OTHER_FAULT) 59 - test-gnc-datetime (Failed) 97 - test-cash-flow (Failed) 98 - test-cashflow-barchart (Failed) 99 - test-standard-category-report (Failed) 100 - test-standard-net-barchart (Failed) 101 - test-standard-net-linechart (Failed)
> OK, I've made some progress by manually setting build directory for "make check": "make -C _build check" and it failed as follows even before tests: That's interesting, but why would you expect to be able to run make anything from outside of the build dir? The POTFILES problem is an artifact of the way msgmerge searches for files with translatable strings. The usual workaround is to have the build directory outside the source tree so that mesgmerge won't recurse into it, but it also works to make the build directory hidden--e.g. naming it .build instead of _build--accomplishes the same thing. This behavior isn't unique to CMake nor is it new in 2.7. The TZ issue is also not new, though there are progressively more failures as we add more time-related tests. The timezone sensitive tests work in TZ=PST8PDT because that's my timezone and I wrote the first time-sensitive tests. I suppose it would be better to have those tests setenv("TZ", "PST8PDT", 1) or for the cases outside of the GncDateTime unit tests calculate the expected value based on the existing TZ. If you run `TZ=PST8PDT make -C _build check` do all tests pass?
(In reply to John Ralls from comment #4) > N.B. Every single commit is built and tested on Travis, see > https://travis-ci.org/Gnucash/gnucash/builds. It's possible that something > is missing from the tarball that's causing trouble, but in general if Travis > can do it you should be able to as well. Just to nitpick: not every single commit is built and tested on Travis. Only the last commit of each push to the repo or each PR is. Intermediate commits may have build failures. Not really relevant to the rest of this bug report though...
> why would you expect to be able to run make anything from outside of the build dir? My mistake obviously. Working late, being tired... Many thanks for hint about hidden build directory -- renaming "_build" to ".build" helped. > If you run `TZ=PST8PDT make -C _build check` do all tests pass? Yes and it seems to be the only time zone that makes all tests happy. I tried 24(!) different time zones only to find that some tests are failing in all time zones that I tried except "PST8PDT". Debian QA routinely re-build packages in different time zones so those failures would have been exposed...
I have a vague sense of deja-vue over the TZ testing issue, likely bug 774237 or bug 771617; maybe some changes didn't merge correctly and it's at least partly a regression. I'll have a go at making at least most of the tests more timezone-independent and see what can be done about the GncDateTime tests so that they'll pass regardless of the environment's TZ. In the meantime Geert, Rob Gowin, and I did some bashing on the ramifications of implementing GNUInstallDirs. It actually broke most of the module loading, so even though it built and (finally!) passed the tests for you it wouldn't have worked. https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2._just_for_dmitry_number_4tar.bz2/download is the fruit of that effort. We've also gotten rid of the extraneous files that were installed in libexec. BTW, the two script files, gnucash-env and gnucash-make-guids, had been there for a very long time and you never noticed before. No matter, they're pretty much obsolete now so we removed them.
Oops, missed one. You want https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2_just_for_dmitry_number_5.tar.bz2/download now.
Thanks, John. You are champion. We are getting somewhere with build and packaging. :) Tests are more fragile than I thought: today the following tests are failing for me even in "PST8PDT" time zone: ~~~~ The following tests FAILED: 7 - test-app-utils (Failed) 11 - test-load-backend (Failed) 12 - test-load-xml2 (Failed) 21 - test-backend-dbi (OTHER_FAULT) 84 - test-aqb (Failed) ~~~~
Is the build directory preserved in your system? If so, could you attach Testing/Temporary/LastTest.log?
Oh, and do you know what you did different from the passing run? There's another oh-by-the-way: As you've probably figured out, GnuCash dlopens stuff a lot. The searches for libraries to dlopen seem to look in installation directories before they look in build directories so compiling different versions from what's installed can often produce weird results. I'd expect that using a DESTDIR when installing would prevent that, but you might check to make sure that it's not causing you problems.
Never mind about the failures. I discovered that those tests fail when GnuCash can't find the backend modules libgncmod-backend-dbi.so and libgncmod-backend-xml.so. I think I've fixed that, so try https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2_just_for_dimitry_number_6.tar.bz2/download.
I've worked through all of the tests with time zone sensitivity and fixed them so that they all pass for all timezones in /usr/share/zoneinfo. The updated tarball is at https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2_just_for_dimitry_number_7.tar.bz2/download.
Thanks. I've just tried "number_7" tarball but it FTBFS even before tests as follows: ~~~~ cd /build/gnucash-2.7.2/.build/libgnucash/app-utils && /usr/bin/cmake -E env LD_LIBRARY_PATH=/build/gnucash-2.7.2/.build//lib/x86_64-linux-gnu/gnucash:/build/gnucash-2.7.2/.build//lib/x86_64-linux-gnu/gnucash/gnucash: GNC_UNINSTALLED=YES GNC_BUILDDIR=/build/gnucash-2.7.2/.build GUILE_LOAD_PATH=/build/gnucash-2.7.2/libgnucash/app-utils GUILE_LOAD_COMPILED_PATH=/build/gnucash-2.7.2/.build//lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.0 GNC_MODULE_PATH=/build/gnucash-2.7.2/.build//lib/x86_64-linux-gnu/gnucash:/build/gnucash-2.7.2/.build//lib/x86_64-linux-gnu/gnucash/gnucash: /usr/bin/guile -e '(@@ (guild) main)' -s /usr/bin/guild compile -o /build/gnucash-2.7.2/.build//lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.0/gnucash/gettext.go /build/gnucash-2.7.2/libgnucash/app-utils/gettext.scm terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::gregorian::bad_year> >' what(): Year is out of valid range: 1400..10000 Child aborted libgnucash/app-utils/CMakeFiles/scm-gettext.dir/build.make:64: recipe for target 'lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.0/gnucash/gettext.go' failed make[3] *** [lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.0/gnucash/gettext.go] Error 1 ~~~~
That's weird. What timezone is the build machine set for?
UTC ("Etc/UTC" to be precise). I've reproduced FTBFS in clean build environments on "Stretch" and "unstable". What's weird is that it did not FTBFS in "Australia/Sydney"...
Aha! Yes, I can replicate it now, though it failed for me building unittest-support.scm instead of gettext.scm.
Easily fixed once I could reproduce it. I hadn't handled correctly the case where the zone file has no transitions. Not surprisingly boost::date_time objects to requesting the date for "not-a-date-time". https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2_just_for_dmitry_number_8.tar.bz2/download
Much better, thank you. :) FTBFS is fixed but I can still trip some tests by manipulating time zone. For example: TZ=UTC-1 /usr/bin/make -C .build check ~~~~ 99% tests passed, 1 tests failed out of 105 Total Test time (real) = 36.23 sec The following tests FAILED: 35 - test-qof (OTHER_FAULT) ~~~~ --- TZ=UTC-1 faketime 2008-12-24 08:55:42 /usr/bin/make -C .build check ~~~~ 98% tests passed, 2 tests failed out of 105 Total Test time (real) = 36.45 sec The following tests FAILED: 35 - test-qof (OTHER_FAULT) 36 - test-engine (OTHER_FAULT) ~~~~ I'm sure you can find more failures by using something like the following script: set -ex ;\ for T in -1 +1 -2 +2 -3 +3 -4 +4 -5 +5 -6 +6 -7 +7 -8 +8 -9 +9 -10 +10 -11 +11 -12 +12; do \ TZ="UTC$$T" $(MAKE) -C .build check ;\ done
That's because "UTC-1" is recognized by GnuCash but not by libc, and some of the tests use libc functions to generate the "correct" answer. If you make it "Etc/UTC-!" it should work.
Sensational. :) All tests passed when TZ is set as "Etc/UTC$T". I'll double check everything but it already looks like we're all good for 2.7.3. Well done, John. Thank you very much for diligence and effort. Though I did managed to trigger (one last) test failure using "faketime": ~~~~ TZ=Etc/UTC-1 faketime 2008-12-24 08:55:42 /usr/bin/make -C .build check 99% tests passed, 1 tests failed out of 105 Total Test time (real) = 40.94 sec The following tests FAILED: 36 - test-engine (OTHER_FAULT) ~~~~
That would be because it's testing the pricedb with prices created for dates between May 2007 and November 2014, and expecting that the test will be run after 2014. Running tests before the test was written isn't generally a design consideration. Why would you expect it to be?
Oh, and interestingly I gave you slightly incorrect advice in comment 35: The zones in /usr/share/zoneinfo/Etc are named "GMTxx", not "UTCxx", on MacOS, Debian-9, and Fedora-26. You must have some additional aliases if UTCxx worked for you; are those something you added yourself or are they a new feature of Debian-unstable?
I usually build in clean environment so I certainly did not add any zones... It must be a feature of "tzdata" and probably an old one. So I've changed zone to "Etc/GMT-$T" and moved "faketime" to the and of 2014: ~~~~ TZ=Etc/GMT+12 faketime 2014-12-24 08:55:42 /usr/bin/make -C .build check 99% tests passed, 1 tests failed out of 105 Total Test time (real) = 37.14 sec The following tests FAILED: 60 - test-gnc-datetime (Failed) ~~~~
Well, that one was easy. Doesn't have anything to do with faketime, 12 Noon GMT is midnight of the same day in +12 (The signs are backwards, GMT+12 is the eastern side of the international date line so its actual offset is -12*3600). https://sourceforge.net/projects/gnucash/files/Development/gnucash-2.7.2_just_for_dmitry_number_9.tar.bz2/download for the fix.
Awesome. :) All tests passed in all time zones. :) Congratulations.
Yay!
Although we're all good on x86_64 some tests are still failing on some architectures: https://buildd.debian.org/status/package.php?p=gnucash&suite=experimental For instance on x86_32 (a.k.a. "i386"): The following tests FAILED: 21 - test-backend-dbi (SEGFAULT) 58 - test-gnc-numeric (Failed) 59 - test-gnc-timezone (Failed) 105 - python-bindings (Failed) See build log here: https://buildd.debian.org/status/fetch.php?pkg=gnucash&arch=i386&ver=1%3A2.7.3-1&stamp=1515361241&raw=0 John, could you please have a look? Thanks.
I have no way to test anything on architectures other than x86_64 and i386. If Debian wants to support those architectures they're going to have to find some voluteers to write patches. I'm struggling with the segfault in test-backend-dbi, actually in g_object_set(lot, "is-closed", -1, NULL), meaning that it seems very much to be a glib2.0 bug, not a GnuCash one. Fails on both Debian 9 and Fedora27. The test-gnc-numeric failure doesn't happen for me on Debian 9. Fedora 27 gets an exception "locale::facet::_S_create_c_locale name not valid", but that might be because I don't have the right language pack installed. Can you look at the file Testing/Temporary/LastTest.log to see if that's the error you got? test-gnc-timezone seems to be a difference in zonefiles between the two architectures and python-bindings is a type mismatch. Both of those will be easy to fix.
Same here, I have only x86 hardware but often build failures on other architectures are due to endian-ness or integer size... We need to make sure that GnuCash builds at least on all official architectures or it may not enter "testing". Some arch-specific FTBFS are usually addressed by porters who are familiar with specific problems. Eventually we may get some help with non-trivial cases (if any). 58 - test-gnc-numeric fails every time for me on all environments where I tried. This if what I've found in ".build/Testing/Temporary/LastTest.log": ~~~~ 58/105 Testing: test-gnc-numeric 58/105 Test: test-gnc-numeric Command: "/home/onlyjob/dev/DEB/gnucash/gnucash-2.7.3/.build/bin/test-gnc-numeric" Directory: /home/onlyjob/dev/DEB/gnucash/gnucash-2.7.3/.build/libgnucash/engine/test "test-gnc-numeric" start time: Jan 12 13:11 AEDT Output: ---------------------------------------------------------- Running main() from gtest_main.cc [==========] Running 22 tests from 6 test cases. [----------] Global test environment set-up. [----------] 7 tests from gncnumeric_constructors [ RUN ] gncnumeric_constructors.test_default_constructor [ OK ] gncnumeric_constructors.test_default_constructor (0 ms) [ RUN ] gncnumeric_constructors.test_gnc_rational_constructor [ OK ] gncnumeric_constructors.test_gnc_rational_constructor (0 ms) [ RUN ] gncnumeric_constructors.test_gnc_numeric_constructor [ OK ] gncnumeric_constructors.test_gnc_numeric_constructor (0 ms) [ RUN ] gncnumeric_constructors.test_int64_constructor [ OK ] gncnumeric_constructors.test_int64_constructor (0 ms) [ RUN ] gncnumeric_constructors.test_implicit_int_constructor [ OK ] gncnumeric_constructors.test_implicit_int_constructor (0 ms) [ RUN ] gncnumeric_constructors.test_double_constructor [ OK ] gncnumeric_constructors.test_double_constructor (0 ms) [ RUN ] gncnumeric_constructors.test_string_constructor [ OK ] gncnumeric_constructors.test_string_constructor (1 ms) [----------] 7 tests from gncnumeric_constructors (1 ms total) [----------] 1 test from gncnumeric_output [ RUN ] gncnumeric_output.string_output [ OK ] gncnumeric_output.string_output (0 ms) [----------] 1 test from gncnumeric_output (0 ms total) [----------] 2 tests from gncnumeric_stream [ RUN ] gncnumeric_stream.output_stream [ OK ] gncnumeric_stream.output_stream (11 ms) [ RUN ] gncnumeric_stream.input_stream [ OK ] gncnumeric_stream.input_stream (0 ms) [----------] 2 tests from gncnumeric_stream (11 ms total) [----------] 6 tests from gncnumeric_operators [ RUN ] gncnumeric_operators.gnc_numeric_conversion [ OK ] gncnumeric_operators.gnc_numeric_conversion (0 ms) [ RUN ] gncnumeric_operators.double_conversion /home/onlyjob/dev/DEB/gnucash/gnucash-2.7.3/libgnucash/engine/test/gtest-gnc-numeric.cpp:296: Failure Expected: 12500.687424058324 Which is: 12500.7 To be equal to: b Which is: 12500.7 [ FAILED ] gncnumeric_operators.double_conversion (0 ms) [ RUN ] gncnumeric_operators.test_addition [ OK ] gncnumeric_operators.test_addition (0 ms) [ RUN ] gncnumeric_operators.test_subtraction [ OK ] gncnumeric_operators.test_subtraction (0 ms) [ RUN ] gncnumeric_operators.test_multiplication [ OK ] gncnumeric_operators.test_multiplication (1 ms) [ RUN ] gncnumeric_operators.test_division [ OK ] gncnumeric_operators.test_division (0 ms) [----------] 6 tests from gncnumeric_operators (1 ms total) [----------] 4 tests from gncnumeric_functions [ RUN ] gncnumeric_functions.test_cmp [ OK ] gncnumeric_functions.test_cmp (0 ms) [ RUN ] gncnumeric_functions.test_invert [ OK ] gncnumeric_functions.test_invert (0 ms) [ RUN ] gncnumeric_functions.test_reduce [ OK ] gncnumeric_functions.test_reduce (0 ms) [ RUN ] gncnumeric_functions.test_convert [ OK ] gncnumeric_functions.test_convert (0 ms) [----------] 4 tests from gncnumeric_functions (0 ms total) [----------] 2 tests from gnc_numeric_functions [ RUN ] gnc_numeric_functions.test_is_decimal [ OK ] gnc_numeric_functions.test_is_decimal (0 ms) [ RUN ] gnc_numeric_functions.test_conversion_to_decimal [ OK ] gnc_numeric_functions.test_conversion_to_decimal (0 ms) [----------] 2 tests from gnc_numeric_functions (0 ms total) [----------] Global test environment tear-down [==========] 22 tests from 6 test cases ran. (13 ms total) [ PASSED ] 21 tests. [ FAILED ] 1 test, listed below: [ FAILED ] gncnumeric_operators.double_conversion 1 FAILED TEST <end of output> Test time = 0.05 sec ---------------------------------------------------------- Test Failed. "test-gnc-numeric" end time: Jan 12 13:11 AEDT "test-gnc-numeric" time elapsed: 00:00:00 ---------------------------------------------------------- ~~~~
OK. Does "official architectures" mean the 10 OSes listed on https://www.debian.org/releases/stable/i386/ch02s01.html.en? The assert on test-gnc-numeric.cpp line 296 should probably be EXPECT_DOUBLE_EQ(12500.687424058324, b); but rounding to 6 figures seems a bit odd. Do you get the same result on up to date Debian 9-32? I spent some quality time with the debugger today and figured out that the crash in test-backend-dbi is really in g_object_get_valist due to G_VALUE_COLLECT_INIT (&value, pspec->value_type, var_args, 0, &error); seeming to not call va_arg() so that name = va_arg (var_args, gchar*); sets name to the first value instead of to the second name. I still don't understand why not nor why it (at least seems) to work in 64-bit and not in 32-bit.
Thanks for looking into the problem. I usually learn about supported architectures for the upcoming release from page like [1] where first 10 real architectures after "all" are colored bright green to highlight their importance over the rest of architectures that are "shaded" (e.g. not production ready, etc.)... As you can see GnuCash 2.6 builds successfully on most architectures and I believe we should be able to build 2.7 just as well... I've committed a change [2] that prints contents of "LastTest.log" if any tests fail -- I hope that would help us to troubleshoot failures from build logs. [1]: https://buildd.debian.org/status/package.php?p=gnucash&suite=unstable [2]: https://anonscm.debian.org/cgit/pkg-gnucash/gnucash.git/commit/?h=experimental&id=e706d64c
That will be helpful for the ones that fail tests. Unfortunately that's only the two ARMs, one of the mips (mipsel), i386, and x32. All but one of the rest segfaulted in Guile trying to compile unittest-support.scm. The one exception, ppc64, segfaulted in gcc trying to compile libgnucash/app-utils/gnc-state.c.
I'll try to switch to Guile-2.2 with next upload as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885204 Let's see how it goes...
I've pushed fixes for all of the failures except gnc-numeric. The crash turned out to be because the database code retrieves an int as an int64_t (a.k.a. a long long) and it was getting put on the stack that way, but it was declared to var_args as an int so the first call to va_arg() incremented only the first word, leaving the second to be retrieved by the next va_arg(). I don't know what to do about the gnc-numeric problem. The code that returns 12500.7 on your i386 and mipsel builds is: GncNumeric::operator double() const noexcept { return static_cast<double>(m_num) / static_cast<double>(m_den); } A moment with a calculator will show that the correct value is indeed 12500.687424058324 and that the compiler on those two platforms is performing an unexpected rounding to get 12500.7.
I'm going to release 2.7.4 in the next few hours, so let's start a new bug for it.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=790845. Please update any external references or bookmarks.