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.
MfG
Goswin
Reply to: