On Wed, Sep 25, 2013 at 10:49 AM, Bruno Wolff III <bruno@xxxxxxxx> wrote: > I need to bisect the Fedora kernel to track down a bug and would some advice > on workflow and tips for speeding up builds. > > My current approach is to start by cloning the linus kernel and cloning the > fedora kernel package. I cloned a git0 version of the package. I am > replacing the rc patch by doing a git diff versus the 3.11 kernel and piping > it through xz. I then use fedpkg local to build the test kernel. 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. > There weren't too many Fedora patches in the period of interest, but > potentially I might need to add or remove one of these. The main issue is > that the builds take long enough that I am only going to be able to do one > test a day. I am building on i686 and really only need one of the PAE or > non-PAE kernels and I don't need any of the other rpms (notably the doc > rpm). > > Does this workflow seem sane? 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 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. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
