Description of problem: Version-Release number of selected component (if applicable): procps-3.2.8-21.20110302git.fc16.x86_64 kernel-3.0-0.rc1.git0.2.fc16.x86_64 How reproducible: always Steps to Reproduce: 1. run uptime or ps Actual results: Non-standard uts for running kernel: release 3.0-0.rc1.git0.2.fc16.x86_64=3.0.0 gives version code 196608 14:54:24 up 10 min, 6 users, load average: 4.26, 3.96, 2.27 Expected results: Same thing without the warning Additional info: There's an sscanf in proc/version.c which assumes %d.%d.%d for version numbers.
Same here [leigh@main_pc ~]$ uptime Non-standard uts for running kernel: release 3.0-0.rc2.git0.1.el6.x86_64=3.0.0 gives version code 196608 17:18:12 up 2:31, 3 users, load average: 0.32, 0.13, 0.08 [leigh@main_pc ~]$
(In reply to comment #0) > Description of problem: > > > Version-Release number of selected component (if applicable): > > procps-3.2.8-21.20110302git.fc16.x86_64 > kernel-3.0-0.rc1.git0.2.fc16.x86_64 > > How reproducible: > > always > > Steps to Reproduce: > 1. run uptime or ps > > Actual results: > > Non-standard uts for running kernel: > release 3.0-0.rc1.git0.2.fc16.x86_64=3.0.0 gives version code 196608 > 14:54:24 up 10 min, 6 users, load average: 4.26, 3.96, 2.27 > > > > Expected results: > > Same thing without the warning > > Additional info: > > There's an sscanf in proc/version.c which assumes %d.%d.%d for version numbers. Are you sure you have reported this against the right package?, I see it as a kernel issue.
(In reply to comment #2) > Are you sure you have reported this against the right package?, I see it as a > kernel issue. I'm positive. The problem is that the utilities make the erroneous assumption that the kernel version always matches "%d.%d.%d" — three digits separated by dots. But the kernel is now just "3.0". You could argue that it'd be more polite of the kernel to just claim to be 3.0.0, but as far as I can see Linus Torvalds is against that. (Part of the _point_ of the change was to reduce the number of digits.)
(In reply to comment #3) > (In reply to comment #2) > > Are you sure you have reported this against the right package?, I see it as a > > kernel issue. > > I'm positive. The problem is that the utilities make the erroneous assumption > that the kernel version always matches "%d.%d.%d" — three digits separated by > dots. But the kernel is now just "3.0". > > You could argue that it'd be more polite of the kernel to just claim to be > 3.0.0, but as far as I can see Linus Torvalds is against that. (Part of the > _point_ of the change was to reduce the number of digits.) Thank you for the explanation.
Created attachment 504153 [details] Patch for handling the kernel3 version string properly Hello guys. I've just built the procps-3.2.8-22.20110302git.fc16 containing the attached patch for proper kernel3 version string handling. Please, test it and let me know. Thanks in advance, Jaromir.
(In reply to comment #5) > Created attachment 504153 [details] > Patch for handling the kernel3 version string properly > > Hello guys. > > I've just built the procps-3.2.8-22.20110302git.fc16 containing the attached > patch for proper kernel3 version string handling. > > Please, test it and let me know. > > Thanks in advance, > Jaromir. It fixes the issue here [root@main_pc leigh]# uptime 11:16:44 up 1 day, 20:29, 5 users, load average: 0.05, 0.03, 0.05 [root@main_pc leigh]# uname -r 3.0-0.rc2.git0.1.el6.x86_64 [root@main_pc leigh]#
3.2.8-22 is missing from rawhide. I don't see any koji builds.
I can also confirm it fixes the issue for me. uname -r 3.0-0.rc3.git5.1.fc16.x86_64 procps-3.2.8-22.20110302git.fc16.x86_64
Built in rawhide.