I've been working on fixing an ftbfs for graphviz on natty:
The fundamental problem is that there are some hard-coded assumptions about
what Python versions are available, and those only go up to Python 2.6 (and
only to Python 2.5 in some file). While tedious and time consuming to track
down, I did manage to find all those spots and add Python 2.7 support. This
*should* only touch
but of course the various autobuild artifacts need updating as well. At first
I took a minimalist approach, running autoconf and automake manually, but then
I got failures because of aclocal.m4/libtool version mismatches. I tried
regenerating just aclocal.m4 and libltdl/aclocal.m4 but could not completely
eliminate the libtool errors. The build complained that libtool was at 2.2.6b
(the version in maverick, my development machine, and natty, my schroots), but
that aclocal.m4 wanted 2.2.6, even though I'd regenerated both aclocal.m4
files I could find.
So I bit the bullet and ran autoreconf. I'd avoided it earlier because it
touches about 100 files and I know how insane it is to try to review diffs
that modify a ton of generated files. Note however that all these generated
files are in the source package (and under bzr version control in the source
The good news is that with my changes and an autoreconf, the package builds.
So I'm looking for recommendations as to the best (or maybe least horrible)
way of dealing with this. Do I just close my eyes, stick my fingers in my
ears and submit changes with the autoreconf regenerated files?
When I submit the patches upstream, I'll likely narrow it down to just the .ac
and .am file changes (and the .install change to Debian). Then upstream can
do whatever autoreconf they want. But for now, how should this be handled in
Ubuntu and Debian?
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel