On Wed, Sep 25, 2013 at 11:10:45 -0400,
Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
The gitX snapshots are exactly what you're describing already. So if
you're within the range of one of the gitX snapshots, use the existing
builds in koji to narrow it down first. The git commit sha1s for each
snapshot are listed in the corresponding %changelog entry.
I do know which snapshots the problem happened between and I am using
the noted commits to bound the search. It would probably have sped
up the diff process to have started from the corrert rc patch point and
just replace the git? patch file. If I need to start again I'll make
that change. But the speed up from that is only only to be about a minute.
Yes, more or less. The issue is that building kernels via RPM is
slow. Sometimes it's better to just build and install local kernels
and cleanup later. That is particularly true if you're bisecting in a
well defined area, such as a driver or subsystem. You can just use
bisect on that directory and things go much faster.
Is there documentation on how to do that without doing the whole rpm
process? In my particular case it might not help much because there
weren't changes in the expected area (the radeon driver) and probably
something else was changed that it uses. But there were still only
around 600 commits to go through, so maybe it would still be faster if
I didn't have to recompile the whole tree for each test.
Is there any easy way to do the builds faster? (I'm thinking by not building
all of the rpms, but other approaches are welcome.)
You can turn off debuginfo, perf, and tools, and that will make the
RPM build go faster. Just run rpmbuild and pass --without perf
--without tools --without debuginfo.
I'll make that change on my next pass.
Thanks!
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel