Neil L. Roeth wrote: > Examining the buildd logs showed it tried to run automake to build > [...] > But, *why* did this happen? I had created Makefile.in in the source > tree after aclocal.m4, so it was a *newer* file there and did not > trigger a call to automake on my build machine.
You asked the question. But then you supplied this answer. > Perhaps the problem is that both aclocal.m4 and Makefile.in are > unpacked from the source package in the order that they appear in > the .diff.gz file; Makefile.in is in the .diff.gz first, followed by > aclocal.m4. So the time ordering was reversed after the files were > created by patching .orig.tar.gz with .diff.gz, and automake got > invoked needlessly. That's my theory, feel free to point out any > stunningly obvious facts that I overlooked which make it invalid :-) Why do you think that you have not answered your own question? :-) I don't really know 100% but I am convinced within the limits of available data. I have created similar problems for myself because of the patch files. > What this does not explain is why it did not FTBFS on all > architectures. A guess. More likely is that perhaps those other architectures patch the files so fast that the resulting timestamp is all within the same second. Which make will accept as up to date. A race condition. If you try the same build enough times all would fail and pass at different times. It all depends on if it can complete within the same second or not if it crosses seconds. > I searched through one or two other logs of successful builds and > did not see any calls to automake, so somehow the dependency did not > trigger. Also, a build with pbuilder on my machine, i.e., a clean > environment, had no problem. If it is a race condition, all sources local to your machine, and you have a fast machine, then the odds are good the timestamp will be in the same second. It may be hard to generate a case which crosses the second boundary. I noticed that the machines that failed your build in the buildd logs were slower machines. If you were to build your own repository, 'apt-get source -b package' would you get the same problem? I always test that no since I added a configure script to a package which did not have one and the configure mode in my development directory was a+x but when created by patch it is not executable. I would never have caught that in my development area but only by fresh source build. > Unless you or someone else can tell me what is going on, and a better way to > fix it, I am inclined to go ahead and include automake in the build > dependencies. Put me in the camp that does not like AM_MAINTAINER_MODE. I would make the timestamps work correctly in the debian/rules file. That limits the ramifications. There are none outside of the debian build. My rules files have build: depend upon build-stamp: depend upon configure-stamp: and there I would touch the generated files in the right order. Or force them to be the same as a reference file timestamp. touch aclocal.m4 Makefile.in configure, I think. Since the patch process is changing the timestamps from what are in your sources it is necessary to force the timestamps back into the order they are in on the system when the patch was created. The actual values are not important but only the order. You may want to read some discussion on the subject of automake and timestamps here. http://mail.gnu.org/archive/html/automake/2003-02/msg00036.html Bob
pgpSWm7qMFafO.pgp
Description: PGP signature
