On Tue, Mar 22, 2005 at 12:45:56PM +0000, Michael K. Edwards wrote: > On Tue, 22 Mar 2005 11:02:47 +0100, David Schmitt > <[EMAIL PROTECTED]> wrote:
> > As Steve mentioned in another mail[1], one of the points where arches > > offload > > work onto the release team is > > "3) chasing down, or just waiting on (which means, taking time to poll the > > package's status to find out why a bug tagged 'testing' is still open), > > missing builds or fixes for build failures on individual architectures that > > are blocking RC bugfixes from reaching testing" > The inspection will be a painful process for anyone who doesn't have > an otherwise idle ARM handy. Sure, he (or I) can massage the build > log to construct URLs for files in pool, and pull them to $fast_box, > unpack, and inspect. But an arm porter is in a better position to do > this inspection, since apt-get build-dep will work without a bunch of > script-fu. Eh, not particularly. This inspection can be done on any machine, and there's no reason not to just use the fastest one available to you (whether that's by CPU, or network); what's needed here is to first identify which packages that were used in the build were broken, which can't be done with apt-get build-dep even on arm; and then verify whether the packages in question have been fixed in a newer version. In general, just looking at apt-get build-dep doesn't guarantee that you haven't overlooked the problem that caused the build failure in the first place, and it isn't even guaranteed to install the same *packages* (let alone package *versions*) as sbuild. ARM porters aren't in a better *position* to do this kind of thing, but I certainly expect them to have more *incentive* to do this kind of thing for their port. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
