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

Re: StrongARM tactics



On Tue, Dec 06, 2005 at 09:02:23AM +0100, Thomas Viehmann wrote:
> Kurt Roeckx wrote:
> >>twinkle: requeue (probably libccrtp was stuck in NEW)
> > The problem is that libccrtp1-1.3-0 is still linked to
> > libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a.
> Hm. Sorry.

> >>wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696
> >>xchm: retry (needed libchm-dev)

> > This can probably be requeued indeed.  But it would help if the
> > maintainer uploaded xchm after libchm was in installed state
> > on all arches, so buildd admins don't have to look at this.
> Yeah. That would help. But so there's a lot of packages that need
> attention by buildd-admins.

> >>xmms-openspc: arch specific (says maintainer in control)
> >>zinc-compiler: arch specific dependency (ghc6)

> > So those should get added to P-a-s instead.
> Well, but that'd be something for the buildd-admin to collect.
> (Or maintainers of the packages, but that doesn't seem to fashionable
> nowadays...)

Um... no.  This is *porter* work; one does not have to be a buildd admin to
analyze a build failure to see whether the package belongs in P-a-s, and
there's no reason that the buildd admins alone should bear the
responsibility for figuring out whether a permanent build failure should be
fixed or ignored.  (Maintainers probably need to be involved in this
process, but usually maintainers don't have the requisite knowledge about
all our ports to make informed decisions on their own.)

Saying "that's the buildd admin's job" about tasks that don't *need* to be
done by the buildd admin is a pretty effective way of encouraging the
problems that the Vancouver proposal sought to address, where two or three
people end up carrying all the ports, and all their time is eaten up by
maintaining the buildds and giving back failed packages with no time for
following through on the permanent failures (which, even though they
sometimes represent a minority of Maybe-Failed packages usually account for
a majority of the actual work needing done).

> >>weechat: don't know, error on dh-strip on 5 archs, no bug filed

> >>That's 2 out of 7 which need actual debugging, both not arm-specific.

> > And only 1/7 where some action of the buildd maintainer is needed
> > at this time to get something build.
> The dep-wait is well inside the "some action of the buildd maintainer is
> needed". The needed P-a-s entries could be handeled centrally if the
> problem description is "pile of maybe-failed packages".

Wonderful.  Nice to see that you think P-a-s entries are somebody else's
problem that should be "handled centrally".

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: