koji build dies with "Bad arg to %patch: %build"

Adam Jackson ajax at redhat.com
Tue Jul 29 13:46:54 UTC 2008


On Mon, 2008-07-28 at 21:39 -0400, Tom Lane wrote:
> Jesse Keating <jkeating at redhat.com> writes:
> > It's actually having problems with one of your %patch arguments.  The
> > srpm is initially created on a RHEL5 system, before passed to mock, so
> > perhaps rpm on RHEL5 doesn't accept the -F flag...  that is the recent
> > thing you changed right?
> 
> Doh, that must be it.  Thanks for the clue.
> 
> (Is it really a good idea to be using a back-rev rpm for one part of
> the build process, and the latest and greatest for other parts?  It
> certainly calls future build reproducibility into question, if you ask
> me.)

I have suggested - multiple times - that for mock the only thing the
system's rpm should be used for is generating the chroot, and that after
doing that (and chrooting inside and rebuilding the rpmdb) all further
use of rpm would be from inside the chroot.

There is a minor issue in doing so, which is that you'd either need to
teach yum about how to run in a chroot, or you'd need to modify mock to
get packages into the buildroot before running (the chroot's) yum on
them.  The reason is that if you don't, then the chroot's yum needs
access to the network, which is generally taken to be a bad idea.

The other problem with this is the construction of the SRPM itself,
which should also be done with the rpm that's expected to build it.
Again, we could do this by constructing a chroot containing rpm and the
scm tool of choice for checkout, and at least in principle that bit of
network access is no more problematic than what we're already doing.

The patch, I'm sure, would be gratefully accepted.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080729/a54f9a9c/attachment.sig>


More information about the fedora-devel-list mailing list