[Mageia-sysadm] ARM port and BuildSystem

[nicolas vigier]

On Mon, 04 Apr 2011, Michael Scherer wrote:

> Le lundi 04 avril 2011 à 19:44 +0200, nicolas vigier a écrit :
> > Hello,
> > 
> > There was some discussions at last council meeting about making ARM an
> > official port, and adding ARM machines in the build system :
> > http://meetbot.mageia.org/mageia-meeting/2011/mageia-meeting.2011-03-28-18.33.log.html#l-381
> > 
> > Rtp has been working on a Mageia ARM port for some time, and I think he
> > plans to have something useable soon, maybe for Mageia 1st release.
> > After asking to rtp, a machine we could use for building packages on
> > ARM is OpenRD :
> > http://newit.co.uk/shop/products.php?cat=9
> > It costs around £203.00 or 230 euros (+ shipping). So I think that's not
> > very expensive.
> 
> I still do have a pandaboard available. It just take that someone in
> Paris fetch it and to decide where we place it ( and a case around it
> would be nicer, and there is nothing to run on it yet ). 

Yes, we can start with this pandaboard, and bring it next time we go to
Marseille. Maybe we can also add an OpenRD if we can buy one, to allow
building packages faster with two build nodes. According to rtp, an
advantage of OpenRD is that it's armv5t which is better to detect
alignement errors.

> 
> > However, this machine is a lot slower than the x86_64 build servers we
> > have, so building big packages like LibreOffice will take much more
> > time. And if we don't want to slow down all the buildsystem, maybe we
> > should make the successufl ARM build not mandatory to upload packages on
> > x86_64 and i586. So this require some changes in the BS. But I think
> > it's something that can be done.
> 
> That for sure something we can do, but then we should also give us
> objectives to fullfill ( like "we should strive to have a synced
> release" ) and also objectives in term of hardware to one day make them
> in sync.
> 
> Moreover if this is not mandatory, don't you fear that the arch will be
> too much out of sync ( as this was the case for ppc/sparc in the
> past ) ? 
> I would also be concerned about the way we manage freeze if the arch is
> late, and the complexity that will occurs. 

Yes, that can be a problem if one arch become too much out of sync.
Maybe we can generate a list of out of sync packages to help see what
needs to be fixed. So ARM will not be guaranted to be always sync with
i586 and x86_64, that will depend how fast people can fix ARM bugs.

> Also what about stuff like :
> - remote shell access ( if there is a arch dependent bugs )
> - various tests ( automated rebuild, youri, etc ) 
> 
> For remote shell access, we could offer VMs for that, but I can hear rtp
> screaming as I type this email :). 
> In fact, the same could be said about rebuilded, but I do not know how
> good is the emulation of arm using qemu.

Or later add new ARM machines where people can have shell access.