[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sparc build failure analysis (was Re: StrongARM tactics)



On Sun, Dec 11, 2005 at 05:55:23AM -0800, Steve Langasek wrote:
> 
> > Indeed, for practical buildd maintainance purposes, the distinction is
> > not that important -- though 'Failed' is known to not benefit of a
> > requeue, while 'Building:Maybe-Failed' might or might not, it's unkown,
> > most archs should have enough surplus buildd power that retrying
> > everything once in a while doesn't hurt.
> 
> > The major benefit is though to make it apparant for porters what to look
> > into, without all the 'noise' in between of maybe-transient failures.
> > One could also make sure that the FTBFS bugs are tagged (user-tagged)
> > with debian-sparc@l.d.o (etc) for example (or $arch@buildd.d.o? There
> > doesn't exist a d-mipsel@l.d.o for example...), so that one can get a
> > nice overview of all the porting bugs. It'd make sense to synchronise
> > this across all architectures, so that it is consistent.
> 
> http://lists.debian.org/debian-alpha/2005/12/msg00028.html

I have a long list of bug affecting amd64, but I haven't started
with usertags for it.

The (FTBFS) bugs I encouter (as buildd admin) are:
- General bugs affecting all arches.
- General bugs affecting 64 bit arches.
- Bugs affecting some arches (like not using -fPIC)
- Bugs only affecting amd64.

And the later really is the minorty of the problems.

Note that this does not cover runtime problems or something like
that, but they're very simular.

Do we need to have a special usertag for the first kind?  This is
basicly something everybody can look at.  The only reason I can think
of that it requires some tag is that it's better then looking at
those that don't have a tag.

So, I'm open for suggestions on how to tag the first 3 of those.


Kurt



Reply to: