Michael Casadevall <sonicmctails@gmail.com> writes: > What about simply decoupling mips/mipsel's version numbers so an out of > date package on mips(el) doesn't stall out the rest of the > testing. Having (somewhat) setup britney/update_out to generate testing > for m68k, it should just be a matter of adding of adding mips and > mipsels, to the proper lists in update_out.py. As it stand armel uses > this (hence why in update_excuses it says Ignoring armel dependency). No, you are entirely correct, this would be the way to do it. We (release team hat on) don't want to do this at the moment because we need to release with binaries for *one* source version on all our architectures. If we add mips* to the architectures which can lag behind now, we will have a hard time to get them in sync later, without actually profiting from this - the major transitions needing hand-holding are not blocking on missing mips* builds. Also, the performance of mipsel in the last fours days, in which two buildds have been working, shows that we just need to resolve the hardware problems and everything is fine. Ryan just reported that a faulty RAM module in the second mips build daemon (mayr) has been identified and removed and the box is being set up for buildd use right now. mips should see the same decrease in the needs-build queue as mipsel has seen in the past few days. (release team hat off) Marc -- BOFH #288: Hard drive sleeping. Let it wake up on it's own...
Attachment:
pgphIpOz7mIBk.pgp
Description: PGP signature