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

m68k: being ignored for testing propagation

Hi folks,

So last month Andreas Barth wrote to say that the release team was
considering ignoring m68k for testing propagation, because it has not been
keeping up with the archive, and as a result is blocking fixes from reaching
testing unless they are manually overridden.  At the time, here is what the
breakdown looked like of missing builds holding packages out of testing:

460 m68k
227 arm
174 mips
148 hppa
132 s390
114 sparc

Here is what it looks like today:

m68k: 397
arm: 285
sparc: 214
mips: 153
hppa: 125
alpha: 93

While you can see that this is an improvement for m68k in absolute numbers,
and also that a couple of other architectures are now looking worse than
they did in September, this is unfortunately not the improvement we need to
be seeing for the port.  Moreover, these numbers only reflect out-of-date
packages, they don't show new packages that are not yet built on m68k -- at
least some of which are a factor because they are build-dependencies of
other packages which *are* out of date.  For another metric of how well
architectures are (not) keeping up with unstable, please see:

As a result, this evening I've asked Anthony Towns to configure britney to
ignore m68k when considering packages for testing so that it no longer holds
up fixes for the other architectures.  As Andreas wrote before, this does
not mean we are ruling out the possibility of releasing m68k with etch.  It
*is* an indication of how much work needs to go into m68k in order for it to
be in a releasable state.

I realize that part of the reason for the current state of affairs on m68k
is the large buildd backlog (326 packages in w-b state Needs-Build), and
that there are limits to how quickly this backlog can be cleared.  There are
also other areas that need attention, though, which don't require you to be
a buildd maintainer to help with (though obviously knowlege of m68k, and the
ability to test, are important).  From
<http://buildd.debian.org/~jeroen/status/architecture.php?a=m68k>, there are
125 packages in state Failed, 138 in state Dep-Wait, and 45 that are
Maybe-Failed; as well as 27 packages in state Not-For-Us.  These are all
packages which count against m68k when attempting to judge the port's
releasability.  Please, if you want m68k to release with etch, work on
turning these into RC bug reports for packages, porter NMUs, re-queued
packages in the case of transient failures, or entries for
(http://buildd.debian.org/quinn-diff/Packages-arch-specific) in the case of
packages that are not candidates for inclusion on m68k.

In addition to getting the count of m68k blockers in unstable down to a more
moderate level, because m68k is now being ignored we will need to pay
special attention to
<http://ftp-master.debian.org/testing/testing_outdate.txt> and
<http://ftp-master.debian.org/testing/testing_probs.html>[1], which show
packages that have allowed to become out-of-date or uninstallable on m68k.
As m68k begins to catch up again these numbers should go down on their own,
but there may be some stragglers which don't find their way into testing
once built, for one reason or another.  Your help in controlling this will
be appreciated.

The release team will continue to monitor the progress of the m68k port.  If
you have any questions about where to go from here, please ask us.

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/

[1] this page also lists all arch: all packages that are uninstallable on
any arch, so one will need to filter the list looking for packages that are
uninstallable *only* on m68k...

Attachment: signature.asc
Description: Digital signature

Reply to: