GNOME Bugzilla – Bug 577578
NumLock remembering disabled because hostname is set to "localhost" warning.
Last modified: 2009-04-02 19:57:20 UTC
Please describe the problem: NumLock remembering disabled because hostname is set to "localhost" warning should be instead a debug message. localhost hostname is very common on desktop systems today, especially laptops that use wireless networks and connect anywhere. This makes the above warning all too common and confusing for a novice user. Steps to reproduce: Log in gnome desktop. Actual results: gnome-settings-daemon reports warning: NumLock remembering disabled because hostname is set to "localhost" Expected results: No warning. Does this happen every time? Yes. Other information:
Created attachment 131826 [details] [review] Proposed patch to remove the warning.
I'm not sure I agree with the reasoning. It's a helpful message to actually identify the problem (if you have it), and debug level messages usually aren't enabled. I also how "novice users" are supposed to encounter that message. Unless you dig into log files or run g-s-d by hand (both of which are rather untypical of novice users) you'll never get to see it.
It depends. You're correct that warnings are supposed to identify problems. That way, people can notice them and go about fixing them. But is disabling NumLock state remembering on localhost a problem? How do I fix it, if I work exclusively on my laptop which is always named localhost? It seems to me that this is just informational message about certain functionality not being used because there is no benefit from it.
It's not so much that it's not useful on "localhost", it's that you can't properly identify the host so you don't know what to save it for. If you go "why the heck doesn't this stupid #?*! save my NumLock state", then yes, I think that message might be helpful.
Maybe I am misunderstanding the whole purpose of saving NumLock state, but my assumption was that NumLock is remembered on per host basis which is useful if you log in different hosts which share gconf storage (e.g. home directory), and you want NumLock state saved separately for each of those hosts. In that case, if a host you're logging in is named localhost, you can't know if there is more than one, therefore you disable the feature. I can agree that in the above use case, having a host named localhost would be erroneous. However, the use case of a typical laptop system is that it constantly switches networks, and with NetworkManager, hostname either changes multiple times during each desktop session, or it is set to "localhost" all the time. Former is fairly supportable nowdays with recent fixes in most gnome applications, but different non-gnome applications still have trouble with this. I would assume that the idea of saving per-host NumLock setting pretty much looses its purpose in such a scenario, either way. And if certain functionality is disabled when there is no benefit from it, I agree that a message is useful when debugging or checking why something doesn't work, but warning about it seems confusing. Finally, it is a minor, cosmetic issue, but if we avoid such non-fixable warnings in console output (e.g. redirected to .xsession-errors), it will improve visibility of other warnings that are actually signaling something going wrong.
> networks, and with NetworkManager, hostname either changes multiple times > during each desktop session Why does it change its hostname? IP address, sure, but hostname? > I would assume > that the idea of saving per-host NumLock setting pretty much looses its purpose > in such a scenario, either way. Might be. > I agree that a message is useful when debugging or > checking why something doesn't work, but warning about it seems confusing. How about simply demoting it to info level, then?
(In reply to comment #6) > Why does it change its hostname? IP address, sure, but hostname? If a distribution wants to set up NetworkManager as a default network configuration provider (recent Fedora, Ubuntu?), you want it to set the host name for systems that depend on it. E.g. thin clients that are installed without any specific configuration, and their properties are saved on the central server which provides them with IP through dhcp that in turn depends on MAC address. Laptops that connect to such networks probably don't need hostname, but at the same time shouldn't break if hostname is (re)set. This behavior would enable both use cases to operate without any required pre-configuration on either system type. > How about simply demoting it to info level, then? Agreed, that definitely seems reasonable. Thanks.
2009-04-02 Jens Granseuer <...> * plugins/keyboard/gsd-keyboard-manager.c: (numlock_gconf_state_key): use info level instead of warning for the "NumLock remembering disabled" message (bug #577578)