| Summary: | kwin marks local Emacs as remote in the window title because WM_CLIENT_MACHINE and $HOST differ | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Stephen Berman <stephen.berman> |
| Component: | compatibility | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | slavek.banko |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.6.2 | |
| Sentry Crash Report: | |||
| Attachments: | Assembly hostname according to the DNS instead of NIS | ||
|
Description
Stephen Berman
2010-11-06 22:33:26 UTC
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. 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 Created attachment 71290 [details]
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.
Please, how can I reopen this bug? It is not resolved / fixed. @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. 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) @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? 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. 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 ;-) 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. > 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. (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. (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. (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 Reopening because this bug is NOT fixed and never was, see the discussion. 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 *** |