> So probably using Qemu could speed it up quite a lot. Also OBS
> offers
> quite a lot of flexibility to decouple arch builds, disable
> selected
> archs etc. But I'm not sure about the processes for chain builds,
> updates, how they make the builds consistent (if one arch fails)...
All sorts of things can speed it up, most of the Fedora builders are
currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
optimal. Add to that 1Gb of RAM and swap the problem gets worse. The
devices we're looking at have proper SATA ports (not over USB) and
quad core 4GB RAM and the time to build is an order of magnitude
faster, and those boards aren't overly stable as they're not
production level HW so once we get our hands on production level
versions of that HW we can start to properly test the difference in
large packages such as gcc, qt, libreoffice and the kernel and will
be
able to much better ascertain the impact. I believe that should be
"soon" although I'm not in direct contact.
It was more argument about real qemu speed from real deployment. Not
bashing the current setup.
It's better to have real data over just talking here :)
R.
Peter
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel