Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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)?