You're receiving this bug because the package in Summary has produced _FORTIFY_SOURCE related warnings indicating the presence of a sure overflow in a static buffer. Even though this is not always an indication of a security problem it might even be. So please check this out ASAP. By the way, _FORTIFY_SOURCE is disabled when you disable optimisation, so don't try finding out the cause using -O0. Thanks, Your friendly neighborhood tinderboxer
Created attachment 246609 [details] Build log
The problem is that oops.c:1177 declares char label[6], then oops.c:1200 calls strcpy to copy a 6 character literal (plus null, so 7 total) into label. There seems to be no good reason that label cannot grow to 8 characters to provide adequate storage. That said, is this package worth keeping? As I understand it, ksymoops is only used for 2.4 series kernels. It last received a non-noise change in 2006 when Vapier added a patch to its Makefile. Gentoo has stopped supporting 2.4 kernels, and even the upstream maintainer (Willy Tarreau) is looking to cease 2.4 maintenance within about a year: <http://lkml.org/lkml/2010/9/6/15>.
The package is not limited to 2.4 kernels. If you turn off symbols in oops output on 2.6, you need this package to resolve the oops still. Fixed in CVS.
(In reply to comment #3) > The package is not limited to 2.4 kernels. > > If you turn off symbols in oops output on 2.6, you need this package to resolve > the oops still. This is counter to the foreword in Documentation/oops-tracing.txt: NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format (from dmesg, etc). Ignore any references in this or other docs to "decoding the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that has been run through ksymoops, people will just tell you to repost it. Could you cite the source which says this is still useful? The ksymoops homepage URL points to a directory that only has the sources.
