On Wed, Jun 03 2009, Luk Claes wrote:
> 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?
If it is not a bug in the package (in other words, no change
made in the package would fix the issue), I see no point in keeping it
open. It would be nice, however, is a psuedo-package were created for
the buildds (or one per buildd, though that seems excessive) so such
issues can be tracked in a central location, rather than scattered
across the 9000 or so source packages.
manoj
--
"If that makes any sense to you, you have a big problem." Durance,
Computer Science 234
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
