Luk Claes <l...@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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to