On Tue, Jul 03, 2007 at 08:25:59AM -0400, Jesse Keating wrote:
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.
So with scratch builds there is no need to commit in CVS, queue the
build, wait for the queue to reach the job, and it really allows
everyone and his cat to do it, not only the submitter?
Where's that hyperbole again?
> It's different if the problem is actually reproducable on
> 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.
Unless upstream never advertized a parallel make feature (which one
really does?) and upstream cares more about fixing real code bugs than
spurious Makefile racings on an 8-way system.
Axel.Thimm at ATrpms.net