On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote: > >I said that deciding which packages should belong in P-a-s is porter work; > >as is filing bugs on failed packages that shouldn't, providing patches, and > >doing porter NMUs if necessary. > Again: what can I do with such a list? See the list below. Changes to the P-a-s list should be sent to the contacts listed at the top of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific). > >If the porters do this effectively, there's really not much need at all for > >telling the buildd maintainers about transient build failures, because > >they'll be pretty obvious (and account for the majority of failures, as it > >should be). > Just because it is obvious does not mean that the buildd adminstrator > does the correct thing. kq was "uploaded" 51 days ago, trustedqsl was > "uploaded" 25 days ago, neither is in the archive. Well, release-wise, the practical impact here is quite small; for packages that aren't needed in order to fix RC bugs, for my part I'm quite content to have the buildd admins manage such give-backs on their own schedule. Being more responsive to give-back requests may generally make people happier, but there's also a context-switch cost associated with such status polling; in the non-RC cases, does it really hurt anything to *not* have these packages given back quickly? If not, isn't a better solution for people to be understanding of this? kq and pointless given back now, btw (not trustedqsl, which is "Failed" rather than "Uploaded"). > openoffice.org has been "building" for 8 days, it only took 57 hours > on my slower than any current sparc buildd pbuilder. kexi has been > "building" for 6 days, it took less than 2 hours. openoffice.org is listed as "building" because the buildd crashed mid-build. Ryan Murray and the package maintainer discussed this on IRC when it happened; it was not immediately given back because of concerns over whether the build might take down a *second* buildd while there was still a significant backlog due to the c2a transition. No, this isn't perfectly transparent; but yes, it should be acceptable. There's almost never a reason to fret over builds-gone-missing for at least, say, a week and a half, which is about how long it would take for the package to be eligible for testing. In OOo's case, try adding another couple of weeks to that for the current c2a transition that it blocks on... > The sparc buildd mainainter has in the past left transient build > failures lie for over 6 months. For the past year he's been requeuing > all maybe-failed packages every 1-3 months. Well, a) we now have auto-dep-wait, so this is even less of a problem now than it might have been before; b) in the general case, it's not much of a problem. > REQUEUE > qterm 0.4.0pre3-2+b1 342381 Consider that this was a bug in a *toolchain* package, so more than a simple give-back is required: gcc-4.0 needs to be upgraded on the buildds for this to work. Given that this was caused by a stray \ in the source that didn't belong, it would be advisable for the package maintainer to defensively correct this as well. > DEP-WAIT > galago-sharp libmono-dev > dmraid libklibc-dev > motv ibzvbi0 (= 0.2.17-3.0.1) > qmailadmin vpopmail-bin > wvstreams libxplc0.3.13-dev > sylpheed-claws-gtk2 libclamv-dev > digikam libartsl-dev (>=1.4.2) > tulip mesa-common-dev (= 6.2.1-7) > liferea libdbus-glib-1-dev > kwave kdemultimedia-dev > ivtools libace-dev > fwbuilder libfwbuilder-dev > gtksharp2 libmono-dev > libavg libavcodeccvs-dev > gnucash slib > memepack r-base-dev > r-cran-bayesm r-base-dev Um, at least some of these dep-waits are completely wrong; r-base-dev and slib are arch: all packages, and it's not useful to set a dep-wait on a package that *is* available. Could you please revise this list accordingly? Also, setting an (= $version) dep-wait isn't particularly helpful, sometimes newer source versions will be uploaded before binaries are uploaded for the current version. So please clarify whether these are meant to be >= or something else. > FAILED But FAILED is an advisory state anyway; it doesn't directly benefit the port, at all, to have the package listed as "Failed", this is just a convenience for folks sifting through the build failures (like the rarely used "confirmed" BTS tag is for maintainers). In the long-term, one of two things needs to happen with each of these build failures: the package needs to be added to P-a-s so the arch no longer tries to build it, or the package needs to be fixed -- via porter NMU if necessary. So as you have the list of these packages, as a porter you can proceed with figuring out which of the two categories each falls into, and take the necessary action without worrying about the "Failed" state, yes? Cheers, -- 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