While I noticed this when using a private kernel ebuild, I don't see why it wouldn't affect any kernel ebuild with four numeric components in the version, which includes: mips-sources openvz-sources vanilla-sources (!) xbox-sources What happens is that for a kernel with a version such as 2.6.35.4, get_running_version fills the kernel vars like this: KV_MAJOR=2 KV_MINOR=6 KV_PATCH=35.4 I've looked at all ebuilds in the tree I could find that test KV_PATCH, and they all assume it to be an integer (or call kernel_is to test it, which makes the same assumption). Actually, the fact is there are only two packages this is likely to affect in practice: sys-fs/evms and sys-fs/udev. Those are the only ones in the tree that use get_running_version (they both do, indeed, attempt integer tests on KV_PATCH). Therefore, fixing the problem would seem to pose very little risk. There may also be rare, user-specific situations where linux-info_get_any_version falls through to get_running_version, but certainly those are broken right now, anyway. Trivial patch follows.
Created attachment 259891 [details, diff] Fix get_running_version to work with four-part kernel version numbers. I realize this doesn't preserve the version sublevel, but it wasn't being preserved in any useful way anyway. If there's a future need for it, it should be parsed into a new, separate variable.
Oh, I forgot to point out the practical results of the bug: 1. The udev ebuild (after spitting out the "integer expression expected" error) refuses to restart udev because it doesn't recognize that the kernel is new enough. 2. The evms ebuildspits out the error, but it's not fatal.
*** This bug has been marked as a duplicate of bug 327417 ***
