Goswin von Brederlow wrote:
> bob@proulx.com (Bob Proulx) writes:
> > But now that I am looking at the package in more detail I am not
> > convinced that this problem is the same as the file skew problem. The
> > diff.gz does patch both the pinfo.info and pinfo.texi files. A time
> > skew could cause makeinfo (not declared as a dependency) to be called
> > to update the file. But if that happens the 'missing' program would
> > be called wrapping it and preventing this call from failing the
> > build.
>
> I just did a testbuild and look what I found:
>
> make[3]: Leaving directory `/mnt/buildd/pinfo/pinfo-0.6.8/doc'
>
> buildd@frosties:~/pinfo/pinfo-0.6.8$ ls -lh doc/pinfo.info
> -rw-r--r-- 1 buildd buildd 0 May 9 01:05 pinfo.info
I did several builds in different ways before I posted my note. I had
done a build without makeinfo installed and had seen the missing
script triggered. I would have sworn that I had covered this case and
had seen that the pinfo.info file was not munged when makeinfo was
missing.
Seeing your result caused me to go through and run all of my testing
again. I was mistaken before. Because if makeinfo is not installed
then the pinfo.info file is zerod out. I can recreate the case now.
I don't know why I did not see this before.
> While it does not fail it it builds wrong. You can easily reproduce
> this by running "touch doc/pinfo.texi" before the build.
I actually did that in my testing before posting my previous note.
Grrr... I must have mixed up my test cases.
> > I am now thinking that the problem was a disk space problem on the
> > build machine when this was autobuilt for amd64. I think the patched
>
> No, timestamp still makes it break.
Note that I never said there was not a file timestamp skew problem in
the package. There clearly is one. I was just thinking it was not
this particular problem at this time. Because I was thinking that I
was able to build with the touch of pinfo.texi and was still able to
get a reasonable pinfo.info file out. Unfortunately I was wrong.
I dug into this further and the root of the problem is the automake
generated Makefile rules here:
.texi.info:
@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9]
cd $(srcdir) \
&& $(MAKEINFO) `echo $< | sed 's,.*/,,'`
The "rm -f $@" removes the file before calling makeinfo. So even
though makeinfo is a noop it is already too late and the file is
removed.
> > At the time it seemed reasonable to wait for the maintainer to react
> > to the bug and to upload a fixed version. After 113 days that does
> > not seem to be going to happen in time for sarge.
Okay, so we are still left with what to do about this problem. What
is the solution? It is a bug that can potentially cause FTBFS on any
given architecture. Certainly the .deb package built for amd64 has
hit this problem.
However I downloaded the .deb file for every Debian supported
architecture and all of them apparently built without hitting this
problem. It looks like amd64 just came up lucky. This was probably
also helped along by the fact that the other systems build on
filesystems with one second resolutions but I am guessing that amd64
built on a filesystem with microsecond resolution.
Because we want amd64 to stay in sync with Debian sarge as much as
possible I still propose that the package be re-queued to build again.
The odds are reasonable that it will build correctly regardless of
this package filestamp bug. Then we will have a good working package
for amd64 and will remain in sync with sarge. And there is still the
bug against the mainstream Debian package so this bug won't get lost.
Sound good?
Bob
Attachment:
signature.asc
Description: Digital signature