Re: buildd failures for amd64?
On Thu, Jul 20, 2006 at 01:53:54PM +0200, Joost Witteveen wrote:
>
> Yes. Although most packages are available for amd64, whenever I noticed
> an unavailable package, I could manually build it without any changes.
Can you give me any list of packages that we should build, are
unavailable, and don't have an RC bug open that it failed to
build?
Note that some of the problems might be temporary, because they
were caused by an other package. In those cases, it can be just
retried. I currently don't know any of those types.
Some might be caused by missing build dependencies, and when you
try it you have them installed while the buildd didn't.
Other might for instance be caused by incorrect build
depedencies, where it needed a newer version of it's build
dependency, that wasn't in the archive at the moment it was tried
but is now. In this case, it's a bug in the package where it
should actually specifiy a correct versioned build dependency.
Even though we could build it at a later time, we don't, and
expect the maintainer to upload a new version with that bug
fixed.
Yet an other type of bug might be some race condition, that
happens to trigger on the buildd but doesn't happen on your host.
For instance, the latest version of tar was unavailable because
of that for some time. We've uploaded that version since it's
not a regression, and it actually fixes an other important bug.
There might be other type of bugs in packages, which the buildd
might find and you don't, but I currently can't think of any
others.
> So maybe it would be useful to send a STOP instead of TERM signal to the
> process (and an email to the owner), go on with the next package, and
> let the owner of the machine find out later what went wrong with the
> build (connecting to the stopped process with gdb and friends).
I don't see the point of this. It's probably reproducible in
most cases.
Kurt
Reply to: