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
