autoreconf advice

[Barry Warsaw]

I've been working on fixing an ftbfs for graphviz on natty:

https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/683182

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

configure.ac
debian/libgv-python.install
tcklpkg/Makefile.am
tclpkg/gv/Makefile.am

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
branches).

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?

Cheers,
-Barry

[Chow Loong Jin]

These days there's dh --with=autoreconf, and for CDBS users,
/usr/share/cdbs/1/rules/autoreconf.mk, which handle all the autoreconf stuff and
cleanup after without needing to commit a huge autoreconf patch into debian/patches.

Just build-depend on dh-autoreconf, and add the required stuff to debian/rules
and you should be done.

--
Kind regards,
Loong Jin

[Barry Warsaw]

On Dec 04, 2010, at 06:08 AM, Chow Loong Jin wrote:

>These days there's dh --with=autoreconf, and for CDBS users,
>/usr/share/cdbs/1/rules/autoreconf.mk, which handle all the autoreconf stuff and
>cleanup after without needing to commit a huge autoreconf patch into debian/patches.
>
>Just build-depend on dh-autoreconf, and add the required stuff to debian/rules
>and you should be done.

Nice. Thanks, I'll give that a try.

-Barry

[Barry Warsaw]

On Dec 04, 2010, at 06:08 AM, Chow Loong Jin wrote:

>These days there's dh --with=autoreconf, and for CDBS users,
>/usr/share/cdbs/1/rules/autoreconf.mk, which handle all the autoreconf stuff and
>cleanup after without needing to commit a huge autoreconf patch into debian/patches.
>
>Just build-depend on dh-autoreconf, and add the required stuff to debian/rules
>and you should be done.

Just to follow up. I ended up solving this by calling

dh_autoreconf autoreconf --

directly right before the configure call. The reason for being explicit is
that the -f -i options dh_autoreconf uses by default broke the build.

Thanks for the clue!
-Barry