[Bug 17962] Re: newly opened gnome-terminal windows don't have .bash_profile sourced
No argument of any sort was made in #8, specious or otherwise; only an observation. And placing profiley stuff into bashrc slows down the shell (as if it's not slow enough already!) Adding things to PATH that you want access to in all your interactive shells, belongs in the file sourced by interactive shells, not merely login ones. There's nothing profiley about that. And it would be entirely inappropriate for GDM or ~/.xsession or the like to source a bash-specific profile script file (as ~/.bash_profile surely is) without the user configuring it to do so, most particularly when bash isn't the usual system shell under which those things would be running (and it's certainly not interactive). Interactive shell stuff goes in the ~/.foorc (~/.bashrc, ~/.kshrc, what have you); MOTD and other once-only, truly profilish-type setup stuff goes in the profile source files, and none of those should be sourced by non-interactive X shell scripts (such as ~/.Xsession) running under /bin/sh (= dash). There's a reason why the default ~/.profile sources ~/.bashrc, and does nothing else by default (though, if it's going to source ~/.bashrc, it ought to have been a ~/.bash_profile, and not ~/.profile, but that's an entirely separate issue). It has been the case for _decades_ that terminal emulators by default spawn interactive, non-login shells. Changing this to satisfy a few people who failed to configure their interactive shells correctly, would surely cause more harm to those who expect things to work the way they always have, than benefit to those who are confused about how to properly set up their source files. Bottom line, you want your profile sourced, configure your emulator to spawn login shells. Not hard: /bin/bash -l versus /bin/bash. And if you want certain items to be in your PATH across all interactive shells, put it in the correct file. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/17962 Title: newly opened gnome-terminal windows don't have .bash_profile sourced To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/17962/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 778801] Re: TERM unconditionally set to xterm, regardless of config
FWIW, the workaround I've been using for some time now is: if [ \( x$COLORTERM = xgnome-terminal -o x$COLORTERM = xTerminal -o x$COLORTERM = xxfce4-terminal \) -a x$TERM = xxterm ] infocmp xterm-256color /dev/null 21; then TERM=xterm-256color fi in my .bashrc or what have you. The Terminal was what worked in Precise and prior; xfce4-terminal is what COLORTERM is now set to. (The infocmp command verifies that there is a terminfo database entry for xterm-256color, so it doesn't get set and then terminal apps haven't a clue how to talk to the terminal.) -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/778801 Title: TERM unconditionally set to xterm, regardless of config To manage notifications about this bug go to: https://bugs.launchpad.net/vte/+bug/778801/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 778801] Re: TERM unconditionally set to xterm, regardless of config
(the line wrapped for the first if line; that needs to be a single line to work) -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/778801 Title: TERM unconditionally set to xterm, regardless of config To manage notifications about this bug go to: https://bugs.launchpad.net/vte/+bug/778801/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 778801] Re: TERM unconditionally set to xterm, regardless of config
According to the discussion on the Gnome VTE bug linked, calling vte_terminal_set_emulation won't work either, unless it happens to be recognized as a supported emulation mode. xterm-256color isn't, so this solution wouldn't work. There doesn't seem to be an obvious, clean way to fix the problem within xfce4-terminal; vte is the one holding all the cards AFAICT. According to discussion on the Gnome VTE bug, vte_terminal_fork_command_full is just a wrapper around some other functions, but one of those functions (__vte_pty_spawn) probably isn't safe to call by users. Perhaps the correct solution should be for vte to revert to its previous behavior, whereby it didn't brutally murder pre-existing TERM settings when the terminal app sets them. If the upstream vte folks don't want to consider this, Ubuntu probably should. ** Also affects: vte (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/778801 Title: TERM unconditionally set to xterm, regardless of config -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 778801] Re: TERM unconditionally set to xterm, regardless of config
Added vte, until it's clearer which of xfce4-terminal and vte should fix this (as I said, though, it looks to me like only vte _can_ fix it, though upstream seems unwilling). -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/778801 Title: TERM unconditionally set to xterm, regardless of config -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 778801] Re: TERM unconditionally set to xterm, regardless of config
Note that gnome-terminal isn't effected, since gnome-terminal doesn't give the user the option to specify the TERM value to begin with. This is generally a desirable feature to have, though. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in Ubuntu. https://bugs.launchpad.net/bugs/778801 Title: TERM unconditionally set to xterm, regardless of config -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
The fix is now in place for the Ubuntu Natty, and it looks like upstream is going to include it for future versions of vte. Nice to finally be able to use gnome-terminal with screen and tmux without glitchy graphics :) Note: at least one person had difficulty reproducing this on their system using the shell script I originally created; the linked Gnome bug report has an improved version attached, that allowed them to reproduce it more reliably. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. https://bugs.launchpad.net/bugs/246701 Title: Change Scroll Region and display glitch -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
(Please note: the debdiff above is now out-of-date; but can still be used, and then just replace the file in debian/patches.) (There is also now a merge proposal against https://bazaar.launchpad.net /~ubuntu-desktop/vte/ubuntu/changes, which does use the updated patch.) -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. https://bugs.launchpad.net/bugs/246701 Title: Change Scroll Region and display glitch -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
Minor fix to patch; addresses the same problem in a few cases apparently not exercised by the automated script. ** Patch added: Revised patch. https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701/+attachment/1759318/+files/lp246701_scroll_region_updates.patch -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. https://bugs.launchpad.net/bugs/246701 Title: Change Scroll Region and display glitch -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
Found the source of the problem. The vte_terminal_process_incoming function from vte.c keeps track of a bounding box of cells to be invalidated, and uses that to invalidate cells at points such as after all input has been processed, or when a large enough cursor jump is made (to avoid letting the bounding box get needlessly large). This bounding box is represented in terms of the total number of lines in the terminal, including history. The problem that arises is that if a scroll takes place before the bounding box has been used to invalidate cells, then a new row is added to the total terminal rows, increasing the index number of the bottom rows. Thus, the bounding box will now be off by one (or however large the scroll is), and no longer reaches all the way to the bottom of the screen (if it did before). This problem applies, even when no scrollback history is enabled, as the relevant indexes all still increase, even though the true number of actual data rows hasn't changed. The fix I implemented is to force invalidation to take place if we move into a scroll region from outside it. ** Patch added: lp246701_scroll_region_updates.patch https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701/+attachment/1750778/+files/lp246701_scroll_region_updates.patch -- Change Scroll Region and display glitch https://bugs.launchpad.net/bugs/246701 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
** Patch added: debdiff against Maverick's vte https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701/+attachment/1750780/+files/vte_0.26.0-0ubuntu3.debdiff -- Change Scroll Region and display glitch https://bugs.launchpad.net/bugs/246701 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 406515] Re: [Karmic] Brightness fn keys lost functionality (multiple laptops)
Same issue on a Compaq CQ60. Only missing the brightness keys, no others; were working fine in Jaunty. No messages from xev or acpi_listen. -- [Karmic] Brightness fn keys lost functionality (multiple laptops) https://bugs.launchpad.net/bugs/406515 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-power-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 501414] [NEW] gnome-terminal crashes on insert line sequene
Public bug reported: Steps to reproduce: 1. Open a fresh gnome-terminal. There must be lines below the prompt to which text has never yet been written. 2. Enter the command: $ printf '\033[L' (the INSERT LINE sequence will be sent to gnome-terminal) 3. gnome-terminal crashes. My assumption is that this is a vte bug; if it's a gnome-terminal bug, please redirect appropriately (I'm on a work machine, and don't want to install xfce4 stuff to check this). This is on Karmic. gnome-terminal 2.28.1-0ubuntu1, libvte9 1:0.22.2-0ubuntu2 ** Affects: vte (Ubuntu) Importance: Undecided Status: New -- gnome-terminal crashes on insert line sequene https://bugs.launchpad.net/bugs/501414 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 231502] Re: Passphrase dialog doesn't accept input
I'm currently using these three, as unsetting just GPG_AGENT_INFO no longer seems sufficient. unset GPG_AGENT_INFO unset SSH_AUTH_SOCK unset GNOME_KEYRING_SOCKET (Not all of these necessarily relate to seahorse? I dunno, I just fix what breaks for me. :) -- Passphrase dialog doesn't accept input https://bugs.launchpad.net/bugs/231502 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 17962] Re: newly opened gnome-terminal windows don't have .bash_profile sourced
As an end user, then, you should add ~/bin/ to your path from within .bashrc, rather than .bash_profile. It has long been historical practice for xterms and the like not to spawn login shells by default. For this reason, people have for many years followed the practice of placing anything important in the rc file, and sourcing the rc file from within their profile. The only other things that should go in a profile are things specific to login shells... things that ought to be followed for _every_ interactive shell, belong in the rc file (that's the rc file's purpose). These bugs are nothing more than a matter of confusion on the user's part for what purposes are served by the *rc and *profile files that a typical shell program supports. -- newly opened gnome-terminal windows don't have .bash_profile sourced https://bugs.launchpad.net/bugs/17962 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 17962] Re: newly opened gnome-terminal windows don't have .bash_profile sourced
(I'll just add here that FWIW Ubuntu does not in fact ship with .bash_profile at all, just the .bashrc) -- newly opened gnome-terminal windows don't have .bash_profile sourced https://bugs.launchpad.net/bugs/17962 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
David, that's really a separate issue and should get a separate report (but I can confirm the same behavior on Intrepid, though showkey doesn't work for me). -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
TERM=screen screen is _never_ good advice (unless you're running screen -m directly inside of a screen session). Also, if TERM=screen screen fixes your problem, then your problem had nothing to do with this bug, which is specifically that some terminals send ^@ screen, rather than the usual ^? or ^H. Other backspace problems are nearly always a problem of incorrect terminfo descriptions for the parent terminal, or incorrect stty settings. Stty is the easiest to fix, so start with stty erase ^? and work from there. -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
Morten, is this the same Wuff, Wuff problem, which shows ^@ chars inside cat? If so, the way to fix this is to turn off any autodetection settings for what backspace should send, and explicitly specify the code it should send (probably, ^?). You could also download the latest sources for screen via the git repository at Savannah, as we've fixed this on our end as well as submitting the vte patch. If not, then you should file a new bug or ask for help on an appropriate forum (such as screen-us...@gnu.org). -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 231504] Re: Seahorse possibly deletes secret keys
Thanks, Seb. I'm going to go ahead and close this out then. I'm not using Seahorse any more, so there's no way I'll be reproducing this any time soon. ** Changed in: seahorse (Ubuntu) Status: New = Invalid -- Seahorse possibly deletes secret keys https://bugs.launchpad.net/bugs/231504 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to seahorse in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
That link is not the same issue; it has to do with the terminfo and stty disagreeing with eachother. Fixing either the terminfo or stty should fix the problem (they agree with each other in upstream screen AFAICT; they disagree in some packages). This bug has to do with vte-based terminals, such as xfce4-terminal and TerminalScreenlet, sending ascii NUL (^@) for backspace when they are set to auto-detect what to send for backspace, which is a different issue. Other backspace problems are nearly always misconfigurations of the environment. They will always exist, because such misconfigurations will always occur easily. -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
That's a different problem, if it's the first line that's working for you. A much better solution is to keep the backspace as ^?, and make sure stty erase ^? is set for the terminal (or that the terminal is otherwise set to send ^?). It makes a much better choice than ^H, which confuses some programs (notably Emacs). -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
Just because it's a config issue, does not mean it's not a bug. The bug (as explained in the original description) is that changing it away from autodetect is required. Tracked down the source of the problem: vte will send whatever the terminal's erase character is, even when it's undefined (that is, '\0'); screen unsets erase and other keys. Vte ought to fall back on a reasonable value, rather than issue the obviously-wrong [EMAIL PROTECTED] ^? seems like a good candidate... Screen should probably leave the value alone as well. Will investigate why this is done, in the Savannah bug whose link was posted earlier. -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 232027] Re: Closing tab results in not accepting input, when XIM is active
The problem isn't gnome-terminal: I've recently noticed that things like changing workspaces, or closing windows, can cause input not to be received in a window until I Alt-Tab twice to transfer focus away and back. This happens in a variety of applications, and so is not gnome- terminal specific. However, I'm unsure wherein the bug lies: could be SCIM, could be the wm (Metacity), could be X itself... Will try to find a better package to shift this to in the meantime. ** Changed in: scim (Ubuntu) Sourcepackagename: gnome-terminal = scim ** Summary changed: - Closing tab results in not accepting input, when XIM is active + Input ignored when switching workspaces, closing windows... -- Input ignored when switching workspaces, closing windows... https://bugs.launchpad.net/bugs/232027 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
** Attachment added: Debdiff (hardy) http://launchpadlibrarian.net/16103643/vte.debdiff -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
Note; the patch above includes literal control characters in the source, namely the ^? (DEL) character; it may not display properly, depending on what you use to view it. I find this practice distasteful, but the surrounding code included literal control characters as well, so I bowed to consistency. -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
** Attachment added: Debdiff (intrepid) http://launchpadlibrarian.net/16104491/vte-intrepid.diff -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
Setting to Confirmed per https://wiki.ubuntu.com/Bugs/HowToFix ** Changed in: vte (Ubuntu) Status: New = Confirmed -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
** Bug watch added: GNOME Bug Tracker #543379 http://bugzilla.gnome.org/show_bug.cgi?id=543379 ** Also affects: vte via http://bugzilla.gnome.org/show_bug.cgi?id=543379 Importance: Unknown Status: Unknown -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 29787] Re: Backspace key in GNU Screen not detected correctly
Retargeting at vte; All xfce4-terminal does is call vte_terminal_set_backspace_binding with VTE_ERASE_AUTO. ** Changed in: vte (Ubuntu) Sourcepackagename: xfce4-terminal = vte Status: Invalid = New -- Backspace key in GNU Screen not detected correctly https://bugs.launchpad.net/bugs/29787 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
See also the bugtracker for GNU Screen, where I discovered and analyzed the problem. https://savannah.gnu.org/bugs/?23699 -- Change Scroll Region and display glitch https://bugs.launchpad.net/bugs/246701 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] Re: Change Scroll Region and display glitch
** Attachment added: scr-fix-min http://launchpadlibrarian.net/15894412/scr-fix-min ** Bug watch added: GNOME Bug Tracker #542087 http://bugzilla.gnome.org/show_bug.cgi?id=542087 ** Also affects: vte via http://bugzilla.gnome.org/show_bug.cgi?id=542087 Importance: Unknown Status: Unknown -- Change Scroll Region and display glitch https://bugs.launchpad.net/bugs/246701 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 246701] [NEW] Change Scroll Region and display glitch
Public bug reported: Please describe the problem: After sending CSR so that the final line in the terminal is excluded from the scroll region, glitches can occur when interspersing writes to the bottom line with scrolls of the upper region. Steps to reproduce: I will attach a script (scr-fix-min) that produces the problem for me. NOTE: This script expects LINES and COLUMNS to be exported and refer to the number of lines and columns in your terminal. These must be accurate or the bug won't be shown. If they are unset, you will get a ton of errors, rather than the simulation. If one is running bash, then $ export COLUMNS LINES $ ./scr-fix-min will probably work. Otherwise, COLUMNS and LINES may need to be set explicitly before running the script. Actual results: What I currently see: one or both of foo and bar are missing. Or, on at least one system, the bar will be black/empty when it ought to be reversed/have-text. Actually, when I _should_ see foo and bar, but don't, I will sometimes actually see an effect such that it looks like the top one or two pixel-rows of the bottom line update and switch back, but not the rest of the line. So a masking problem or incorrect information about what portions of the display to update seem likely. Expected results: What you ought to see: the bottom bar flash between x, foo, x, and bar. Does this happen every time? This reproduces reliably for me on gnome-terminal. xfce4-terminal sometimes shows both foo and bar as it ought to, and sometimes doesn't (same app, same instance, different runs of script). Other information: This behavior was discovered while I was using screen, which can use the final line as a status line. I was playing with screen's autoaka feature, which allows the current screen window's name to change based on the currently-running command: I found that everything worked as it should until the prompt reached the bottom, so that hitting enter caused scrolling. At that point, the window title would stop updating. ** Affects: vte Importance: Unknown Status: Unknown ** Affects: vte (Ubuntu) Importance: Undecided Status: New -- Change Scroll Region and display glitch https://bugs.launchpad.net/bugs/246701 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 232027] Re: Closing tab results in not accepting input
I thought it was quite clear: what is unclear about it? (Being unclear, and being unreproducible to you, strike me as distinct complaints.) No other steps. The given steps reproduce the problem very reliably for me. Obviously there's a difference between my environment and yours, but as to what it might be, I couldn't guess. Since gnome-terminal itself is actually responding to Control-Shift-T for opening new tabs, or Control-Shift-N for new windows, it seems entirely possible that the issue is really with libvte, or perhaps some issue involving both gnome-terminal and libvte. The fact that having opened a new tab or window alters the behavior, though, tells me that gnome-terminal must have at least something to do with it. I've attached my profile settings, in case they are part of why I'm able to reproduce the problem. I'll try blowing it away, meanwhile, to see if that stops the issue. Since I'm at my laptop, I now have the gnome-terminal version available: 2.22.1-0ubuntu2 libvte9 is 1:0.16.13-1ubuntu1. ** Attachment added: ~/.gconf/apps/gnome-terminal/profiles/Default/%gconf.xml http://launchpadlibrarian.net/14805240/%25gconf.xml -- Closing tab results in not accepting input https://bugs.launchpad.net/bugs/232027 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 232027] Re: Closing tab results in not accepting input
Okay, so I verified that, while blowing away my gnome-terminal config and restarting GNOME does not eliminate the problem, a fresh new account does not exhibit the symptoms. The difference appears to be that my normal account is set up to use the SCIM X Input Method. On a fresh account, if I do an im-switch -s scim, and then restart that user's GNOME session, I am then able to reproduce the symptoms on that account, using the steps I described. So, the issue is likely that gnome-terminal mishandles something related to XIMs (though, it _could_ be SCIM-specific). People that use gnome-terminal and need to type in relatively exotic (usually, Asian) characters, will likely experience this problem, while folks who can get what they need from ASCII characters and maybe dead- letter keys or combination keys, probably won't. ** Changed in: gnome-terminal (Ubuntu) Status: Incomplete = New ** Summary changed: - Closing tab results in not accepting input + Closing tab results in not accepting input, when XIM is active ** Description changed: Binary package hint: gnome-terminal Steps to reproduce (some steps may not be necessary; I'm not on my home machine right now so can't eliminate the unnecessary steps): 1. Open gnome-terminal 2. Type some stuff (may not be necessary) 3. Open a new tab via Control-Shift-T 4. Type some stuff (may not be necessary) 5. Close the tab (I usually do this via Control-D in the shell) Resulting Behavior: Keys typed in the original tab are no longer processed (they are, however, queued up: see the Workarounds). Expected Behavior: Keys typed in the original tab should be processed as normal, appearing and taking effect in the terminal. Workarounds: - - Opening a new tab again will cause all the keys that had been typed in the original tab to be processed immediately. Closing that tab again results in the same buggy behavior. + - Opening a new tab again will cause all the keys that had been typed in the original tab to be processed immediately. Closing that tab again results in the same buggy behavior. [NOTE: this does not appear to be the case lately; nothing previously typed is processed, it must be retyped.] - Opening a new _window_, via Control-Shift-N, will cause all the keys to be processed immediately, and closing the new window does _not_ result in the original terminal window locking up again. Apologies for not specifying the gnome-terminal package version; I'm away from the affected system at this moment. However, I am running Hardy Heron (8.04), and my packages were up-to-date as of last night. -- Closing tab results in not accepting input, when XIM is active https://bugs.launchpad.net/bugs/232027 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 221516] Re: [Hardy] Key combination Ctrl-] is ignored
(setting to Confirmed due to an identified fix) ** Changed in: gnome-terminal (Ubuntu) Status: Incomplete = Confirmed -- [Hardy] Key combination Ctrl-] is ignored https://bugs.launchpad.net/bugs/221516 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 232027] [NEW] Closing tab results in not accepting input
Public bug reported: Binary package hint: gnome-terminal Steps to reproduce (some steps may not be necessary; I'm not on my home machine right now so can't eliminate the unnecessary steps): 1. Open gnome-terminal 2. Type some stuff (may not be necessary) 3. Open a new tab via Control-Shift-T 4. Type some stuff (may not be necessary) 5. Close the tab (I usually do this via Control-D in the shell) Resulting Behavior: Keys typed in the original tab are no longer processed (they are, however, queued up: see the Workarounds). Expected Behavior: Keys typed in the original tab should be processed as normal, appearing and taking effect in the terminal. Workarounds: - Opening a new tab again will cause all the keys that had been typed in the original tab to be processed immediately. Closing that tab again results in the same buggy behavior. - Opening a new _window_, via Control-Shift-N, will cause all the keys to be processed immediately, and closing the new window does _not_ result in the original terminal window locking up again. Apologies for not specifying the gnome-terminal package version; I'm away from the affected system at this moment. However, I am running Hardy Heron (8.04), and my packages were up-to-date as of last night. ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New -- Closing tab results in not accepting input https://bugs.launchpad.net/bugs/232027 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 231502] [NEW] Passphrase dialog doesn't accept input
Public bug reported: Binary package hint: seahorse Since upgrading to Hardy Heron, I ran into problems with the Passphrase dialog when using Enigmail with Thunderbird. It'll plug along fine, not grabbing focus, but accepting input. But then, at some point, I'll hit send on a message, the passphrase dialog will come up, and it won't accept input. Even if I click to give it focus, it still won't accept input. Characters don't show in the text box, and typing return won't confirm/close the dialog. Strangely, hitting Escape _will_ close the dialog. Once this starts happening, it seems to keep happening. Logging out/in, even restarting (IIRC) don't fix the problem. It took me a while to figure out that Enigmail was delegating the passphrase stuff to a gpg- agent, and wrapping thunderbird with a script that unsets GPG_AGENT_INFO did the trick (so that it doesn't call out to seahorse). Once I experienced the problem and tracked it to seahorse, I also tried gpg directly from the commandline with --use-agent, and see the same symptoms. ** Affects: seahorse (Ubuntu) Importance: Undecided Status: New -- Passphrase dialog doesn't accept input https://bugs.launchpad.net/bugs/231502 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to seahorse in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 231504] [NEW] Seahorse possibly deletes secret keys
Public bug reported: Binary package hint: seahorse Since upgrading to Hardy, a few times I've discovered my ~/.gnupg/secring.gpg to be truncated to zero bytes. I suspect seahorse, only because it's the major thing I can think of that has changed since the upgrade; I have never explicitly installed or configured seahorse, and AFAICT, Gutsy did not set it for use by default, whereas now GPG_AGENT_INFO seems to be directed at seahorse. At least, Enigmail/Thunderbird always used its builtin passphrase dialog previously, whereas now by default it uses seahorse's. I'm afraid I have zero reproduction info: I am not yet aware of the steps that lead to it being truncated, only that suddenly I can't sign emails because I have no secret keys. It's entirely possible that my problem is specific to the combination of Seahorse/Enigmail/Thunderbird. I'm hoping someone could give me tips on finding ways to reproduce the problem easily: I don't want to use Seahorse so have unset GPG_AGENT_INFO in a wrapper around Thunderbird, so am probably far less likely to reproduce it on my own now; but I'm willing to try things (and have backups of my keys). ** Affects: seahorse (Ubuntu) Importance: Undecided Status: New -- Seahorse possibly deletes secret keys https://bugs.launchpad.net/bugs/231504 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to seahorse in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121739] Re: terminal wont accept typed input when prompting for password
As previously mentioned, it's not nothing happens. It's accepting input, but hiding it. Just type the password and hit return. -- terminal wont accept typed input when prompting for password https://bugs.launchpad.net/bugs/121739 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 133723] Re: gnome-terminal locks up on unicode input
*** This bug is a duplicate of bug 121161 *** https://bugs.launchpad.net/bugs/121161 Hi, and thanks for reporting this bug. You've neglected to mention which version of gnome-terminal you're running, but actually, I think the more pertinent question is what version of libvte you're running. This looks to be a duplicate of bug 121161, which is reported to have been fixed in current development (Gutsy Gibbon), so I'm going to go ahead and mark this as such. Note that it's probably somewhat misleading to say that it's unicode input: all input is unicode input, and gnome-terminal has been working just fine with things like the compose key or other forms of unicode input (to produce characters such as é or ©). The real issue was that it wasn't working with X Input Methods. ** This bug has been marked a duplicate of bug 121161 scim-chewing will crash GNOME terminal. ** Changed in: gnome-terminal (Ubuntu) Status: New = Fix Released -- gnome-terminal locks up on unicode input https://bugs.launchpad.net/bugs/133723 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 106995] Re: gnome-terminal unconditionally interprets mouse wheel events
For me, this happens in Feisty as well, though I suspect it depends on the version of screen running (potentially, remotely)--or possibly bash --rather than of gnome-terminal. In order for such a thing to occur, bash must request screen to send it mouse button events, and screen must in turn request it of the xterm-like terminal running it. It seems likely that, for whatever reason, bash does not enable mouse-button support when running directly in gnome-terminal, but does when being run under screen. While it's hard to say for certain, my strong suspicion is that this is a bash issue, rather than a vte issue. However, as to whether this is truly a bug, I'm not sure. Note that, scrolling through the scrollback buffer when screen is active is useless anyway, since screen does not cause anything to be scrolled in the terminal; rather, it saves things to its own scrollback buffer, which can be accessed in copy mode (C-A C-[). -- gnome-terminal unconditionally interprets mouse wheel events https://bugs.launchpad.net/bugs/106995 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 126500] Re: vte has some trouble handling chinese language
*** This bug is a duplicate of bug 121161 *** https://bugs.launchpad.net/bugs/121161 Hi! This appears to be the same bug as bug 121161, so I'm marking this as a duplicate and closing it out. This issue has been fixed in the latest release of libvte in Gutsy. ** This bug has been marked a duplicate of bug 121161 scim-chewing will crash GNOME terminal. -- vte has some trouble handling chinese language https://bugs.launchpad.net/bugs/126500 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 115100] Re: Terminal displays as a blank window
If this is only a broblem for people using beryl or compiz, it seems very likely the fault lies with those, rather than gnome-terminal. -- Terminal displays as a blank window https://bugs.launchpad.net/bugs/115100 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 124251] Re: Ability to drag files out of the Terminal onto the Desktop or into other Applications
Sebastien, I don't find this a remotely simple feature request. Implementing this would take a very significant amount of planning, IMO. -- Ability to drag files out of the Terminal onto the Desktop or into other Applications https://bugs.launchpad.net/bugs/124251 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 124251] Re: Ability to drag files out of the Terminal onto the Desktop or into other Applications
Thanks for your report. Your idea might get more attention and have the possibility of being implemented if you submit a specification for it. First check whether the idea is already registered [WWW] https://launchpad.net/ubuntu/+specs, and if so, contact the specification's drafter about your ideas. Otherwise, you can start writing a spec yourself. [WWW] https://wiki.ubuntu.com/FeatureSpecifications FWIW, this really isn't within the scope of what a normal terminal application would do. However, I believe there are already some experimental terminals that deal with interesting UI ideas (not sure drag-and-drop are among them). See CUIterm, for instance, at http://linux.pte.hu/~pipas/CUI/ ; I'd bet you'd have somewhat better luck convincing them to add the feature you're talking about Note that, in order to do the sort of thing you're talking about, you generally would need to both change the terminal, and use a customized shell for that terminal. Also, for future reference, the bug tracker's not really the appropriate place to submit feature requests, except for very trivial ones: it's for actual bugs only in general. Otherwise, feature requests are really what https://launchpad.net/ubuntu/+specs is for. Good luck! ** Changed in: gnome-terminal (Ubuntu) Status: New = Invalid -- Ability to drag files out of the Terminal onto the Desktop or into other Applications https://bugs.launchpad.net/bugs/124251 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 123306] Re: gnome-terminal and others crash due to g_thread_init() not being called
** Changed in: gnome-terminal (Ubuntu) Status: New = Confirmed -- gnome-terminal and others crash due to g_thread_init() not being called https://bugs.launchpad.net/bugs/123306 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 116351] Re: terminal window fork bomb
Gerald, note that X-ing out of a terminal because of some program may not be the best way to deal with that: if the program is ignoring SIGINT (the ^C signal), it could be ignoring SIGHUP (the lost terminal signal) as well; better to open another terminal, find the offending process's pid, and use an unignorable signal like SIGKILL. -- terminal window fork bomb https://bugs.launchpad.net/bugs/116351 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 122601] Re: UI should allow easier access to editing title of terminal
** Changed in: gnome-terminal (Ubuntu) Importance: Undecided = Wishlist -- UI should allow easier access to editing title of terminal https://bugs.launchpad.net/bugs/122601 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121161] Re: scim-chewing will crash GNOME terminal.
Running under QEMU, I confirmed the bug in Feisty, and then after upgrading to Gutsy, confirmed that it appears to be working correctly. -- scim-chewing will crash GNOME terminal. https://bugs.launchpad.net/bugs/121161 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
Wasn't fighting for whose fault it was; was fighting whether it was a really bug, and whether infocmp's output really was meant to describe modified function keys. Now that that's been established, I think the change should be relatively straightforward; assuming xterm has changed its behavior _intentionally_, the terminfo database needs to change. Assuming gnome-terminal has changed compatibly, that should be all. If gnome-terminal is currently behaving differently from xterm, then gnome- terminal would need to stop claiming to be xterm ^_^ As I mentioned, gnome-terminal _has_ changed incompatibly wrt to xterm, in its handling of modified cursor keys and the like. AFAICT, this was an unintentional change, however, and so the fix needs to be made in gnome-terminal. And that's a separate bug. A brief discussion with upstream would be good, to verify that the terminfo needs to change. Because, if the change was intentional, it seems like they should have updated the terminfo in the X source as well; but the link Alex gave shows a terminfo with still-broken control sequences. -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121739] Re: terminal wont accept typed input when prompting for password
Note that commands that take passwords typically turn of local echo, meaning your typing is in fact read as input, but you don't see it on the screen. This is to protect you from people being able to see your password by peering over your shoulder. Please verify that su really isn't taking your input. Are you just su-ing to root? If so, did you set up a password for root? Since sudo is the recommended method for obtaining root privileges, Ubuntu installations do not set up a root password by default. This is because sudo prompts for the calling user's password, rather than the user being su'd to (and then checks that the calling user has appropriate access, as defined by /etc/sudoers). The su command, on the other hand, asks for the destination user's password, so if you have not set a password for root (via sudo passwd root, for example), a su to root would be guaranteed to fail. -- terminal wont accept typed input when prompting for password https://bugs.launchpad.net/bugs/121739 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
Alex, Izzy, I'm not sure where you get the idea that xterm should generate those sequences. infocmp gives \EO5P for function key 25, not for control-function key 1. Infocmp does not and has never had a mechanism for specifying modifiers to special keys. It looks to me that MC is in the wrong. I'll say it again, there is no mechanism for ncurses to handle special keys with modifiers; it's an xterm extension that various terminals emulate. It is thus impossible for xterm's infocmp database to lie about them. -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 58715] Re: Resume from hibernation shouldn't ask for my password with automatic login
** Changed in: gnome-screensaver (Ubuntu) Sourcepackagename: None = gnome-screensaver Status: New = Confirmed -- Resume from hibernation shouldn't ask for my password with automatic login https://bugs.launchpad.net/bugs/58715 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-screensaver in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 59840] Re: soundfonts (*.sf2) get wrong MIME Type video/x-msvideo
In Feisty, an empty file test.sf2 is detected as a plaintext file. However, it's possible that soundfonts are detected through magic rather than extensions. Could you please attach the output of hd test.sf2 | head, where test.sf2 is your soundfont file? ** Changed in: shared-mime-info (Ubuntu) Sourcepackagename: None = shared-mime-info Importance: Undecided = Wishlist Assignee: (unassigned) = Micah Cowan Status: New = Incomplete -- soundfonts (*.sf2) get wrong MIME Type video/x-msvideo https://bugs.launchpad.net/bugs/59840 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for shared-mime-info in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
Izzy, the second paragraph you wrote is rather uninformative. Many of the characters being generated are being stripped out, using the method you've described. Use cat instead. Note that for many terminals, the sequences generated will depend greatly upon whether the terminal is in keypad transmit mode, which most applications that expect to use special keys will set. The sequences for special keys that are described in the terminfo database _only_ apply to behavior when keypad transmit mode is activated (when available); it does not describe what the sequences should look like when that mode is not in effect. The best way to see what they look like when keypad transmit mode is enabled, is to use the command tput smkx; cat; tput rmkx to test the typing. There is nothing particularly special about F1..F4 compared with F5..., they simply generate different sequences (which are both documented correctly in terminfo). Xterm's behavior for generating control sequences have _not_ changed recently; gnome-terminal's (and xfce4-terminal's) on the other hand, have (and are broken). And, as I've said, there is no mechanism for terminfo to describe control+special key, and thus, no way for xterm to break it. For much, much more info about the problem in gnome-terminal, see bug 89660. -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121630] Re: gnome-terminal crashed with SIGSEGV in strlen()
Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report (the one that was generated automatically from apport is useless). This will greatly help us in tracking down your problem. ** Changed in: gnome-terminal (Ubuntu) Assignee: (unassigned) = Micah Cowan Status: New = Incomplete -- gnome-terminal crashed with SIGSEGV in strlen() https://bugs.launchpad.net/bugs/121630 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121630] Re: gnome-terminal crashed with SIGSEGV in strlen()
Never mind; apport's retrace is useless, the one you originally gave with your bug is great. -- gnome-terminal crashed with SIGSEGV in strlen() https://bugs.launchpad.net/bugs/121630 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121630] Re: gnome-terminal crashed with SIGSEGV in strlen()
#10 0xb77789a6 in IA__g_signal_emit_valist (instance=0x80baaa0, signal_id=8, detail=0, var_args=0xbfd559b0 �Yտ\026) at /build/buildd/glib2.0-2.13.5/gobject/gsignal.c:2209 ... #11 0xb7778d99 in IA__g_signal_emit (instance=0x80baaa0, signal_id=8, detail=0) at /build/buildd/glib2.0-2.13.5/gobject/gsignal.c:2243 var_args = 0xbfd5599c \001 -- gnome-terminal crashed with SIGSEGV in strlen() https://bugs.launchpad.net/bugs/121630 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121630] Re: gnome-terminal crashed with SIGSEGV in strlen()
Is ssh-loop some sort of custom script, and what do the arguments
{build,orion,mountain} signify?
--
gnome-terminal crashed with SIGSEGV in strlen()
https://bugs.launchpad.net/bugs/121630
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
«Micah, since the purpose of terminfo is to recognize what xterm does, it seems to me that suggesting that xterm should follow what terminfo says it does is putting the cart before the horse. terminfo doesn't describe what xterm should do, it (should) describe what xterm *does*.» Xterm does, in fact, do what terminfo says. That was my whole point. There is also, additionally, functionality that xterm does, that is not (and cannot currently be, and has not ever been) described by terminfo. This includes the control-special key stuff. None of MC, vim, nor irssi rely on ncurses to tell them anything about when a function key *plus modifier* has been hit, because, as I've said, ncurses is not capable of telling them this. In the case of vim, at least, vim specifically checks the TERM variable to see if it's an xterm or xterm-clone, and in that case listens for specific control sequences (that are not, and cannot currently be, tracked by terminfo). Again, see bug 89660. Regardless of whether xterm changed relatively recently, which I haven't had a chance to confirm yet; gnome-terminal has definitely changed in a way that breaks with any sequence xterm has used, either past or present. -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
Okay, thanks Alex, that clarifies things quite a lot. I guess Xterm and its sisters have repurposed the kfX strings. It might help for terminfo(5) to clarify this situation (even though it really isn't ncurses' responsibility to do so, since that's not the original meaning of those names; still, it does briefly address XTerm/DEC mouse handling). What I've said up until now actually does apply to the other special keys (such as cursor keys), though, but that's irrelevant to this bug. -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 96676] Re: [feisty] function keys don't work in gnome-terminal
Did any terminal ever actually have 64 function keys, as the existence of kf0-kf63 suggests? I doubt it. And I had been wondering about that. :) Seems to me, though, if terminfo has 'em in there _specifically_ for usages like xterm's, they're without excuse for not saying something about how they tend to be used. :p -- [feisty] function keys don't work in gnome-terminal https://bugs.launchpad.net/bugs/96676 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 57055] Re: Cannot Burn CD/DVD on HL-DT-ST DVD-RW GWA-4082N
** Changed in: nautilus-cd-burner (Ubuntu) Sourcepackagename: None = nautilus-cd-burner Status: Unconfirmed = Confirmed -- Cannot Burn CD/DVD on HL-DT-ST DVD-RW GWA-4082N https://bugs.launchpad.net/bugs/57055 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for nautilus-cd-burner in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 106995] Re: gnome-terminal unconditionally interprets mouse wheel events
Please specify the versions of the libvte-common and gnome-terminal packages installed on your system. What exactly do you mean by history scrolling? Do you mean that it scrolls through bash's command line history? gnome-terminal should never send _any_ escape codes for mouse actions, unless it has specifically been asked to. Something has asked it to. Do you only encounter this action after running certain programs, or do you have a customized .bashrc? Please move any .bashrc you have, to a temporary location (where bash won't read it by default, and open a new gnome-terminal. Does this behavior still occur? (Áron, I hope you don't mind if I assign this one to myself, again.) -- gnome-terminal unconditionally interprets mouse wheel events https://bugs.launchpad.net/bugs/106995 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121173] Re: Last line disappears when switching tab
Quite probably, this bug is related to bug 120046 (of which I marked this as a duplicate, and then changed my mind, as the described problems may be sufficiently different). -- Last line disappears when switching tab https://bugs.launchpad.net/bugs/121173 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 120046] Re: gnome-terminal mouse scroll error when using tabs
A similar bug, bug 121173, is claimed to be fixed in the very latest update to libvte in Gutsy. Áron couldn't produce this anyway in Gutsy, but if it was still present but required specific environments to reproduce, it _may_ have been resolved by that same fix... -- gnome-terminal mouse scroll error when using tabs https://bugs.launchpad.net/bugs/120046 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 120046] Re: gnome-terminal mouse scroll error when using tabs
Is that with the brand-new libvte that was released for Gutsy yesterday? -- gnome-terminal mouse scroll error when using tabs https://bugs.launchpad.net/bugs/120046 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 57885] Re: Reboot/Shutdown hangs after connecting to a shared folder
** Changed in: nautilus (Ubuntu) Sourcepackagename: None = nautilus -- Reboot/Shutdown hangs after connecting to a shared folder https://bugs.launchpad.net/bugs/57885 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121161] Re: scim-chewing will crash GNOME terminal.
Here is valgrind output (xfce4-terminal did not crash for this run, but valgrind seems to have found plenty to complain about). The test was to type the text, echo 今日は、田中さん (Hello, Mr Tanaka), twice, then exit via Ctrl+D. ** Changed in: vte (Ubuntu) Sourcepackagename: gnome-terminal = vte Status: Unconfirmed = Confirmed ** Attachment added: valgrind.log.19308 http://launchpadlibrarian.net/8139419/valgrind.log.19308 -- scim-chewing will crash GNOME terminal. https://bugs.launchpad.net/bugs/121161 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121161] Re: scim-chewing will crash GNOME terminal.
I have noticed the same problem with scim-anthy (for Japanese input), as well. This used to work, but when I don't remember. I don't see any recent package updates to either gnome-terminal, libvte-common or scim. I don't seem to be able to reliably reproduce it, however, it appears at this time that the Japanese comma can tend to invoke the problem. Backspacing and retyping may also help, perhaps. At some random points, the currently-input text becomes an opaque white box (none of the text visible), and then later is visible again (after more typing). This is true of xfce4-terminal as well, which also crashes. When running xfce4-terminal within gnome-terminal, I managed to get a *** glibc detected *** xfce4-terminal: munmap_chunk(): invalid pointer: 0x08439c40 ***, followed by a backtrace that was not very informative (possibly because I don't have the debug symbols). After installing the debug symbols (for it and libvte), I was unable to reproduce that same crash. I also got *** glibc detected *** xfce4-terminal: corrupted double-linked list: 0x0823aa20 *** without a backtrace. I also get random messages like (xfce4-terminal:18241): Vte-WARNING **: Can not find appropiate font for character U+823a2c0. or ...for character U+0019 (the former could never be a valid Unicode character, the latter is Ctrl+Y). I'm reassigning to vte, since the same problem is in xfce4-terminal. -- scim-chewing will crash GNOME terminal. https://bugs.launchpad.net/bugs/121161 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121173] Re: Last line disappears when switching tab
** This bug has been marked a duplicate of bug 120046 gnome-terminal mouse scroll error when using tabs ** This bug is no longer a duplicate of bug 120046 gnome-terminal mouse scroll error when using tabs -- Last line disappears when switching tab https://bugs.launchpad.net/bugs/121173 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 121161] Re: scim-chewing will crash GNOME terminal.
BTW, I checked to see if the U+823a2c0 could have been some strange combination of actual Unicode characters involved in the text I typed; this does not appear to be the case. -- scim-chewing will crash GNOME terminal. https://bugs.launchpad.net/bugs/121161 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 120858] Re: Graphical corruption in gnome-terminal
Probably, it's at least an interaction between gnome-terminal and your X driver; where the bug lies is hard to say. I'm adding xserver-xorg- video-ati so that between the two, perhaps we can find the bug in one or both. Perhaps its a duplicate of bug 34435, though AFAICT the symptoms are different from that bug and its duplicates. However, it mentions problems with the XRENDER extension, used via Cairo in most apps, which gnome-terminal also uses. Are you able to reproduce this problem in xfce4-terminal (which shares the same library code for the terminal emulation widget as gnome- terminal)? ** Also affects: xserver-xorg-video-ati (Ubuntu) Importance: Undecided Status: Unconfirmed -- Graphical corruption in gnome-terminal https://bugs.launchpad.net/bugs/120858 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 48880] Re: Control-s should do forward-search-history
Ctrl-S controls the flow... by pausing all output on the terminal (Ctrl-Q is used to resume output). The output of the stty commands given above actually are not entirely accurate, because bash changes the state of the tty just before, and after, running a command. If you were to run stty against the tty while bash is still reading input via libreadline, you'd see some different results: at a minimum, -icanon instead of icanon. However, it's possible that readline should also be setting -ixon -ixoff (I'd have to look up if it's really supposed to do this), in which case the settings of stop and start should be ignored, and passed through to bash. You can check the terminal settings when bash is still listening for input instead of running a command (such as stty itself), by obtaining the name of the pseudo-terminal file that bash is running on with the tty command, and then running stty against it from a _different_ terminal/shell: stty -a /dev/pts/whatever-the-terminal-is. The fact that Ctrl-S followed by cursor down results in gnome- terminal eating the initial ESC of ESC [ B, and then inserts the rest of that sequence, even when stty has ^S assigned for stop, is clearly a bug. However, it may be a separate bug from whether or not readline is setting the terminal properly. If it turns out there are two separate issues, we will need to split this bug report into two. -- Control-s should do forward-search-history https://bugs.launchpad.net/bugs/48880 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 89660] Re: cursor control regression in vim
It seems extremely likely to me that this is a bug with vte, rather than vim, so I'm reassigning. vim is expecting the same sequences it has always expected from xterm and xterm-emulating ttys. xterm normally sends ESC [ A for cursor up; when keypad send mode is on (vim activates this mode), it sends ESC O A instead. Regardless of mode, control-cursor-up is represented as ESC [ 1 ; 5 A. gnome-terminal and xfce4-terminal (both of which use vte to handle terminal emulation), are currently sending erroneous codes for control- cursor-up (and others) when keypad send mode is on: ESC O 1 ; 5 A (which is not a valid sequence). vim doesn't recognize it, and interprets it directly, which means it is interpreted as end input mode; open a new line above current position; start inserting 1;5A Compare the following commands; after each command I am typing as input, a line consisting of updownrightleft, followed by a line of the same keys with the control key held down, followed by Control-D (to terminate input to cat). Here's how it looks in xterm: schmendrick$ cat /dev/null ^[[A^[[B^[[C^[[D ^[[1;5A^[[1;5C^[[1;5B^[[1;5D schmendrick$ tput smkx; cat /dev/null; tput rmkx ^[OA^[OB^[OC^[OD ^[[1;5A^[[1;5B^[[1;5C^[[1;5D The tput smkx command places the terminal into keypad send mode; the second tput command resets that mode. Note that while the normal cursor keys emit different sequences in the two different modes, the control- cursor-keys emit exactly the same sequences. Here's the same thing as it looks in gnome-terminal and xfce4-terminal: schmendrick$ cat /dev/null ^[[A^[[B^[[C^[[D ^[[1;5A^[[1;5B^[[1;5C^[[1;5D schmendrick$ tput smkx; cat /dev/null; tput rmkx ^[OA^[OB^[OC^[OD ^[O1;5A^[O1;5B^[O1;5C^[O1;5D Note that for both the normal cursor keys and the control-cursor-key combos, the [ character in the sequence is replaced with an O. This is more consistent, but it breaks with previous behavior, and xterm's behavior, and there is no way for vim to understand how to process these sequences (other than as literal vim commands, which is what you've seen). ** Changed in: vte (Ubuntu) Sourcepackagename: vim = vte ** Changed in: vte (Fedora) Sourcepackagename: vim = vte ** Summary changed: - cursor control regression in vim + control-cursor-key regression in vim -- control-cursor-key regression in vim https://bugs.launchpad.net/bugs/89660 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for vte in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 120046] Re: gnome-terminal mouse scroll error when using tabs
I can't reproduce this. Any further hints to help reproduce this? -- gnome-terminal mouse scroll error when using tabs https://bugs.launchpad.net/bugs/120046 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-terminal in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 576] Re: Missing charsets in String to Fontset conversion - confirm kill
*** This bug is a duplicate of bug 2066 *** https://bugs.launchpad.net/bugs/2066 ** This bug has been marked a duplicate of bug 2066 Unable to load any usable fontset -- Missing charsets in String to Fontset conversion - confirm kill https://bugs.launchpad.net/bugs/576 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee (via bug 2066). -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 108833] Re: Vim GUI writes warnings to terminal
It's not vim that emits these errors, it must be some library it's using. There may be something missing from your desktop environment. Are you running under a gnome session, or do you use Xubuntu? I couldn't find the string device event controller in the Gtk+ sources, but I'm forwarding this to the gtk guys anyway, as I suspect they'll have a better understanding where to forward you. ** Changed in: gtk+2.0 (Ubuntu) Sourcepackagename: vim = gtk+2.0 -- Vim GUI writes warnings to terminal https://bugs.launchpad.net/bugs/108833 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 102002] Re: GTK assertion `g_path_is_absolute (filename)' failed
** Changed in: gtk+2.0 (Ubuntu) Sourcepackagename: vim = gtk+2.0 -- GTK assertion `g_path_is_absolute (filename)' failed https://bugs.launchpad.net/bugs/102002 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 59400] Re: Screen saver running in sessions that are not in control of monitor
Confirming for the screensaver, as while Ken is right that it's not a bug with the screensaver when considering its original intended use, it is a bug with the screensaver in consideration of the use for which we have chosen it. It may not be Gnome's responsibility to fix, but it is ours, and the fix (or at least some part of it) would likely be implemented in gnome-screensaver. ** Changed in: gnome-screensaver (Ubuntu) Importance: Undecided = Low Status: Unconfirmed = Confirmed -- Screen saver running in sessions that are not in control of monitor https://bugs.launchpad.net/bugs/59400 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-screensaver in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 113694] Re: [apport] gnome-session crashed with SIGSEGV
** Tags added: needs-i386-retrace -- [apport] gnome-session crashed with SIGSEGV https://bugs.launchpad.net/bugs/113694 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-session in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 113445] Re: xxxxx
Hello, and thank you for submitting this bug report. However, you have provided no information at all about what the problem is that you are experiencing. You include a link, but it is a file:// link, and so requires that the person viewing it already have a copy of the program. To attach a copy of the crash, please use the Browse... button in the include an attachment section of the comment. Also, please give a description of what you were doing, what you expected to happen, and what actually happened. Also, please use Edit description/tags to change the bug's title to something actually descriptive of the problem. Is this truly a problem with gedit, or with compiz? The name of your file:// link would seem to indicate the latter, but this bug has been filed against the former. Thank you for helping us to track down this bug! ** Changed in: gedit (Ubuntu) Assignee: (unassigned) = Micah Cowan Status: Unconfirmed = Needs Info -- x https://bugs.launchpad.net/bugs/113445 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gedit in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 105390] Re: window manager crashes/does not work
But, surely there must have been /something/ in the configuration that caused metacity not to work, since blowing it away got it working again? -- window manager crashes/does not work https://bugs.launchpad.net/bugs/105390 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 105390] Re: window manager crashes/does not work
Actually, just to be sure we know what the problem was, rather than close the bug out yet, if you still have the old, moved-out-of-the-way .gnome2/ directory around, could you maybe tar it up and attach it? «tar xjf gnome2.tbz moved-gnome2/» should do. -- window manager crashes/does not work https://bugs.launchpad.net/bugs/105390 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list [EMAIL PROTECTED] https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 105390] Re: window manager crashes/does not work
Just so you know, shirish, the DISPLAY=:0 is a guess, and is only likely to work if that user is the first one to have logged into a graphical desktop. You can get the actual value by looking at your current .xsession-errors, the line that says: /etc/gdm/PreSession/Default: running: /usr/X11R6/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x /var/lib/gdm/:0.Xservers -h -l :0 shirish If it says something other than :0 there, use that instead. The fact that you have a test user working fine, strongly suggests that something is wrong with your configuration. I know seb128 had you move your .gnome2/session out of the way, and you were still having problems... you might try moving your whole .gnome2 out of the way (which will remove your configuration in many programs). If that doesn't work, you might need to move your important things away, destroy the shirish user, and recreate a new account for shirish (since the test account was working). -- window manager crashes/does not work https://bugs.launchpad.net/bugs/105390 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 105390] Re: window manager crashes/does not work
shirishag75 wrote: ok would try that, just to inform the number of things which were tried so everybody knows. actually the command which u gave in the morning DISPLAY=:0 metacity --replace use to give a warning shirish @ubuntu $ Window Manager manager warning found in configuration database is not a valid value for keybinding toggle_shaded That doesn't look like a serious problem. which escalated to the afternoon to :- shirish @ubuntu $ Window Manager manager warning found in configuration database is not a valid value for keybinding toggle_shaded Window Manager error= Unable to open X display 0 That looks like you forgot the colon again :) shirish @ubuntu $ Window Manager manager warning found in configuration database is not a valid value for keybinding toggle_shaded xlib: connection to 0.0 refused by server xlib: No protocol specified This probably means :0 isn't owned by you (perhaps the test user was running that session?); that's why I talked about checking the value in ~/.xsession-errors. Further things tried by seb128 :- gconftool --2 --get /desktop/gnome/application window_manager/default ? /usr/bin/metacity failed to get a value for '?' Bad key or directory name '? Must begin with a slash (/) That's because he hadn't actually meant the ? to be typed. Otherwise, it worked fine. (And, he just wanted to get the /usr/bin/metacity value: he wasn't expecting it to fix anything.) was asked if there was any .dmrc directory in /home/username which was replied in negative was asked to move the file ~/.gnome2/session which had no effect then tried sudo apt-get install --reinstall metacity_common which again did not result into anything better The only solution which works in the meanwhile is typing 'metacity' without the quotes in terminal brings all window decorations etc. What this essentially means is that running metacity by hand fixes things, but for some reason metacity is either not running by default in your gnome session, or is crashing for some strange reason. moving ~/.gnome2/session seems like it should have fixed it; but ~/.gnome2 definitely ought to: it's just a bit draconian (though not as much so as blowing away the user's home directory), since any customizations to gnome apps that you've done will have to be redone. Thanks for the run-down, shirish! -- window manager crashes/does not work https://bugs.launchpad.net/bugs/105390 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 59400] Re: Screen saver running in sessions that are not in control of monitor
Hm. I believe this is so that when the second user's session ends, the first user, when his X session is made the current one, will be required to log in. I agree that it would be beneficial to prevent the screensaver from actually using up CPU unless it's the currently visible one, but I think the fix for this is likely to be far from trivial. -- Screen saver running in sessions that are not in control of monitor https://bugs.launchpad.net/bugs/59400 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-screensaver in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 103144] Re: scripts running from desktop : $PWD = /home/user
Yeah, okay: you're right, that seems wrong. Confirmed for Feisty Edgy. -- scripts running from desktop : $PWD = /home/user https://bugs.launchpad.net/bugs/103144 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 56976] Re: Printer Properties Dialog is too slow to show up
Confirmed for Feisty Fawn. I believe opening that dialog also queries the printer, which may be part of the problem; but in any case, it should bring the window up immediately, and then perhaps display some helpful querying the printer progress bar or what have you, so that the user is provided with a less jarring experience (did my computer just freeze up?) ** Changed in: gnome-cups-manager (Ubuntu) Status: Unconfirmed = Confirmed -- Printer Properties Dialog is too slow to show up https://bugs.launchpad.net/bugs/56976 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for gnome-cups-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 103144] Re: scripts running from desktop : $PWD = /home/user
Hi, and thanks for taking the time to submit this bug report. I've confirmed that this does occur; however, I do not believe it's a bug. It should probably be prioritized as Wishlist. I'm guessing this is not how upstream will want to go, but I'll let someone else make that decision. The PWD is probably whatever it was when the session was started (gdm will typically change to the home dir before beginning a session). Just because you executed it from a certain location doesn't mean that should be the current working directory. Executing a script from a desktop is analagous to invoking ~/Desktop/test, not cd ~/Desktop; ./test. ** Changed in: nautilus (Ubuntu) Sourcepackagename: None = nautilus Status: Unconfirmed = Confirmed -- scripts running from desktop : $PWD = /home/user https://bugs.launchpad.net/bugs/103144 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62398] Re: [Edgy] gnome-games doesn't have proper license info
** Changed in: gnome-games (Ubuntu) Status: Unconfirmed = Confirmed -- [Edgy] gnome-games doesn't have proper license info https://launchpad.net/bugs/62398 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 58083] Re: No keyboard previews
** Also affects: xorg (Ubuntu) Importance: Untriaged Status: Unconfirmed -- No keyboard previews https://launchpad.net/bugs/58083 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 61503] Re: Dapper: Nautilus crashes when deleting a folder from the side-pane
I can't reproduce this problem. I was able to move two folders into the wastebasket by right-clicking in the Tree view. Please provide a more detailed explanation of exactly what you tried (exact filenames, what the current directory is, what the path buttons list at the top was). ** Changed in: nautilus (Ubuntu) Status: Unconfirmed = Needs Info -- Dapper: Nautilus crashes when deleting a folder from the side-pane https://launchpad.net/bugs/61503 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 61503] Re: Dapper: Nautilus crashes when deleting a folder from the side-pane
I tested using version 2.14.3-0ubuntu1 -- Dapper: Nautilus crashes when deleting a folder from the side-pane https://launchpad.net/bugs/61503 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 61158] Re: edgy: translation error in dutch
** Changed in: Ubuntu Sourcepackagename: None = gnome-panel -- edgy: translation error in dutch https://launchpad.net/bugs/61158 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 61157] Re: separated spelt incorrectly in usage string
** Changed in: gaim (Ubuntu) Status: Unconfirmed = Confirmed -- separated spelt incorrectly in usage string https://launchpad.net/bugs/61157 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 61161] Re: Evince takes a long time to render pages in PDF documents
Hear, hear. This is a major reason why I use xpdf. ** Changed in: evince (Ubuntu) Status: Unconfirmed = Confirmed -- Evince takes a long time to render pages in PDF documents https://launchpad.net/bugs/61161 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 57160] Re: Can't lock desktop.
Assigning to gnome-screensaver, although it could be a session manager thing. ** Changed in: Ubuntu Sourcepackagename: None = gnome-screensaver -- Can't lock desktop. https://launchpad.net/bugs/57160 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 55988] clock-panel no longer installs NTP support
Public bug reported: When NTP support is not installed, checking Synchronize clock... gives the message about needing to install NTP support, but does not offer to do so, nor give instructions as to the appropriate packages to install. This in edgy (2.15.91-0ubuntu2) ** Affects: gnome-system-tools (Ubuntu) Importance: Untriaged Assignee: Ubuntu Desktop Bugs Status: Fix Released -- clock-panel no longer installs NTP support https://launchpad.net/bugs/55988 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
