The source is bundled with the linux kernel tarball. During unpack, the source has to be extracted from the right tarball and then patched to the latest rc or patch level. Only the needed parts of the tree are extracted, and only they need to be patched. Thus, the patch is filtered using filterdiff. Only, the patch is made using -p1 style and filterdiff produces an empty patch, which is not applied. Because the ebuild was never tested with a non-empty patch, the epatch is invoked in the wrong directory and after sed changes the source in a way that prevents any patch from applying cleanly. I attach a patch to the ebuild that fixes those issues. Reproducible: Always
Created attachment 217530 [details, diff] fixes the ebuild
Uhm in which situation the patch could be empty at all? I've made it a rule to add RCs only for stuff that gets actually changes in perf (see [1]), so there should be no way for this to happen. [1] http://blog.flameeyes.eu/2010/01/19/splitting-packages-when-to-bump
# ebuild /usr/portage/dev-util/perf/perf-2.6.33_rc5.ebuild unpack # ls -laF /var/tmp/portage/dev-util/perf-2.6.33_rc5/work/perf-2.6.33_rc5.patch -rw-r--r-- 1 root root 0 Jan 27 17:11 /var/tmp/portage/dev-util/perf-2.6.33_rc5/work/perf-2.6.33_rc5.patch because the ebuild runs: $ filterdiff -i tools/perf/* -i include/* -i lib/* -i arch/*/include/* -z /usr/portage/distfiles/patch-2.6.33-rc5.bz2 | wc -l 0 <--- EMPTY PATCH !!! instead of: $ filterdiff -p1 -i tools/perf/* -i include/* -i lib/* -i arch/*/include/* -z /usr/portage/distfiles/patch-2.6.33-rc5.bz2 | wc -l 133716
Thanks Zeev, I fixed this now, sorry for the wait.
