[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pinfo -- release critical bug for amd64

bob@proulx.com (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.


Reply to: