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