On Tuesday 03 July 2007 07:47:26 Axel Thimm wrote:
But you understand that the month of trials is about buildon the
Fedora builders, not on your own server or workstation? It isn't
really a sensible turnover to edit, submit, wait for being queued in,
wait for being built on all archs, get the response on failure, dig
trhough a web interface, find the logs, donwload them, comaper them to
local logs etc. Now add the fact to it that if someone else than the
submitter has some suggestion it needs first to get piped through the
submitter, who needs to <repeat all steps above>.
Scratch builds are your friend. You can target a single arch, build any srpm
you want, etc... No need for the hyperbole of above.
It's different if the problem is actually reproducable on your
own
system.
What's the drawback of a general discommendation of smp_flags (not
talking about openoffice and friends)? A submitter waiting twice as
long in build time? Is that really a big drawback in comparison to
having packages break out of the blue? No Makefile project not
intended/tested by upstream for parallel builds is smp_flags safe, the
race may just not have been triggered yet (as in the case of vtk).
And if your build succeeds on F7 and start to mysteriously fail on F8
will the first thought be that the hidden make -jX bug hit you or that
something in the build environment is screwed?
To use somebody else's argument it can be useful to /find/ these bugs. If the
software doesn't compile right due to smp often it is an upstream bug that
needs to be addressed. Maybe the upstream doesn't have access to smp, and we
can get them into Fedora and give them access to our build farm so that they
can make better code.
And yes, things are faster. The faster they get through the build system, the
faster the next job can start, and so on and so forth.
--
Jesse Keating
Release Engineer: Fedora