BuildSystem questions

Dan Williams dcbw at redhat.com
Sun Nov 13 00:22:07 UTC 2005


On Sat, 2005-11-12 at 13:06 -0700, Kevin Fenzi wrote:
> >>>>> "Dan" == Dan Williams <dcbw at redhat.com> writes:
> But they _don't_ differ in content. 
> 
> - - Submit job for package A-1.0-1.fc5
> - - Build fails or gets stuck in the build system. 
> - - make NO CHANGES to the package in cvs. 
> - - plague-client kill NNN
> - - plague-client requeue NNN
> - - package builds and goes to needsign. 
> 
> Is there anything wrong with that procedure? I find it nasty to bump
> the release in a package just to get another build when nothing in the
> package has changed. If you have to modify the package to build of
> course you need to change release, but in this case nothing has
> changed except the buildsystem didn't get stuck on the job. 

No, nothing wrong with that procedure.  Buildsystem issues shouldn't
require a retag unless the job has actually made it through to needsign,
which almost none will.  You can simply requeue.

> Dan> Two issues here...  The PPC machine either has 4 processors or 2
> Dan> x dual core, I forget which.  So while it's got twice the number
> Dan> of CPUs as one of the hammer boxes, they are slightly slower.
> Dan> The real issue with the PPC machine is the disks, which seem to
> Dan> be slower in general, and that multiple mock/yum instances don't
> Dan> run in parallel.  I think we're still seeing the issue where
> Dan> mock/yum lock the host machine's rpmdb even though they install
> Dan> to the chroot.  That means only one 'prepping' job can actually
> Dan> execute at any time, even if 4 jobs are 'prepping'.

I'm actually 50% wrong here, the problem is not mock/yum waiting on
buildroot locks as I've just found out.  So I think its just slower
disks or something, not anything intrinsic to mock or yum.

Dan




More information about the fedora-extras-list mailing list