Bug 81060
| Summary: | gnome-terminal -x is adding --display in the wrong place | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | George Karabin <gkarabin> | ||||
| Component: | gnome-terminal | Assignee: | Havoc Pennington <hp> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | phoebe | CC: | jturner, wtogami | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2003-02-08 18:53:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 79578 | ||||||
| Attachments: |
|
||||||
Created attachment 89296 [details]
List of recently installed rawhide packages
I recently updated a number of packages from rawhide, including the panel and
other gnome packages. This problem went away afterwards.
Let's assume it was a libc glitch or the like then, there's been some stuff like that. Let us know if the bug returns. Oddly enough, with no changes to my installed software, the problem came back this afternoon. Even more odd, the problem didn't occur this morning. I'm going to reopen the bug, although now I'm kind of wondering about it's reproduceability. Is there an easy way to strace something run from the panel? You could make "strace -f -o /tmp/output foo" the command to be run by the launcher. Doh! Anyway, doing that showed as the first line:
3559 execve("/usr/bin/ssh", ["ssh", "monarch.sdca.asp.ti.com", "--display",
":0.0"], [/* 21 vars */]) = 0
Oh, crap. gnome-panel probably adds the --display to attempt to handle the multihead case. I'll file a gnome.org bug Except I can't reproduce the problem. "rpm -q gnome-panel"? "rpm -q gnome-desktop"? Do you have a multihead system? I don't have a multihead system, although I do have a laptop with a docking station, so there are two different displays in use at different times. I can't imagine that gnome can tell that, and get confused by it, but there you go, in case it matters. Here are the versions: gnome-panel-2.1.90.1-2 gnome-desktop-2.1.90-1 Ah, here we go: http://bugzilla.gnome.org/show_bug.cgi?id=103487 I think we can blame gnome-terminal. I think I know when I broke it, even. gnome-terminal 2.2.0 should have a working fix for this. *** Bug 82117 has been marked as a duplicate of this bug. *** I can't replicate this bug either, so hoping that the original poster will confirm that the new gnome-terminal code does indeed fix the problem. Sorry for the long delay - my machine had been less than stable and I hadn't had a chance to boot into phoebe at work for a while. I can verify that gnome-terminal-2.2.0.-2 isn't showing the problem anymore. Thanks! Closing this out based on feedback from original poster. |
Description of problem: Version-Release number of selected component (if applicable): gnome-panel-2.1.4-4 How reproducible: 100% Steps to Reproduce: 1. Create a new launcher on desktop or panel. 2. Select "Run in Terminal" and enter a simple ssh command, like "ssh hostname" (no quotes) to some ssh-computer on the network. 3. Execute the launcher. Actual results: A gnome-terminal will pop up and after authentication is complete it will briefly flash a message about :0.0 not being found (at least, this is what I see with a remote zsh shell, other shells might conceivably vary). Then the terminal will exit. Expected results: The terminal should stay open - no command should have been passed over the ssh link. Additional info: When I issue the same ssh command from the command line, I don't see any problem. Likewise, if I explicitly give ssh the name of a command to run on the remote machine (like "xterm") the command runs properly.