Add AM_MAINTAINER_MODE to your configure.in or configure.ac, or run ./configure --enable-maintainer-mode if your ./configure script supports it (which it probably does). yes, it's probably some weird timestamp issue or some other weirdness. It's not worth investigating, just do the above :) * Neil L. Roeth (neil@occamsrazor.net) wrote: > I am having a similar problem right now, and I was going to "solve" it by > adding automake to the build dependencies. > > I had to run automake on my source tree, and after uploading the changed > package, it FTBFS on some architectures, but not all. Examining the buildd > logs showed it tried to run automake to build Makefile.in, which has a make > dependency on Makefile.am and aclocal.m4. It failed to find automake and > died. The simple solution is to add automake to the build dependencies, which > you say should not be done. > > 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. However, the buildd make somehow thought the > Makefile.in was *older* than aclocal.m4, so it did trigger a call to automake > and failed when it could not find it. 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 :-) > > What this does not explain is why it did not FTBFS on all architectures. 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. > > 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. > > For reference, the buildd logs are here: > > http://buildd.debian.org/build.php?arch=&pkg=aplus-fsf > > and it is the -4 packages for which the above occurred. > > On Mar 12, Eric Dorland (eric@debian.org) wrote: > > As automake maintainer I'd just like to point out that build-depending > > on automake1.6 (any automake for that matter) is bad! Run automake on > > your source tree and ship the changed files in the diff.gz. > > > > * Jean-Michel Kelbert (kelbert@debian.org) wrote: > > > Hi, > > > > > > I recently upload to sid my new package : k3b. But I have forget to add > > > automake1.6 in Build-Depends. That's why I would like to made a new > > > release. However, I didn't manage to compile k3b from source ! But if I > > > apply the diff.gz patch to the upstream source. Then it works ! I didn't > > > unterstand why ! I made a diff -Naur from the two directory, and the > > > content is the same. Then I made a diff from the md5sum of each file in > > > the directory, and it is also the same ! That's why I don't understand > > > why it doesn't compile (with debuild) from the debian sources ! > > > > > > Thanks for your help. > > > > > > -- Eric Dorland <dorland@lords.com> ICQ: #61138586, Jabber: hooty@jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ ------END GEEK CODE BLOCK------
Attachment:
pgpMjODToqTPM.pgp
Description: PGP signature