Re: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes <email@example.com> wrote:
>> And what should one do with a bug like this? At the moment it's quite
>> irrelevant whether one of our packages has a bogus RC bug. But what if
>> that happens when I'm hoping for a transition to testing?
> Are you now talking about the failure on hppa or the one on ia64 (in
> both cases the bugs were filed by the buildd admin)?
I'm talking about any bug that was filed against package $foo because
package $bar FTBFS on $buildd_a, when it later turns out that the reason
for the breakage is "something" on $buildd_a.
> The one on hppa is as far as I can see nothing you can do about and
> should probably be mentioned to the porters.
That doesn't solve my problem: Should I
- keep the bug open against my package? Doesn't make sense, since I have
- make sure that the porters, buildd admins etc. are aware of the
problem and simply close the bug?
- reassign to buildd.debian.org: That you just said I shouldn't do
- reassign to $computer_name.buildd.debian.org: That would make most
sense, but it isn't possible.
> The one on ia64 breaks the buildd's chroot and looks to be easily solved
> by making sure that the maintainer scripts don't fail when the missing
> command is not available.
It could be easily solved by making sure that nothing on the buildd
installs packages without installing their dependencies.
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg