>>>>> "Hannu" == Hannu Nyman <[email protected]> writes:
Hannu> [...] If any of the developers have any debugging advice,
Hannu> please give it.
Here's what I do:
I "git bisect" it, with a distclean between each build.
You want to be really sure that the problem is or is not introduced in
a particular rev. Keeping stuff from previous builds may speed things
up, but at the cost of not being sure anymore. You want to be sure.
Do minimal, vanilla package selection, since the packages won't be
involved in your problem. Identifying the rev that breaks will help
whoever can fix it to see what might be wrong. Having a copy of a
minimal .config stashed away* that you can expand with make defconfig
is handy too (minimizing interaction between builds). Something like:
git bisect start
git bisect bad <commit>
git bisect good <commit>
cp ../my-starting-config .config
make defconfig
make -j$CORES BUILD_LOG=1 IGNORE_ERRORS=m V=99
<flash image to test>
cp .config bin/ ; mv logs bin/ ; mv bin ../bin-r$REV-target
git bisect <good|bad>
make distclean
GOTO cp ../my-starting-config .config (rinse/repeat)
... until you find the revision step that breaks. I hang on to the
built revs (with a copy of the .config and logs) for future reference.
then:
git bisect reset
to return to your initial HEAD. It is a bit tedious, but it helps get
your problem fixed.
* you can generate a suitable ../my-starting-config by rm'ing .config
and .config.old, then make menuconfig'ing the bare minimum for your
situation, then running:
scripts/diffconfig.sh > ../my-starting-config
--
Russell Senior, President
[email protected]
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
