Hi,
After quite a while being puzzled why my package, building fine on my
computer, failed to be build by my sponsor. Everything indicated
automake was being run, while it shouldn't.
It turned out, that 2.6.x kernels support mtimes of high precision
(nanoseconds rather than just seconds). Since in the diff file, the
Makefile.in was patched before the Makefile.am, the .am got a newer
mtime, and caused automake to be invoked. Swapping them around in the
diff solved this. On my 2.4.x kernel, this didn't happen, because both
were patched in the same second, but it always happened on my sponsor's
machine...
The issue here is, that it is very well possible that there are source
packages in the archive, which were never build by 2.6.x kernels, and
thus might very well contain the same miniscule timeskew problem.
What makes this problem extra hard to nail down, is that the order of
files in the diff matters, and this difforder is determined by the order
dentries are read. This can be different from fs to fs. It would be
cleaner if diffs supported mtime perservation. This could be
implemented very easily, since the mtime is already recorded in the
diff, so only modifications (optional flag which should be used by
dpkg-source -x) to `patch' are needed. However, this is definitely not a
good idea to do just before sarge, even though it might not break often,
it certainly will break sometimes.
Anybody time to rebuild the whole archive on a 2.6 kernel before sarge
gets released, to track down those FTBFSO2.6K[1] :)? I don't know HOW
much over-capacity there is for i386, and wether people think this is
worth the effort to check out? In the same time, you will catch also
binary i386 uploads which actually fail to build by themselves[2].
Since IMO all binary packages in the main section of the archive should
be autobuild, and none uploaded by maintainers, to make sure they match
the source, I personally would consider it good if it's done, if
feaseable.
--Jeroen
[1] ... On 2.6 Kernel
[2] Or are in somehow kernel-specific, so it is quite a rough sieve with
a very lot of false positives, making it of much less use for the
FTBFS-hunting cause[3]
[3] However it's interesting to know what packages have build problems
on 2.6.x kernels
--
Jeroen van Wolffelaar
+31-30-253 4499
Jeroen@A-Eskwadraat.nl
http://Jeroen.A-Eskwadraat.nl
Attachment:
pgpWRbs6366Tb.pgp
Description: PGP signature