Re: StrongARM tactics
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...)
>>visualboyadvance: buggy, could requeue to get #334727
> What's the point to requeue if this bug isn't fixed?
There isn't, thats why it says "buggy, could requeue", not "needs
retry". Also if you had a lot of cycles to spare, the last build log
would actually reflect the current problem...
>>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".
OTOH above sample is biased: There's only ~57 Packages where apt-get
fails or dpkg complains about wrong arch.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
Reply to: