Re: Bits from the release team (freeze time line)
On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote:
> On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote:
> > On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote:
> > > However, using words like "known-buggy mips* machines" is just FUD
> > > against the mips*-ports, and plainly inacceptable, so please stop
> > > doing that. (For reference, there is no mipsel machine which has
> > > hardware bugs affecting daily operations. There are two mips machines
> > > which are pre-series and are not as stable as I wish, but as builddadm
> > > I was more occupied recently with arm* machines not stable then with
> > > mips machines not stable. This all doesn't mean I think nothing should
> > > be changed, but please do not FUD against mips* (or any other
> > > architecture).)
> >
> > builddadm does not keep the machines running, DSA does. ball is ancient,
>
> I agree that ball, rem and mayer are indeed ancient. That said despite
> their age, they are about twice faster as armel and armhf build daemons
> for building for example libreoffice or qt4-x11. Does they cause any
> problem from the administration point of view?
The mipsel machines are working reliably but are probably not replacable if one
dies. They could use more memory and it'd be helpful if they booted from SATA
(so that we can source new disks if/when the current PATA disks die).
> > corelli and gabrielli are unstable under load and lucatelli does need
> > occasional reboots too, IIRC.
>
> I agree that corelli and gabrielli are unstable, though it's clearly not
> related with the load. I am not aware of any issue with lucatelli, do
> you have some more details?
Of the four Movidis mips machines that I received at ubcece, one was dead on arrival,
two have proven unreliable and only one is stable. All four were received with
notes indicating that their eth0 was faulty, suggesting that they failed QA.
The one that is stable is often so overloaded that we can't actually run any of
our regular system administration tasks since the entire system is just thrashing
(because there are 2 buildd instances running concurrently, and g++ with large
parallelism just eats memory)
I think that our core point is that we need the porter community (internal and
external) to source production-quality buildd hardware with requisite out of band
managment (console & power, minimum). DSA is happy to organize the purchase
of hardware, if we're pointed to an acceptable vendor.
That said, if the external hardware community is interested in having Debian
ported to their architecture, then we should not need to purchase hardware. Nor
should we need to accept buggy pre-production hardware.
So, our concern remains: buildd and porter boxen for the mips* and arm* need some
attention from the porter community. Let's work together to get some newer, more
capable, bug-free hardware lined up. Maybe even "under warranty" :)
Thanks,
Luca
--
Luca Filipozzi
http://www.crowdrise.com/SupportDebian
Reply to: