Re: Bug#531581: Critical problems on hppa and ia64 buildds
Luk Claes <luk@debian.org> 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
no bug
- 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.
Regards, Frank
--
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg
Reply to: