256258 2010-11-06 22:33:26 +0000 kwin marks local Emacs as remote in the window title because WM_CLIENT_MACHINE and $HOST differ 2012-10-15 12:00:18 +0000 1 1 4 Plasma kwin compatibility unspecified openSUSE Linux RESOLVED DUPLICATE 308391 NOR wishlist --- 0 stephen.berman kwin-bugs-null slavek.banko 4.6.2 0 oldest_to_newest 1041156 0 stephen.berman 2010-11-06 22:33:26 +0000 Version: unspecified (using KDE 4.5.2) OS: Linux The window title of Emacs 24 (built from Emacs bzr repository sources) always ends in the string " <@escher.home> ", which I was told means that kwin identifies the application as running on a remote machine; however, it is running locally. This is the bug; what follows are some analysis and hypotheses. I reported this problem to the Emacs developers list (see http://permalink.gmane.org/gmane.emacs.devel/132402 and followups) and learned that Emacs 24 (unlike earlier versions) sets WM_CLIENT_MACHINE by gethostbyname(), which returns the FQDN, which is "escher.home". The developer surmised that kwin uses the hostname, which is just "escher" (both the FQDN and the short name are listed in /etc/hosts). So it appears that kwin does not recognize that "escher.home" and "escher" refer to the same machine. Would it be possible for kwin to check /etc/hosts or to use gethostbyname()? Reproducible: Always Steps to Reproduce: Start a recent build of Emacs 24 as local X application under kwin. The window title can be changed within the running Emacs by setting the variable frame-title-format, e.g. to some string value, or also to nil (no title). Actual Results: Whatever the value of frame-title-format is set to, the window title ends in the string " <@full.hostname> ", where "full.hostname" is the full hostname appearing in /etc/hosts, not the short variant. Expected Results: The window title should not end in " <@full.hostname> ", since the application is running locally. 1041159 1 mgraesslin 2010-11-06 22:53:24 +0000 This looks like an emacs bug to me. Please see the standard for it: http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.9 > The client should set the WM_CLIENT_MACHINE property (of one of the TEXT types) to a string that forms the name of the machine running the client as seen from the machine running the server. I assume for the server it will just be escher and not the fqdn. It is rather unusual to identify the local machine with a fqdn. Anyway it's not a bug in kwin, but a regression in emacs. If they change something like that, they should revert and not tell window managers to adjust their code. 1098826 2 mgraesslin 2011-03-19 10:46:47 +0000 I assume this is fixed with the following commit: commit c24ea2b4aac214ce29afc013cc037c110a24aa12 Author: Luboš Luňák <l.lunak@suse.cz> Date: Fri Mar 4 16:22:23 2011 +0100 do not show hostname in titlebar if it's FQDN of localhost If not fixed in 4.6.2 please reopen 1257302 3 71290 slavek.banko 2012-05-22 11:51:06 +0000 Created attachment 71290 Assembly hostname according to the DNS instead of NIS When I wanted to incorporate to Trinity patch from your commit c24ea2b4, I found that it does not work properly. To build the full qualified host name is used NIS domain instead of the DNS domain. NIS domain but may either be different or none at all. Therefore I have prepared a new patch - see commit 9e3f8a7f in Trinity. 1257304 4 slavek.banko 2012-05-22 11:54:38 +0000 Please, how can I reopen this bug? It is not resolved / fixed. 1305797 5 thomas.luebking 2012-10-14 14:56:26 +0000 @Slávek The trinity patch is likely borrowed from the kwin patch Martin mentioned. The major difference is the usage of the POSIX confirm getaddrinfo() while the kwin code includes the BSD/Linux only getdomainname() That said: deactivating title trimming in the bespin deco (which i maybe really should move upstream? /advert), a see this in emacs as well, having a look into the resolution now. 1305799 6 thomas.luebking 2012-10-14 15:09:12 +0000 Sorry to say, but that's an emacs thing, the hostname is in the set caption and *not* added by kwin (it's also present the very same way in _every_ WM i tested - and I've quite some flying around) The host is properly resolved (and also simple in my case) and the caption is "emacs@hostname" and *not* "emacs<@hostname>" So unless you hit this with sth. that is not the "I-am-special" emacs, the only valid bug in this regard would be the posix incompliance (what does not affect you unless you're on some Oracle OS and would not change the visual outcome either) 1305800 7 thomas.luebking 2012-10-14 15:18:05 +0000 @Slavik You're however in general absolutely right about NIS ./. DNS, ie. getdomainname being isuffiencient in that case, but that's actually a completely different bug -> please refile and ideally provide a patch at git.reviewboard.kde.org out of curiosity: local bind or sth. OS specific? 1305802 8 slavek.banko 2012-10-14 15:28:26 +0000 The patch, which is used as a solution mentions LibreOffice. And that LibreOffice is what the patch not resolved. In other words, the original patch from KDE4.x not fulfilling its purpose - not even a little bit. Comment I added to this issue because, at this issue is patch listed as its solution. 1305816 9 thomas.luebking 2012-10-14 16:11:28 +0000 it's not the same bug and cannot be since the insufficient patch is newer than the bug. you pointed the issues with getdomainname under a certain scenario, but that issue could not have possibly existed when this bug was filed so we cannot legally resolve DNS/NIS by closing this bug. why hijacking a different dead bug is a bad idea has nicely been illustrated within the last hour when i wasted time on checking emacs ;-) 1305821 10 slavek.banko 2012-10-14 16:39:39 +0000 Bad that Martin improperly stated the patch from Lukáš for this bug. Otherwise I would my comment to this error not written. I just created an account on the Review Board to be able to put a patch to Review Board... For first I must a bit to learn Review Board. 1305827 11 mgraesslin 2012-10-14 16:47:01 +0000 > Bad that Martin improperly stated the patch from Lukáš for this bug. > Otherwise I would my comment to this error not written. Ah I don't use emacs and the bug looked similar :-) > > I just created an account on the Review Board to be able to put a patch to > Review Board... For first I must a bit to learn Review Board. easiest way is with post-review especially in combination with git. 1305843 12 thomas.luebking 2012-10-14 18:11:32 +0000 (In reply to comment #10) > Bad that Martin improperly stated the patch from Lukáš for this bug. Actually sounds like a reasonable assumption - the reporter even might have spotted the total absence of a usable hostname resolution. > Otherwise I would my comment to this error not written. General rule of thumb: unless there's a commit message that closes the bug and you can say that this committed fix does actually not fix that very bug - just open a new bug, pointing out the issue with the status quo. Reviving bugs simply doesn't work. > I just created an account on the Review Board to be able to put a patch to > Review Board... For first I must a bit to learn Review Board. It's not very hard, you need an updated git branch with the desired patch on to of the origins HEAD, then you can just add a new review (component is kde-workspace) of that diff. 1305848 13 slavek.banko 2012-10-14 18:26:58 +0000 (In reply to comment #12) > > Otherwise I would my comment to this error not written. > General rule of thumb: unless there's a commit message that closes the bug > and you can say that this committed fix does actually not fix that very bug > - just open a new bug, pointing out the issue with the status quo. > > Reviving bugs simply doesn't work. Aha - I'm used to from other bugzilla, where reopening commonly used. After all, that's why I asked this before, as it does here. > > > I just created an account on the Review Board to be able to put a patch to > > Review Board... For first I must a bit to learn Review Board. > It's not very hard, you need an updated git branch with the desired patch on > to of the origins HEAD, then you can just add a new review (component is > kde-workspace) of that diff. Well, simple - but I have complete GIT clone Trinity, but neither piece KDE4.x. Therefore, I hope that you will be able to adapt the patch yourself. The fact that you want me to set the patch on a silver platter, it's more complicated for me. 1305852 14 thomas.luebking 2012-10-14 18:39:37 +0000 (In reply to comment #13) > Aha - I'm used to from other bugzilla, where reopening commonly used. After > all, that's why I asked this before, as it does here. Re-opening does work, reviving a 18 months old bug rather not ;-) > KDE4.x. Therefore, I hope that you will be able to adapt the patch yourself. Sure, no problem. > The fact that you want me to set the patch on a silver platter, it's more > complicated for me. It wasn't thought like that but rather a) get in more committers b) have your name under the patch 1306107 15 kevin.kofler 2012-10-15 11:38:37 +0000 Reopening because this bug is NOT fixed and never was, see the discussion. 1306114 16 thomas.luebking 2012-10-15 12:00:18 +0000 there's a more precise bug available, this one's incredibly ambiguous because emacs sets the hostname in the title anyway and that will not be fixed with the fqdm check either. if that's your problem, you can mark it as won't fix and contact emacs authors. *** This bug has been marked as a duplicate of bug 308391 *** 71290 2012-05-22 11:51:06 +0000 2012-05-22 11:51:06 +0000 Assembly hostname according to the DNS instead of NIS bp030-9e3f8a7f.diff text/plain 1551 slavek.banko Y29tbWl0IDllM2Y4YTdmMGM5ZjJlZDExMjVjNzE3ZjUzNzRhYWY4ZDRlYzIyNWUKQXV0aG9yOiBU aW1vdGh5IFBlYXJzb24gPGtiOXZxZkBwZWFyc29uY29tcHV0aW5nLm5ldD4KRGF0ZTogICAxMzMw ODAzOTIzIC0wNjAwCgogICAgRml4IGhvc3RuYW1lIGRpc3BsYXkgaW4gdGl0bGViYXIgd2l0aCBj ZXJ0YWluIHByb2dyYW1zCiAgICBUaGlzIGNsb3NlcyBCdWcgODg5CiAgICBUaGFua3MgdG8gU2zD oXZlayBCYW5rbyBmb3IgdGhlIHBhdGNoIQoKZGlmZiAtLWdpdCBhL2t3aW4vdXRpbHMuY3BwIGIv a3dpbi91dGlscy5jcHAKaW5kZXggOTNkMTQwOC4uMTE1OWRlYiAxMDA2NDQKLS0tIGEva3dpbi91 dGlscy5jcHAKKysrIGIva3dpbi91dGlscy5jcHAKQEAgLTE4LDYgKzE4LDggQEAgTGljZW5zZS4g U2VlIHRoZSBmaWxlICJDT1BZSU5HIiBmb3IgdGhlIGV4YWN0IGxpY2Vuc2luZyB0ZXJtcy4KICNp bmNsdWRlICJ1dGlscy5oIgogCiAjaW5jbHVkZSA8dW5pc3RkLmg+CisjaW5jbHVkZSA8c3RyaW5n Lmg+CisjaW5jbHVkZSA8bmV0ZGIuaD4KIAogI2lmbmRlZiBLQ01SVUxFUwogCkBAIC0zMjMsNiAr MzI1LDI3IEBAIGJvb2wgaXNMb2NhbE1hY2hpbmUoIGNvbnN0IFRRQ1N0cmluZyYgaG9zdCApCiAg ICAgICAgICAgICBpZiggaG9zdCA9PSBob3N0bmFtZWJ1ZiApCiAgICAgICAgICAgICAgICAgcmV0 dXJuIHRydWU7CiAgICAgICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHsgLy8g ZS5nLiBMaWJyZU9mZmljZSBsaWtlcyB0byBnaXZlIEZRRE4sIGV2ZW4gaWYgZ2V0aG9zdG5hbWUo KSBkb2Vzbid0IGluY2x1ZGUgZG9tYWluCisgICAgICAgICAgICBzdHJ1Y3QgYWRkcmluZm8gaGlu dHMsICpyZXMsICphZGRyOworICAgICAgICAgICAgYm9vbCBpc19sb2NhbCA9IGZhbHNlOworCisg ICAgICAgICAgICBtZW1zZXQgKCZoaW50cywgMCwgc2l6ZW9mIChoaW50cykpOworICAgICAgICAg ICAgaGludHMuYWlfZmFtaWx5ID0gUEZfVU5TUEVDOworICAgICAgICAgICAgaGludHMuYWlfc29j a3R5cGUgPSBTT0NLX1NUUkVBTTsKKyAgICAgICAgICAgIGhpbnRzLmFpX2ZsYWdzIHw9IEFJX0NB Tk9OTkFNRTsKKworICAgICAgICAgICAgaWYoIGdldGFkZHJpbmZvKCBob3N0LCBOVUxMLCAmaGlu dHMsICZyZXMgKSAhPSAwKQorICAgICAgICAgICAgICAgIHJldHVybiBmYWxzZTsKKyAgICAgICAg ICAgIGZvcihhZGRyID0gcmVzOyAhaXNfbG9jYWwgJiYgYWRkcjsgYWRkciA9IGFkZHItPmFpX25l eHQpCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgIGlmKCByZXMtPmFpX2Nhbm9u bmFtZSAmJgorICAgICAgICAgICAgICAgICAgICBob3N0ID09IFRRQ1N0cmluZyggcmVzLT5haV9j YW5vbm5hbWUgKSkKKyAgICAgICAgICAgICAgICAgICAgaXNfbG9jYWwgPSB0cnVlOworICAgICAg ICAgICAgICAgIH0KKyAgICAgICAgICAgIGZyZWVhZGRyaW5mbyhyZXMpOworICAgICAgICAgICAg cmV0dXJuIGlzX2xvY2FsOworICAgICAgICAgICAgfQogICAgICAgICB9CiAgICAgcmV0dXJuIGZh bHNlOwogICAgIH0K