Steve Langasek <[EMAIL PROTECTED]> writes: > That would be RC bug #295175 in the xfree86-common package. I don't imagine > gnucash would've fared any better under these circumstances without the > libtool update, either.
Ah, ok! I'm glad you are up on these things; I would not have guessde to look there. I'll just wait until that gets into unstable on all the arch's and then maybe we can see what gnucash problems remain. > Though it might be nice if gnucash's configure script called, and used the > output from, the AC_PATH_X macro if it's going to be including X11/Xlib.h > (and why does a GNOME application need to directly include X headers, > anyway?). See, gnucash is big and complicated. :) gnucash installs its own Xlib error handler. > Yes, libtool updates are not as nice as they ought to be -- frequently > complicated by upstreams' use of questionable practices where autoconf > macros (aclocal.m4) are concerned. I still haven't gotten gnucash playing > nicely with libtool 1.5, FWIW, after several iterations... Thanks for trying. :) Maybe once the xfree86-common problems are stamped out by Branden, gnucash 1.8.10-7 won't have a severe an issue with the older libtool. Upstream reports that no 1.8 releases should be expected for things like the build system; 1.8.10 was a data corruption bug and 1.8.11 was to fix a release engineering mistake in 1.8.10 (already corrected in the Debian package, so I haven't bothered with 1.8.11). The gnome-2 branch of gnucash is still nowhere near ready; release is expected "later this year". It is possible that these problems will stymie work on 1.8.10 for Debian, at least, not before sarge release. If that's true, I can hobble together an interim version based on the old version in woody, which backports the important bugfixes since then, but I would rather avoid such a procedure if possible. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
