After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 657490 - glibtop: Non-standard uts for running kernel when using linux 3.0
glibtop: Non-standard uts for running kernel when using linux 3.0
Status: RESOLVED OBSOLETE
Product: libgtop
Classification: Core
Component: linux
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libgtop maintainers
libgtop maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-27 09:40 UTC by Ionut Biru
Modified: 2018-01-10 19:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix this issue (1.28 KB, patch)
2011-10-22 19:00 UTC, Ionut Biru
reviewed Details | Review

Description Ionut Biru 2011-08-27 09:40:57 UTC
Hi,
glibtop: Non-standard uts for running kernel:
release 3.0-ARCH=3.0.0 gives version code 196608

the function set_linux_version expects a version with x.y.z schema
Comment 1 Ionut Biru 2011-10-22 19:00:44 UTC
Created attachment 199731 [details] [review]
fix this issue

please review
Comment 2 Nicolas Iooss 2014-04-13 16:08:20 UTC
Hello,

This bug also occurs in Debian testing, when running gnome-system-monitor:

    glibtop: Non-standard uts for running kernel:
    release 3.12-1-amd64=3.12.0 gives version code 199680

The previous patch solves this issue.  I'm not a glibtop developer but I've got some experience with C and the patch looks good to me except on one point: when sscanf("3.12-1", "%u.%u.%u", &x, &y, &z) returns 2, is the fact that the value "z" has not changed (and is still zero) a reliable well-defined behavior?  As I haven't found anything about it in http://linux.die.net/man/3/sscanf I'd expect that z would be undefined after the call to sscanf and needs to be reset to 0.

Thanks
Comment 3 Benoît Dejean 2014-04-13 20:20:51 UTC
Hello Nicolas, it's funny because i've never seen the warning myself although i'm a debian/sid user.
Comment 4 Benoît Dejean 2014-04-13 20:22:51 UTC
Review of attachment 199731 [details] [review]:

Patch is fine, I think we can safely forget about what happens if the last number fails to parse, just as we've doing since the begining.
Comment 5 Nicolas Iooss 2014-04-13 20:36:02 UTC
> Hello Nicolas, it's funny because i've never seen the warning myself although
i'm a debian/sid user.

What is the output of "uname -r" on your machine? Even with a 3.x kernel it may contain 3 digits. For example, until a few days ago, on Archlinux this commands gave:

    3.13.8-1-ARCH

... which doesn't trigger the bug.
Comment 6 Benoît Dejean 2014-04-14 07:11:12 UTC
I get a "3.14.0ben" for example, but maybe something changed in Linux since the early 3.x versions.
Comment 7 GNOME Infrastructure Team 2018-01-10 19:48:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgtop/issues/21.