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