Frank Küster wrote: > 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
> - make sure that the porters, buildd admins etc. are aware of the > problem and simply close the bug? You might want to downgrade the bug and only close it when it is realy solved? >> 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. A patch is appreciated, thanks for your cooperation. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
