Re: bug closing etiquette
Ben Pfaff <blp@cs.stanford.edu> writes:
> Anyone have a suggestion about what to do when the maintainer
> can't reproduce it and the reporter can only reproduce it on one
> of his machines? I'm kind of stymied on #329333 for Autoconf.
> No idea what the problem is here.
Well, the problem is that for some reason when he builds the package when
automake1.8 is installed, it's trying to rebuild autoconf.in. This is
done with the rule:
$(srcdir)/autoconf.in: $(srcdir)/autoconf.as # FIXME: $(m4sh_m4f_dependencies)
$(AUTOM4SH) $(srcdir)/autoconf.as -o $@
which as you can see from the FIXME comment is buggy. Specifically, it's
missing a dependency on $(AUTOM4TE_CFG), so that command runs without
building the .cfg file first and then fails.
The mystery is that for some reason when automake1.8 is not installed,
make thinks (correctly) that autoconf.in is up to date and doesn't try to
rebuild it. I'm not seeing anything in the logs that would obviously
explain that. If it really happens only on his machine, I'd start
suspecting some sort of issue on that machine that caused file system
timestamps to be off.
The only connection that I can see to automake is that the build does
appear to try to run automake after running configure:
cd . && /bin/sh /source-etch/autoconf-2.59a/config/missing --run automake-1.7a --gnu
/source-etch/autoconf-2.59a/config/missing: line 52: automake-1.7a: command not found
WARNING: `automake-1.7a' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
but this fails in both build logs, so I don't see why one of them would
behave differently than the other. missing does touch files, but it only
touches Makefile.in so far as I can tell:
find . -type f -name Makefile.am -print |
sed 's/\.am$/.in/' |
while read f; do touch "$f"; done
Unless for some reason an additional dependency is being added to Makefile
when it's generated on his system, I'm mystified as to the difference.
I'd probably end up closing the bug as unreproducible and probably due to
something weird on his local system if the buildds are fine and no one
else is having trouble, but maybe someone will come up with a perceptive
analysis.
It's kind of annoying that Autoconf's build system tries to run Automake,
though. I wonder if that's fixable. If someone *does* have automake-1.7a
installed, they may not get the same build that everyone else gets.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Reply to: