Re: pinfo -- release critical bug for amd64
[EMAIL PROTECTED] (Bob Proulx) writes: >> > 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. Any architecture with 2.6 kernel and enough ram. The internal timestamps have mikrosecond resolution while the on disk timestamps only seconds. I think amd64 is the only arch having 2.6.x on the buildd so far. > 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 The right thing to do is to add a "touch doc/pinfo.info" to debian rules or add a Build-Depends on makeinfo and NMU it. We know what is wrong, we know a trivial way to fix it. Why should we compromise? pinfo should be fixed or removed from sarge. I made the bug RC so the release team should do the right thing now. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pinfo -- release critical bug for amd64
Goswin von Brederlow wrote: > [EMAIL PROTECTED] (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' > > [EMAIL PROTECTED]:~/pinfo/pinfo-0.6.8$ ls -lh doc/pinfo.info > -rw-r--r-- 1 buildd buildd0 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 $@ [EMAIL PROTECTED] [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
Re: pinfo -- release critical bug for amd64
[EMAIL PROTECTED] (Bob Proulx) writes: > While walking through my list of things needed for amd64 I found that > 'pinfo' still is not fixed. The 'pinfo' package is not installable on > amd64 at this time. > > Previous discussion of this problem is here: > > http://lists.debian.org/debian-amd64/2005/01/msg00155.html > > It was determined at the time that there was a time skew bug that was > causing the build failure. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290618 > > 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. > > 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: [EMAIL PROTECTED]:~/pinfo/pinfo-0.6.8% grep makeinfo ../*build checking for working makeinfo... found && makeinfo `echo pinfo.texi | sed 's,.*/,,'` Same without makeinfo installed does use the missing script as far as I can tell, BUT: make[3]: Entering directory `/mnt/buildd/pinfo/pinfo-0.6.8/doc' cd . \ && /mnt/buildd/pinfo/pinfo-0.6.8/missing makeinfo `echo pinfo.texi | sed 's,.*/,,'` WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[3]: Leaving directory `/mnt/buildd/pinfo/pinfo-0.6.8/doc' [EMAIL PROTECTED]:~/pinfo/pinfo-0.6.8$ ls -lh doc/pinfo.info -rw-r--r-- 1 buildd buildd0 May 9 01:05 pinfo.info While it does not fail it it builds wrong. You can easily reproduce this by running "touch doc/pinfo.texi" before the build. > 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. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
