I've been running it on both amd64 and x86 ever since I put it into portage. It's been running very well for me. I've asked the other arch teams to test it, but I'd like for x86 and amd64 to stable it please. Thanks!
The emerge runs fine, but it fails on tests: FAILURE xaccResolveFilePath test-resolve-file-path.c:81 /var/tmp/portage/gnucash-2.0.1/homedir/.gnucash/data/postgres:,,localhost,foo,bar (postgres://localhost/foo/bar) vs /root/.gnucash/data/postgres:,,localhost,foo,bar Executed 4 tests. There was 1 failure. With tests disabled everything goes well on amd64 and gnucash works nicely... emerge --info Portage 2.1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-suspend2-r4Dudebox-Edition x86_64) ================================================================= System uname: 2.6.17-suspend2-r4Dudebox-Edition x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.4 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -msse3 -Os -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -msse3 -Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distcc distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://server/gentoo-portage" USE="amd64 X alsa apache2 avi berkdb bitmap-fonts cairo cdr cli crypt cups dbus dlloader dri dvd dvdr eds emboss encode esd fam firefox fortran gcj gdbm gif gpm gstreamer gtk gtk2 hal imap isdnlog jpeg kde kdeenablefinal kdehiddenvisibility libg++ mad mikmod mp3 mpeg mysql ncurses nls nptl nptlonly objc objc++ ogg oss pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl sqlite ssl tcpd test truetype truetype-fonts type1-fonts udev unicode vorbis xml xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I've disabled the tests for now. Tester has filed a bug upstream about the broken test (it's the test itself that is broken). So please, arch teams, stable 2.0.1 on your platforms. Since ia64 and alpha only just added this to testing, we'll leave this bug open for the next 30 days for them.
dysblr
http://bugzilla.gnome.org/show_bug.cgi?id=354973 is the bug that Tester filed.
marked stable on x86, along with dev-perl/Finance-Quote-1.11. Closing bug.
keeping open for the next set of arches (in 28 days).
The postgresql-log seems not to be the problem. I ran with debugging turned on and I think I found the cause. First of all I see lots of: Error: gnc_iso8601_to_timespec_gmt(): unable to recover from buggy mktime Warning: gnc_iso8601_to_timespec_gmt(): mktime failed to handle daylight saving : tm_hour=-1 tm_year=70 tm_min=59 tm_sec=59 tm_isdst=-1 for string=1970-01-01 00 :59:59+01 Error: gnc_iso8601_to_timespec_gmt(): unable to recover from buggy mktime Warning: gnc_iso8601_to_timespec_gmt(): mktime failed to handle daylight saving : tm_hour=8 tm_year=3 tm_min=35 tm_sec=46 tm_isdst=-1 for string=1903-01-02 08:3 5:46.00 Error: gnc_iso8601_to_timespec_gmt(): unable to recover from buggy mktime Warning: gnc_iso8601_to_timespec_gmt(): mktime failed to handle daylight saving : tm_hour=-1 tm_year=70 tm_min=59 tm_sec=59 tm_isdst=-1 for string=1970-01-01 00 :59:59+01 Also I find pango-warnings on the console calling gnucash. When I try to make a booking I find in the gnucash trace: Error: gnc_iso8601_to_timespec_gmt(): unable to recover from buggy mktime Warning: trans_on_error(): Another user has modified this transaction just a moment ago. Please look at their changes, and try again, if needed. Error: xaccTransRollbackEdit(): Rollback Failed. Ouch!
Josh, from your comments in another bug, it sounded like you were associated with gnucash upstream. That being the case, I'd greatly appreciate your input here.
(In reply to comment #8) > Josh, from your comments in another bug, it sounded like you were associated > with gnucash upstream. That being the case, I'd greatly appreciate your input > here. [Yes, I am.] GnuCash doesn't really care to to support the postgres backend in 2.0, which I believe the errors in Comment #7 (which, really, seem to be closer to Bug#147736) are caused by. The erroring code is called from a couple of other places, but primarily by the PG backend. The PG backend has not supported the full feature set since 1.8.0, is not actively maintained by any current developer, and had almost bitrotted itself out of the source tree just before 2.0. The normal (XML-file) backend works very well. I suggest `ewarn`ing about this if the postgres USE flag is set (I humbly suggest stablization of 2.0.1.)
I'll open a new bug in a month for 2.0.1-r1 which does not even have postgresql support at all. Josh, would it not be wise for upstream to simply deprecate the configure option (or at least warn of its brokenness)?
