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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]