Bug#281057: ...
Hi Ian, I can't remember what I did when I updated the patch, but a simple text merging sounds more probable than performing all the tests again. Please note that I no longer work for the company where we maintained a dpkg-based Linux distro and kept on sending bugreports or patches to mainstream developers. This means that the e-mail address I posted my earlier comments from is no longer active, this also means that I no longer have the infrastructure to play with dpkg, and actually I no longer care about it. I was here to help you for nearly three years, unfortunately you didn't take the opportunity, now it's gone. I wish you good luck in judging my patch, keeping relevant parts, throwing out irrelevant segments, or do your best to just simply fix this bug. I'm sorry but I can't provide any new info. bye, Egmont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281057: PING!!!
## ####### ## ##
## ## ## ### ## ## ## ## ## ##
## ## ## ## ## ## ## ## ##
## ## ## ## #### ## ## ## ##
## ## ## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ##
## ## #### ## ## ## ## ## ##
## ## ## ## ##
## ## ## ### ## ## ## ## ##
## ## ####### ## ##
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404503: typo
An obvious temporary workaround is __not__ using an __8-bit__ locale... This is a quite serious typo that inverts the sense of the sentence... By the way, I don't agree that this is a good workaround, as it leads to different system setup, filenames or text file contents being encoded in different charset etc... so you'll get completely different result. A good workaround is to use other input methods, e.g. a good terminal emulator under X, or Alt+Number from numpad, or loading a keymap that contains the desired accented letters without dead keys... -- Egmont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281057: Ping!
Ping! ... It was 2 years ago that I posted this bugreport, including: - detailed description of what to do for the bug to occur, - detailed explanation where and why the source is buggy, - patch to fix the problem. Just a note I haven't mentioned before: this patch has already survived 2 years of intensive testing, since we're using dpkg with this patch to build up and upgrade chroot systems where all the packages of a Linux distribution are being built, and the packages that form these chroot jails are continuously updated to newer or fixed versions. My estimate is that we've upgraded the chroot using dpkg with this patch approximately 50.000 times in these 2 years -- successfully, as opposed to the times when we used an unpatched dpkg and had serious OOM troubles when upgrading e.g. kernel-headers inside the chroot after a kernel version bump. During these 2 years no valuable comments arrived from any Debian/Dpkg developers. I wonder why... Isn't there anyone caring about this bug? (Is there anyone caring about Dpkg at all?) Or you simply lack developer resources? (Well, that could be an excuse for an unreproducible bug report or a bug report without a patch, but I feel I've done everything anyone could have done to locate and fix this bug; all you have to do is verify it and then apply the patch.) Or what else is happening behind the scenes? If you check the bug archives of Debian, you'll see that I already posted several bug reports and patches (well, not very much, maybe a dozen) and some of them were successfully applied, making Debian a slightly better distro. Unfortunately this is not my first bugreport where I have to wait years for anyone to move his fingers. If you continue developing with this approach, all you'll reach is that I'm going to fix these bugs for myself and not send any feedback at all. It's not worth it for me to spend my time explaining the story if noone's listening to me. Is this what you want? I hope not... -- Egmont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281057: patch updated
Hi,
I send these two patches updated to the newest dpkg (namely 1.13.22).
Is there any chance that they'll be reviewed and probably committed by
someone around there?
--
Egmont
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281057
diff -Naur dpkg-1.13.22.orig/src/processarc.c dpkg-1.13.22/src/processarc.c
--- dpkg-1.13.22.orig/src/processarc.c 2006-05-31 04:46:30.0 +0200
+++ dpkg-1.13.22/src/processarc.c 2006-06-29 17:22:39.0 +0200
@@ -646,15 +646,17 @@
upgrade/downgrade, fnamevb.buf);
for (cfile= newfileslist; cfile; cfile= cfile-next) {
+struct stat st_tmp;
if (!cfile-namenode-filestat) {
- cfile-namenode-filestat= nfmalloc(sizeof(struct stat));
- if (lstat(cfile-namenode-name, cfile-namenode-filestat)) {
+ if (lstat(cfile-namenode-name, st_tmp)) {
if (!(errno == ENOENT || errno == ELOOP || errno == ENOTDIR))
ohshite(_(unable to stat other new file `%.250s'),
cfile-namenode-name);
- memset(cfile-namenode-filestat, 0,
- sizeof(cfile-namenode-filestat));
+ cfile-namenode-filestat= 0;
continue;
+ } else {
+ cfile-namenode-filestat= nfmalloc(sizeof(struct stat));
+ memcpy(cfile-namenode-filestat, st_tmp, sizeof(struct stat));
}
}
if (!cfile-namenode-filestat-st_mode) continue;
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281057
diff -Naur dpkg-1.13.22.orig/src/processarc.c dpkg-1.13.22/src/processarc.c
--- dpkg-1.13.22.orig/src/processarc.c 2006-06-29 17:24:20.0 +0200
+++ dpkg-1.13.22/src/processarc.c 2006-06-29 17:26:00.0 +0200
@@ -60,7 +60,7 @@
static char *cidirbuf=0, *reasmbuf=0;
static struct fileinlist *newconffiles, *newfileslist;
static enum pkgstatus oldversionstatus;
- static struct varbuf infofnvb, fnvb, depprobwhy;
+ static struct varbuf infofnvb, fnvb, cfnvb, depprobwhy;
static struct tarcontext tc;
int c1, r, admindirlen, i, infodirlen, infodirbaseused, status;
@@ -648,7 +648,12 @@
for (cfile= newfileslist; cfile; cfile= cfile-next) {
struct stat st_tmp;
if (!cfile-namenode-filestat) {
- if (lstat(cfile-namenode-name, st_tmp)) {
+ varbufreset(cfnvb);
+ varbufaddstr(cfnvb,instdir);
+ varbufaddc(cfnvb,'/');
+ varbufaddstr(cfnvb,cfile-namenode-name);
+ varbufaddc(cfnvb,0);
+ if (lstat(cfnvb.buf, st_tmp)) {
if (!(errno == ENOENT || errno == ELOOP || errno == ENOTDIR))
ohshite(_(unable to stat other new file `%.250s'),
cfile-namenode-name);
Bug#378983: make dpkg -S work with a trailing slash
Package: dpkg Version: 1.13.22 Severity: wishlist Currently if the argument of dpkg -S ends with a slash, no match is found. E.g. dpkg -S /usr/include - lots of packages found dpkg -S /usr/include/ - no output Since the TAB completion feature of most shells (including the default bash) puts a slash at the end of the directory name, it's usually much easier to type the directory's name with a slash at the end than without it. Please modify dpkg -S so that it finds matching directories in this case too. Thanks, Egmont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#734571: mc: [copy] paste adds extra characters
A fix for VTE is available at https://bugzilla.gnome.org/show_bug.cgi?id=729533 -- it used to handle bracketed paste mode differently than other terminals. I might create a patch for MC too (after all, it should work with current VTE), but after a first glimpse it doesn't look trivial. egmont
Bug#747347: Update or drop obsolete 60_termcap-home-end.patch
Package: vte3 Version: 1:0.36.0-2 VTE 0.36 changed the control sequences generated for Home and End. They used to be \eOH and \eOF, now they are the xterm-compatible \e[H and \e[F. (Due to an unfortunate bug, they are \e[1~ and \e[4~ for the keypad, this is already fixed in git. Forget these sequences, \e[H and \e[F are the correct ones.) With this change in mind, 60_termcap-home-end.patch no longer makes sense. The patch should be updated or dropped. (I can't tell where that termcap file is being used, if at all.) Upstream reference: https://bugzilla.gnome.org/show_bug.cgi?id=600659 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734571: mc: [copy] paste adds extra characters
Mainstream vte-0.36.2 release fixes the bug. On Tue, May 6, 2014 at 3:50 PM, Egmont Koblinger egm...@gmail.com wrote: A fix for VTE is available at https://bugzilla.gnome.org/show_bug.cgi?id=729533 -- it used to handle bracketed paste mode differently than other terminals. I might create a patch for MC too (after all, it should work with current VTE), but after a first glimpse it doesn't look trivial. egmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726919: gnome-terminal: cursor blinking in inactive window
The mainstream bugreport is https://bugzilla.gnome.org/show_bug.cgi?id=677329 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746415: gnome-terminal: will not start with non-utf-8 locale
Upstreamed: https://bugzilla.gnome.org/show_bug.cgi?id=732127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719553: gnome-terminal's --working-directory option does not accept paths that use ~ as reference to the home directory
You can use a space instead of '=', i.e.: gnome-terminal --working-directory ~/Storage It'll work as you'd expect. It's a feature of the *shell* that it looks up the home directory if the '~' is the first character of a word. If you use '=' as separator then '~' is not the first character and hence the shell doesn't expand it. The '~' itself, when literally part of a filename, does not refer to a home directory and should remain a literal '~'. It's only the shell (and a few more apps that deliberately choose to mimic the shell's behavior) that treats '~' specially. So, gnome-terminal works as expected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719553: gnome-terminal's --working-directory option does not accept paths that use ~ as reference to the home directory
See also: http://lists.gnu.org/archive/html/bug-bash/2007-12/msg3.html On Thu, Jun 26, 2014 at 11:45 AM, Egmont Koblinger egm...@gmail.com wrote: You can use a space instead of '=', i.e.: gnome-terminal --working-directory ~/Storage It'll work as you'd expect. It's a feature of the *shell* that it looks up the home directory if the '~' is the first character of a word. If you use '=' as separator then '~' is not the first character and hence the shell doesn't expand it. The '~' itself, when literally part of a filename, does not refer to a home directory and should remain a literal '~'. It's only the shell (and a few more apps that deliberately choose to mimic the shell's behavior) that treats '~' specially. So, gnome-terminal works as expected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503280: gnome-terminal: SIGWINCHes when switching tabs
I've reported this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=731137 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649579: gnome-terminal: sends unnecessary SIGWINCHes
I've reported this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=731137 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749448: gnome-terminal: Alt+number doesn't work in applications anymore
Please see https://bugzilla.gnome.org/show_bug.cgi?id=730128 for official upstream response. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525507: gnome-terminal shifts the last line to the right if it's updated twice in a row.
Unfortunately this is not yet fixed upstream. I've forwarded upstream at https://bugzilla.gnome.org/show_bug.cgi?id=731155 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634179: Printing bold characters changes the colour of the following
Hi Nicolas, What is this application you're running? Could you please run it under script and attach the resulted typescript file? thx, egmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736342: gnome-terminal: regularly stops using X input method
Hi Tollef, I've filed the bug upstream here: https://bugzilla.gnome.org/show_bug.cgi?id=731230 I'll be happy to work on fixing this. If you have a reproducible test case that'd help a lot! thanks, egmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679810: gnome-terminal: segmentation fault in libgobject
I suspect it's the same as the recently-fixed https://bugzilla.gnome.org/show_bug.cgi?id=730389 https://git.gnome.org/browse/gnome-terminal/commit/?id=f65261a Could you maybe try to backport that patch to your gnome-terminal? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729324: gnome-terminal: Background options are no available longer
Transparency was indeed removed from official gnome-terminal. A patch to bring it back is available at https://code.launchpad.net/~larsu/gnome-terminal/update-restore-transparency-patch (This an improved version over the original patch from http://debarshiray.wordpress.com/2014/05/15/transparent-terminals-back-in-fedora/ ). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525507: gnome-terminal shifts the last line to the right if it's updated twice in a row.
Fixed upstream, will appear in vte-0.38 (gnome-terminal-3.14). On Tue, Jun 3, 2014 at 12:57 PM, Egmont Koblinger egm...@gmail.com wrote: Unfortunately this is not yet fixed upstream. I've forwarded upstream at https://bugzilla.gnome.org/show_bug.cgi?id=731155 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706126: mc: Internal viewer fails to display UTF-8 man pages
Mainstream bugreport is at http://www.midnight-commander.org/ticket/1539 mc-4.8.13 will hopefully fix this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761671:
This is probably the same as https://bugzilla.gnome.org/show_bug.cgi?id=730763. Could you please verify if you experience the same symptoms as there (e.g. focus out repaints the screen; the timestamp printed by a date reveals that it's executed as soon as you hit Enter, even though the display is not yet updated...)? I haven't faced this bug for a while now. I suspect it's a problem with some underlying component (X, Gtk?) that's probably been fixed in the meantime. (Just for the record: I am using the latest Ubuntu.)
Bug#765877: gnome-terminal decreases size when mouse over close tab button
I'd argue that this is a bug in your Gnome theme. The close button shouldn't change its size on hover. If it does, weird things are bound to happen, and I'm not sure if gnome-terminal could (and really don't think it should) try to do anything to prevent this.
Bug#763383: Add transparency option to gnome-terminal
Zerothly, there is no need for a patch; gnome-terminal supports transparency just fine. It's not the same. With the given patch, you get a translucent background, but all other colors remain opaque. With a WM/compositing approach even the foreground colors, non-default background colors, and the UI chrome (menubar, tabs, WM title bar) become transparent. It's really not the same user experience. Especially with the foreground text becoming translucent, the result is in my opinion less usable than with the explicit transparency patch. Firstly, this patch will *never* be accepted upstream Secondly, it relies on an undocumented feature of vte Why not at least document the vte feature and committing to keeping that, for the benefit of other vte-based apps? Thirdly, the actual patch presented here has several defects, chiefly the problem that it always forces an ARGB visual even when no transparency is in use. This may negatively impact performance and memory use. Someone somewhere (can't remember who and where, sorry) pointed out that quite a few other apps already always force ARGB without problems. As far as I remember, they pointed out that ARGB used to have problems but it's not the case anymore. Yet, if it's still an issue, the patch should be further improved to handle this. I myself have used g-t with this patch for about half a year now, and F20/Rawhide also ships this. I haven't found any reports yet that are likely connected to transparency. What are the other defects? Fourthly, the patch adds user-visible strings, but does not contain their translation Isn't it one more reason for accepting the feature mainstream (maybe behind a disabled-by-default configure flag)? Translations would appear at almost zero cost. Finally, there are many other terminal emulators that do support transparency (e.g., KDE's konsole); so if they want transparency, the user can simply choose to use one of them instead of gnome-terminal. I have recently put tons of effort in improving gnome-terminal, probably most significantly the rewrap-on-resize feature makes it significantly better for me than most other terminals. I'd hate to tell our users go use another terminal, that's not why I put so much work in it. I'd prefer my work to reach as many users as possible, even those who insist on transparency. as an addendum: While the OP claims that the patch is already more widely used than just its originator (Fedora) I'm not sure about Ubuntu's branches and stuff, but looking at https://code.launchpad.net/~ubuntu-desktop/gnome-terminal/ubuntu and https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging suggests to me that probably the patch is going to be included in Vivid. In conclusion, it is my opinion that Debian should *not* add this patch to its gnome-terminal package. I don't think I have a conclusion here :) I think the best would be if mainstream g-t accepted this feature, I can't see why ChPe is so resistant, but he made it clear that the feature won't become mainstream. I'm not sure if all major distros shipping the patch and pushing for adoption could make him change his mind. Given this situation, Debian should listen to its users, understand the pros/cons of applying this patch and make whatever seems to be the best decision. cheers, egmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763383: Add transparency option to gnome-terminal
Fyi: The transparency patch indeed did appear in Ubuntu Vivid. On Sun, Nov 2, 2014 at 12:48 PM, Egmont Koblinger egm...@gmail.com wrote: Zerothly, there is no need for a patch; gnome-terminal supports transparency just fine. It's not the same. With the given patch, you get a translucent background, but all other colors remain opaque. With a WM/compositing approach even the foreground colors, non-default background colors, and the UI chrome (menubar, tabs, WM title bar) become transparent. It's really not the same user experience. Especially with the foreground text becoming translucent, the result is in my opinion less usable than with the explicit transparency patch. Firstly, this patch will *never* be accepted upstream Secondly, it relies on an undocumented feature of vte Why not at least document the vte feature and committing to keeping that, for the benefit of other vte-based apps? Thirdly, the actual patch presented here has several defects, chiefly the problem that it always forces an ARGB visual even when no transparency is in use. This may negatively impact performance and memory use. Someone somewhere (can't remember who and where, sorry) pointed out that quite a few other apps already always force ARGB without problems. As far as I remember, they pointed out that ARGB used to have problems but it's not the case anymore. Yet, if it's still an issue, the patch should be further improved to handle this. I myself have used g-t with this patch for about half a year now, and F20/Rawhide also ships this. I haven't found any reports yet that are likely connected to transparency. What are the other defects? Fourthly, the patch adds user-visible strings, but does not contain their translation Isn't it one more reason for accepting the feature mainstream (maybe behind a disabled-by-default configure flag)? Translations would appear at almost zero cost. Finally, there are many other terminal emulators that do support transparency (e.g., KDE's konsole); so if they want transparency, the user can simply choose to use one of them instead of gnome-terminal. I have recently put tons of effort in improving gnome-terminal, probably most significantly the rewrap-on-resize feature makes it significantly better for me than most other terminals. I'd hate to tell our users go use another terminal, that's not why I put so much work in it. I'd prefer my work to reach as many users as possible, even those who insist on transparency. as an addendum: While the OP claims that the patch is already more widely used than just its originator (Fedora) I'm not sure about Ubuntu's branches and stuff, but looking at https://code.launchpad.net/~ubuntu-desktop/gnome-terminal/ubuntu and https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging suggests to me that probably the patch is going to be included in Vivid. In conclusion, it is my opinion that Debian should *not* add this patch to its gnome-terminal package. I don't think I have a conclusion here :) I think the best would be if mainstream g-t accepted this feature, I can't see why ChPe is so resistant, but he made it clear that the feature won't become mainstream. I'm not sure if all major distros shipping the patch and pushing for adoption could make him change his mind. Given this situation, Debian should listen to its users, understand the pros/cons of applying this patch and make whatever seems to be the best decision. cheers, egmont
Bug#770596: gnome-terminal: leaves defunct bash processes behind
Hi Jérémy, Thanks for the report, I forwarded it upstream: https://bugzilla.gnome.org/show_bug.cgi?id=740929 Could you please verify that this only occurs to you if you close the tab/window by its X button or a shortcut key, and not when you ask the shell to exit (with Ctrl+D or the exit command or such)? thanks, egmont
Bug#770596: gnome-terminal: leaves defunct bash processes behind
Upstream fix is at https://git.gnome.org/browse/vte/commit/?h=vte-0-38id=d9d83d4 On Sun, Nov 30, 2014 at 6:46 PM, Egmont Koblinger egm...@gmail.com wrote: Hi Jérémy, Thanks for the report, I forwarded it upstream: https://bugzilla.gnome.org/show_bug.cgi?id=740929 Could you please verify that this only occurs to you if you close the tab/window by its X button or a shortcut key, and not when you ask the shell to exit (with Ctrl+D or the exit command or such)? thanks, egmont
Bug#770596: gnome-terminal: leaves defunct bash processes behind
The first upstream fix was incorrect. The correct fix is these two commits on top of each other: https://git.gnome.org/browse/vte/commit/?h=vte-0-38id=d9d83d4 https://git.gnome.org/browse/vte/commit/?h=vte-0-38id=b033047
Bug#770596: gnome-terminal: leaves defunct bash processes behind
FYI: New upstream tarball is released with the fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723944: gnome-terminal: g-t says it is xterm while in fact it is xterm-256color, this severely limits the user experience/comfort
vte-0.39.1 (to be released as stable in Gnome-3.16) changes this to xterm-256color. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681982: gnome-terminal: Cursor does not change when unfocused
This is caused by https://bugzilla.gnome.org/show_bug.cgi?id=677329 , a bug in either Gtk+ or X (unfortunately we don't know). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774600: gnome-terminal: Hangs with full cpu load
I wonder if it's the same as https://bugzilla.gnome.org/show_bug.cgi?id=735101 ... probably it is. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#368916: gnome-terminal: $TERM should be set to gnome instead of xterm
Hi, I've been an active contributor/developer of gnome-terminal in the last 1.5 years. I firmly disagree with Christoph's comment Apparently upstream intentionally breaks things or simply doesn't care. We do care, and we worked hard recently to make gnome-terminal work reasonably close to xterm. Just look at the changelog and count how many emulation fixes we had in the last 1.5 years! Gnome-terminal has set TERM=xterm for a long time, and xterm is our reference as for how the terminal should work. On the other hand, TERM=gnome, which is written and maintained (probably not maintained actively too much) by xterm/terminfo's maintainer, is probably way out of date. Without looking at the details, I'm quite sure that TERM=xterm is way closer to describe gnome-terminal's behavior than TERM=gnome. And even if someone updates and corrects the gnome terminal description, we'd have to wait years until it's deployed to most of the hosts where you'd want to ssh to. Sure it's not perfect, but incorrectly reporting blink support is probably a magnitudes smaller problem than the ones you'd face with TERM=gnome. *If* someone updates TERM=gnome and keeps it updated, changing to that as the default might become a viable option in maybe 5 years or so. Over the last year or two we fixed plenty of _actual_ bugs where the emulation was incorrect. Christoph found the tinyest and most negligible feature that we promise to support but actually don't (i.e. blinking), and riding this he wants to push towards a completely different design which would have way more severe bugs which he can't foresee. With further details/discussions in the mainstream bugreport, I recommend that Debian developers stick to gnome-terminal developers' choice. cheers, egmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663253: gnome-terminal: tab should NOT get focus
Forwarded upstream: https://bugzilla.gnome.org/show_bug.cgi?id=746665 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726309: [Pkg-xfce-devel] Bug#726309: xfce4-terminal: fails to produce sigquit
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=748520 cheers, e.
Bug#783903: Gnome-terminal : missing 'open in tab'
In Preferences, you can specify whether a new terminal should be opened in a tab or a window. This setting is used if you click on the Open Terminal menu entry. As you've realized, the two actions still have their separate shortcuts. It's only the menu entry that offers only one or the other, based on your preferences. This was a deliberate change in mainstream gnome-terminal. Whether a good one or not is debatable. cheers, e.
Bug#788301: [gnome-terminal-server] freezes and eats 99% of CPU, all gnome-terminal get dead.
Sounds the same as https://bugzilla.gnome.org/show_bug.cgi?id=735101 - follow this link to find the fix to the Gtk+ patch ( https://git.gnome.org/browse/gtk+/commit/?id=561ff51a) which should ideally be backported indeed. e.
Bug#785765: [gnome-terminal] high-contrast gtk+ theme causes window to resize when hovering tab-close buttons
Duplicate of bug 765877? e.
Bug#788026: synaptic: Uses obsolete vte3 which is going away
Hi,
As per Andreas's off-bugtracker request, let me send a skeleton patch.
It compiles but sure doesn't run correctly; but at least shows which
are the bits that need to be addressed by someone familiar with
synaptic and C++. Please make sure to review every line of the patch
and address all the comments mentioned within.
In increasing order of importance:
- Minor changes around the scrollbar and font handling; I don't think
anything could've gone wrong here
- No more vtereaper, the API changed here a little bit. Previously it
was a global reaper object, so you'd need to know the PID and compare.
Now it's a signal connected to a VteTerminal instance, and I believe
there can only be one child per terminal at a time (or even if vte
allows more, I guess no reasonable app does this), so I hope verifying
and comparing the PID is not necessary anymore. Please double check if
I'm correct here.
- The big piece is spawning a process for the terminal, and here my
patch is definitely incomplete as it'd require more thorough
understanding of the code:
-- argv needs to be populated with the command to be launched
-- the possible pty flags and spawn should be carefully revised
-- I _think_ that whatever happened so far between the
vte_whatever_fork() and the exec() [now I replaced vte_whatever_fork()
by vte_whatever_spawn(), but I haven't traced down where the exec()
happens], which I believe is probably what DoInstallPostFork() does,
needs to be moved into the child_setup method of vte_whatever_spawn().
It's going to be a bit of refactoring.
Should you get stuck with these, I recommend to look at (apart from
vte's doc obviously) gnome-terminal's source code, as well as the two
small self-contained test programs (vteapp.c and app.vala) in vte's
source tree.
Good luck,
egmont
diff --git a/configure.in b/configure.in
index 4d802db..ef22639 100644
--- a/configure.in
+++ b/configure.in
@@ -47,7 +47,7 @@ dnl AC_SUBST(BUILD_wings)
dnl we build for gtk3 by default now
pkg_modules=gtk+-3.0 = 2.91.0, pango = 1.0.0, glib-2.0
-vte_modules=vte-2.90
+vte_modules=vte-2.91
PKG_CHECK_MODULES(GTK, [$pkg_modules])
BUILD_gtk=gtk
diff --git a/gtk/rgdebinstallprogress.cc b/gtk/rgdebinstallprogress.cc
index a084860..155ed27 100644
--- a/gtk/rgdebinstallprogress.cc
+++ b/gtk/rgdebinstallprogress.cc
@@ -54,18 +54,19 @@
#include i18n.h
-void RGDebInstallProgress::child_exited(VteReaper *vtereaper,
- gint child_pid, gint ret,
+void RGDebInstallProgress::child_exited(VteTerminal *vteterminal,
+ gint ret,
gpointer data)
{
RGDebInstallProgress *me = (RGDebInstallProgress*)data;
- if(child_pid == me-_child_id) {
+// I _guess_ there's no point in checking the pid, since there can be one child per terminal
+//XXX if(child_pid == me-_child_id) {
//cout correct child exited endl;
//cout waitpid returned: WEXITSTATUS(ret) endl;
me-res = (pkgPackageManager::OrderResult)WEXITSTATUS(ret);
me-child_has_exited=true;
- }
+//XXX }
}
ssize_t
@@ -289,8 +290,7 @@ void RGDebInstallProgress::conffile(gchar *conffile, gchar *status)
void RGDebInstallProgress::startUpdate()
{
child_has_exited=false;
- VteReaper* reaper = vte_reaper_get();
- g_signal_connect(G_OBJECT(reaper), child-exited,
+ g_signal_connect(VTE_TERMINAL(_term), child-exited,
G_CALLBACK(child_exited),
this);
@@ -341,8 +341,9 @@ void RGDebInstallProgress::expander_callback (GObject*object,
// this crap here is needed because VteTerminal does not like
// it when run hidden. this workaround will scroll to the end of
// the current buffer
+ // TODO is this still true as of libvte-2.91 ???
gtk_widget_realize(GTK_WIDGET(me-_term));
- GtkAdjustment *a = vte_terminal_get_adjustment(VTE_TERMINAL(me-_term));
+ GtkAdjustment *a = gtk_scrollable_get_vadjustment(GTK_SCROLLABLE(VTE_TERMINAL(me-_term)));
gtk_adjustment_set_value(a, gtk_adjustment_get_upper(a) - gtk_adjustment_get_page_size(a));
gtk_adjustment_value_changed(a);
@@ -401,15 +402,20 @@ RGDebInstallProgress::RGDebInstallProgress(RGMainWindow *main,
_term = vte_terminal_new();
vte_terminal_set_size(VTE_TERMINAL(_term),80,23);
- GtkWidget *scrollbar = gtk_vscrollbar_new (vte_terminal_get_adjustment(VTE_TERMINAL(_term)));
+ GtkWidget *scrollbar = gtk_vscrollbar_new (gtk_scrollable_get_vadjustment(GTK_SCROLLABLE(VTE_TERMINAL(_term;
gtk_widget_set_can_focus (scrollbar, FALSE);
vte_terminal_set_scrollback_lines(VTE_TERMINAL(_term), 1);
+
+ char *s;
if(_config-FindB(Synaptic::useUserTerminalFont)) {
- char *s =(char*)_config-Find(Synaptic::TerminalFontName).c_str();
- vte_terminal_set_font_from_string(VTE_TERMINAL(_term), s);
+ s =(char*)_config-Find(Synaptic::TerminalFontName).c_str();
} else {
- vte_terminal_set_font_from_string(VTE_TERMINAL(_term), monospace 8);
+ s = monospace 8;
}
+ PangoFontDescription *fontdesc =
Bug#797596: O shortcut used twice in context menu
Thanks, I filed it upstream: https://bugzilla.gnome.org/show_bug.cgi?id=754497
Bug#788026: synaptic: Uses obsolete vte3 which is going away
> If you have time it would be awsome to test the latest git. Thanks for your work! Unfortunately I don't think I'll have time to test it. If it "seems to" work (starts up the command properly) there's hardly anything that can go wrong. I recommend that you apply your patch and let the community test it as part of unstable/testing. e.
Bug#807668: terminator: Please update terminator to 0.98
Actually, instead of 0.98 you should really consider the gtk3 bazaar branch. At this moment, it contains 2 known regressions compared to the gtk2 bazaar branch (which already has maybe two dozens of bugfixes since 0.98), and the underlying VTE library (responsible for the terminal emulation itself) has received 100+ bugfixes and improvements since the gtk2 days. Hopefully these 2 known regressions will be fixed in a couple of weeks and a tarball will be released too. See also https://bugs.launchpad.net/terminator/+bug/1030562
Bug#819774: Typo in description: witch
Package: cowsay-off Version: 3.03+dfsg1-15 Package description says: This package contains cows witch some may consider to be offensive. Should be s/witch/which/
Bug#820303: remmina: Blank screen on ssh connections
Upstream investigation and fix: https://github.com/FreeRDP/Remmina/issues/835 https://bugzilla.gnome.org/show_bug.cgi?id=765382
Bug#825069: RFP: terminix -- Tiling terminal emulator using GTK+ 3 and VTE
Package: wnpp Severity: wishlist Version: 1.0.0 (as tagged in git) or newer from the 'stable' branch (see https://github.com/gnunn1/terminix/issues/25) URL: https://github.com/gnunn1/terminix License: MPL Terminix is a tiling terminal emulator. It is more or less similar to Terminator (which is already shipped by Debian). Unlike Terminator, which still uses Gtk+-2 and its matching ancient buggy and unmaintained libvte9 for terminal emulation, Terminix is based on the newest Gtk+-3 and libvte-2.91. Terminator as a project is also pretty much abandoned, whereas Terminix is actively being maintained. After significant amount of development and testing-bugfixing, version 1.0.0 has just recently been tagged in git. It has a decent UI, a neatly organized prefs window, and cool features such as a session sidebar. It is also, according to my best knowledge, the first libvte-2.91 based terminal emulator that brings back the popular feature of background image (which is no longer explicitly supported by libvte-2.91, but could be hacked around by placing an image behind a transparent vte widget). (This was committed shortly after 1.0.0.) I believe Terminix is a great replacement for Terminator, an actively maintained project providing a nicer user interface, better overall experience, and most importantly, a significantly newer and better behavior for the actual terminal emulation. Thanks, egmont
Bug#824359: Fwd: Bug#824359: mc: breaks paste in vte-based terminals
> all terminals in Debian I'd call good currently use libvte9 This is quite subjective. You might judge a terminal emulator by the "chrome" (the UI, menus, config dialog, etc.) and then it's entirely up to your taste which one you prefer. Or you might judge it by the actual terminal behavior. libvte9 gives you no rewrap on resize, no italic, no true color, scrollback data stored unencrypted on disk, couple of known segfaults, one known case of permanent scrollback data corruption, a few intermittent display corruptions, painfully slow processing of quickly arriving data, obsolete escape sequences generated on keypresses, emulation errors: just to name a few of those hundreds of issues that we've fixed since then in the gtk3 version. No doubt that libvte-2.91 provides a way superior actual terminal emulation experience. > for the insanity of GTK3's vte, it's enough to look at the font selection dialog VTE does not provide any font selection dialog, it's up to the app. As for the mc workaround, this might be a resonable thing to do, but be aware that it'll only provide partial protection, e.g. probably won't totally fix if you hide the mc panels with Ctrl+O (see mc bug 3207 for a possible scenario). cheers, egmont
Bug#824359: mc: breaks paste in vte-based terminals
Even though triggered by a recent change in mc, this is not a bug in mc, rather a bug in the (ancient, unmaintained, Gtk2-based) libvte9 (vte-0.28). See the upstream mc bug, as well as the other mc bug linked from there for explanation. Fix for libvte9 is at https://bugzilla.gnome.org/show_bug.cgi?id=729533#c6
Bug#824359: Fwd: Bug#824359: mc: breaks paste in vte-based terminals
Hi, By the way, see https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1566437 comment 7. I'm wondering, does this workaround really belong to mc? Shouldn't rather the shell prompt (PS1) emit all kinds of escape sequences that reset plenty of terminal settings (that faulty apps might leave in a undesired state) to their default? (E.g. default charset, default attributes, default keypad and numpad mode, disable mouse mode as well as mouse extensions, and a whole lot more... including, of course, disabling bracketed paste mode.) cheers, egmont
Bug#854816: remmina: Blank screen on ssh connections
Hi guys, Just one click away from the linked bug 820303, namely in https://bugzilla.gnome.org/show_bug.cgi?id=765382 it was clearly concluded -- and confirmed even by a Remmina developer -- that it was a bug in Remmina, accidentally triggered by a (not buggy) change in VTE. Again, repeating: It is clearly known to be a Remmina bug (with patch available) and by no means a VTE bug. Please act accordingly. e.
Bug#820303: remmina: Blank screen on ssh connections
Marek: "Is this bug already in upstream?"-- you've missed my previous comment here that begins with "Upstream investigation and fix". Please those links. Yup, mainstream VTE and Remmina developers have together investigated this issue, located the bug in Remmina, and came up with a patch. cheers, egmont
Bug#834455: gnome-terminal: Window height decreases by 1 line with each typed character if multiple tabs are opened
Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
Bug#834455: gnome-terminal: Window height decreases by 1 line with each typed character if multiple tabs are opened
Note: The height change probably occurs when the terminal title is set (perhaps even set again to its previous value). If the title is set via bash's PS1 then it might set it again on each keypress (but keys pressed e.g. after a "cat" won't change the window size). On Wed, Aug 17, 2016 at 11:04 AM, Egmont Koblinger <egm...@gmail.com> wrote: > Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898 >
Bug#843642: gnome-terminal: Scrolling with touchpad combines smooth and rough movement
There was no upstream bugreport up until now, however, I've talked to vte's main developer when I saw the roxterm bug and he had no clue about it either (neither did I). Mind you, neither of us actually started to deeply investigate the story. I've created an upstream bug now: https://bugzilla.gnome.org/show_bug.cgi?id=774430
Bug#747244: gnome-terminal: mouse cursor hides when typing and won't unhide when moving it again
Hi, I belive this is the same as the upstream bug at https://bugzilla.gnome.org/show_bug.cgi?id=725342, which in turn boiled down to the Gtk+ focus-out issue: https://bugzilla.gnome.org/show_bug.cgi?id=677329. If so, it's fixed in gtk+ 3.18.9. cheers, e.
Bug#807668: terminator: please package gtk3 port to experimental
Hi, Terminator 1.90 (based on gtk3) has been released. In the mean time, the gtk2 version will no longer be maintained. Please see the official announcement at https://gnometerminator.blogspot.com/2016/11/because-theyre-like-buses-which-is.html . cheers, egmont
Bug#623062: terminator: High memory usage
Hi, FYI: Approximate memory usage (RSS) for me right after starting up the apps is: gnome-terminal, xfce4-terminal, mate-terminal: 35 MB terminator: 55 MB terminix: 60 MB I'm on Ubuntu Yakkety, some of these apps are from Zesty beta or manually compiled, all of them using Gtk+-3 and corresponding libvte-2.91. (In the original report, and probably in the followup comments too they were probably based on Gtk+-2 and libvte9.) I don't know where these large numbers come from, but I can easily imagine Gtk+ itself (with all the things it's doing under the hood, e.g. I guess it caches the font, etc.) bringing in perhaps a good 30 or so megs (hey, an empty gedit consumes 44 MB for me), and perpahs the Python overhead (including its automatic deferred GC) is yet another 20 M. Dunno. VTE is expected to consume somewhere around up to maybe 0.5 MB - 1 MB per widget once you actually start using it (that is, once you produce a nice amount of output, not just the initial shell prompt and a few lines). That is, it's negligible here. cheers, egmont
Bug#822450: [terminator] Separator size doesn't work
Hi, I think this is fixed in the brand new 1.90 version; could you please confirm it? cheers, egmont
Bug#668238: terminator: Doesn't close unlinked files
Oh, wait... The fact that these file descriptors remain open _even after you close the corresponding terminal_ is still present (in Terminator-1.90) and is an actual valid issue. Hang on, I'll investigate. e.
Bug#668238: terminator: Doesn't close unlinked files
I've reported this issue upstream: https://bugs.launchpad.net/terminator/+bug/1645500 e.
Bug#330907: /usr/sbin/gnome-pty-helper: writes arbitrary utmp records
FYI: VTE (Debian package name: libvte-2.91-0) no longer ships gnome-pty-helper as of version 0.42. VTE, and in turn gnome-terminal, no longer does utmp/wtmp logging at all. See https://git.gnome.org/browse/vte/commit/?id=299c700 and https://bugzilla.gnome.org/show_bug.cgi?id=747046 for further details. cheers, egmont
Bug#809343: Lines disappear from scrollback
Hi, Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does have a bug that sounds like the one you're describing. Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've fixed the scrollback corruption bug that we were aware of. e.
Bug#843642: gnome-terminal: Scrolling with touchpad combines smooth and rough movement
Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/
Bug#833901: terminator: Copy and paste from other applications to Terminator are failing
Hi, Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does have a bug around the so-called "bracketed paste mode" which causes the behavior you see. Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've fixed this bracketed paste bug. e.
Bug#818635: terminator: Terminator omits lines in some scenarios (may be related to coloring)
Hi, Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does have a bug that sounds like the one you're describing (and yes it was related to coloring). Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've fixed the scrollback corruption bug that we were aware of. e.
Bug#668238: terminator: Doesn't close unlinked files
Hi, It is by design that Terminator (more precisely, the vte widget that does the actual terminal emulation) stores the scrollback data in unlinked temporary files. Terminator-0.98 uses the gtk2-based vte for terminal emulation, which uses too many of them, up to 12 per vte (that is, per terminal). Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug 807668) which uses the much newer gtk3-based vte, in which we've optimized it to use at most 3 files per vte. (Moreover, the contents are no longer in plain text, they are encrypted.) e.
Bug#668238: terminator: Doesn't close unlinked files
Hi, I've just read it more carefully that you're not only worried about the number of files, but also about the overall disk usage and the entire design as well. Along with the encryption, compression was also implemented, so the overall occupied size is now (with the gtk3-based vte-0.40 or newer) about 3-4x smaller than before. (Note that compression relies on the sparse block features of Unix filesystems, see https://bugzilla.gnome.org/show_bug.cgi?id=738121 and https://git.gnome.org/browse/vte/tree/src/vtestream-file.h?h=vte-0-46 if you really care about the technical details.) Looking at your bullet points in order: 1. Just make your /tmp large enough, or decrease the scrollback size. "or is actually tmpfs in memory" -- this is not a concern; the scrollback has to reside somewhere, if it's in vte's (terminator's) memory then it's essentially the same as being written to a file on tmpfs. You can't have a large scrollbar that's just magical without being stored anywhere :) 2. That's a valid point, but not related to vte or terminator in particular, and should have an app-agnostic generic solution. With a trivial modification vte could only unlilnk those files when the widget is destroyed, it'd make them easier to discover, yet remain on the disk if the app crashes. Unlinking and keeping an fd open is a typical pattern used by many others who won't need the file once the app exits, I see no reason for vte not to follow this pattern. 3. As said, with newer (gtk3-based) vte (used by terminator-1.90) it's at most 3 per widget. 4. I don't understand this at all. Who would select() on them? It's unlinked as soon as created, so noone is supposed to open it other than the creator vte / terminator itself. It's not waiting for data to appear there, so there's no select() whatsoever going on on these files, only read()/write() operations. cheers, e.
Bug#751588: Setting TERM=terminator messes up console
The correct setting for TERM is xterm (or rather xterm-256color). This variable is supposed to refer to a terminal behavior description, not to the name of the executable that is a terminal emulator. Terminator uses the VTE widget for actual terminal emulation, which in turn tries to emulate xterm as closely as reasonable. VTE defaults to xterm-256color nowadays (used to be xterm up until about a year ago), and so does gnome-terminal (the "reference" frontend developed together with VTE). If kupfer (whatever that is) requires the terminal emulator's executable name to be specified in $TERM then it's a bug (a fundamental misunderstanding of this variable) in kupfer and should be fixed there.
Bug#846645: terminator: Transparent background not working
Hi, I can confirm the transparency problem. It works on Ubuntu's default Unity 7, though. Also, transparency works under both Mutter and Unity 7 with some other emulators based on the same VTE, namely gnome-terminal with Ubuntu's transparency patch, Terminix, and xfce4-terminal. Forwarded upstream: https://bugs.launchpad.net/terminator/+bug/1647052 e.
Bug#846645: terminator: Transparent background not working
This is two separate bugreports. Transparency: What desktop / window manager are you using? VTE has reworked transparency and it requires a compositing WM. /usr/bin/who not reporting ttys: VTE, as per https://bugzilla.gnome.org/show_bug.cgi?id=747046, no longer does utmp/wtmp logging. e.
Bug#846861: layout is not displayed correctly
I've halved all the size numbers in the config, and it still appears perfectly for me (now the overall window is a "regular" window, smaller than the screen in both dimensions). Just for the record: What is your desktop environment / window manager? thx, egmont
Bug#846861: layout is not displayed correctly
Hi, I cannot reproduce this issue on Ubuntu 16.10 with Terminator-1.90 using your config. I get a terminator window occupying the entire screen, with 2x2 terminals in an equal split. Your config seems to contain hardcoded pixel values like 3200, 1672, 1600... The exact behavior might easily depend on their relation to the actual screen size. What's your screen size? My one is 1920x1080. e.
Bug#876757: gnome-terminal: does not set the underlying setting key for "show menubar"
Hi, Right click menu's "Show Menubar" by design only influences the current window (similarly to some other options there, such as selecting a Profile or toggling Read-Only). What you're looking for is the global menu's Edit -> Preferences -> "Show menubar by default in new terminals". cheers, egmont
Bug#854149: libvte-2.91-0: x-terminals not properly compose unicode characters
Hi,
This is a truly interesting bug.
If you highlight and copy-paste only the printed "1" or "2" digits, you'll
notice that "1" carries the combining strikethrough with it. This is one
possible way of making sure that VTE's belief about where that combining
accent is is correct. The problem "only" occurs when it displays it.
To make it more complicated, the behavior:
- depends on which regular characters are used instead of "1" and "2";
- depends on the combining accent
- depends on the font;
- is consistent with gedit.
Let's replace "1" and "2" with "a" and "b", as well as "x" and "y". Let's
also try '\u0301' (accent acute) in addition to the strikethrough.
echo -e '1\u03012'
echo -e 'a\u0301b'
echo -e 'x\u0301y'
echo -e '1\u03362'
echo -e 'a\u0336b'
echo -e 'x\u0336y'
and also redirect the output and open the file in gedit.
And let's try a couple of fonts:
DejaVu Sans Mono Oblique =>
Only the 2nd out of the 6 commands appear correctly ("a" with accent).
The rest: in gedit there's another cell in between containing the accent
only, in vte the accent is on top of the second letter.
FreeMono Regular, Noto Mono Regular, Tlwg Mono Regular, Ubuntu Mono Regular
=>
In both apps: The accent is always on the first character, as expected.
Liberation Mono Regular, Nimbus Mono L Regular =>
In vte: The accent is always on top of the second letter.
In gedit: The acute accent is always on top of the second letter. The
strikethrough is always in an additional cell between the two letters (as
DejaVu in 5 out of 6 cases).
Monospace Regular =>
Like DejaVu, except that the 3rd case also renders correctly (x with acute
accent).
Some conclusions:
It's broken in VTE if and only if broken in Gedit as well.
In Gedit it can be broken in two different ways; either the accent appears
over the second letter, or combines into a glyph that looks double wide
(but actually the cursor or mouse highlight jumps through it in a single
step) and contains the base letter in the left part and the combining one
in the right part. Which of these two broken variants occurs might depend
on the combining character itself.
Whether broken or not might depend on the base character and might depend
on the combining character too.
The only rendering difference between gedit and vte can be explained very
well. Gedit renders the entire flow in one step. VTE instead renders every
cell separately (putting into it the contents it wishes to see there, and
it knows correctly that these combining characters belong to the first
cell). Whatever is painted there might overflow out of the cell (and is
still painted there), but for the next character it's another painting step
started at the location VTE believes is the correct starting position. So
wherever gedit seems to paint three columns looking like "a-b", vte instead
renders "a-" beginning at column 1, and then paints "b" beginning at column
2, effectively looking as if the letter "b" was striked through.
For all the rest, it's a total mystery to me. I have no clue if it's all
these fonts that are buggy, or Gtk+'s font rendering has some fundamental
flow, or what else.
Okay, so let's check Konsole, KDE's terminal emulator build on top of Qt
and KDE libs. Konsole is notorious for not rendering each cell
independently, but rather a continuous run of text in a single step (as
most apps typically do except for terminal emulators).
KDE's behavior is almost the same as gedit's. The only exception I've found
was that with Monospace it rendered exactly as with Dejavu, that is, only
the accent on top of "a" was correct, the one on top of "x" wasn't (it was
on top of "y").
At this point my primary suspects are all these monospace fonts, although
there's sure much more to this story, e.g. there might be some mapping to
precomposed characters or whatnot...
It would be great to get someone heavily experienced in fonts involved in
this thread.
cheers,
egmont
Bug#799802: [roxterm] Dodgy filename locks up roxterm during rsync (100% CPU)
Hi, I cannot reproduce the issue -- in fact, I came across it on the bugs.debian.org website which is encoded in UTF-8 so it cannot represent the non-UTF-8 you're talking about. I'm copy-pasting the command but it's perfectly valid UTF-8 and no lockup happens. It would be great if you could construct a command line that emits such locking non-UTF-8 (e.g. echo "\x12\x34..."), whereas the command itself can be copy-pasted from UTF-8 websites. That being said, I suspect that this bug might be the same as (or similar to) https://bugzilla.xfce.org/show_bug.cgi?id=13383 https://bugzilla.gnome.org/show_bug.cgi?id=33 https://bugzilla.gnome.org/show_bug.cgi?id=730154 comments 4-7 although that wouldn't explain the 100% CPU usage. cheers, egmont
Bug#877293: gnome-terminal: Missing localization for 'Copy', 'Paste' and 'Copy as HTML'
The missing translations were committed into mainstream gnome-terminal git after the 3.26.0 release, and hence will appear in 3.26.1.
Bug#854149: libvte-2.91-0: x-terminals not properly compose unicode characters
See also https://bugs.launchpad.net/ubuntu/+source/fonts-liberation/+bug/299158.
Bug#854414: screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color."
Hi guys,
Quickly glazing through the thread, a couple of remarks:
- screen/tmux indeed needs that TERM inside them is something
screen-related. Forget xterm or xterm-256color, go with screen,
screen-256color or screen.xterm-256color or alike. This is properly
documented in their docs/faqs and answered on hundreds of random forums
(whereas, of course, the opposite is also answered on random forums, you
should use common sense which answers to trust :)) The most notable
difference is the lack of "bce" causing colored lines (e.g. in midnight
commander) not to fill the entire line, but there are other differences as
well.
- The most standard setup according to my experiences is that TERM=xterm of
the graphical terminal emulator (8/16 colors) translates into TERM=screen
inside (also 8/16 colors), whereas TERM=xterm-256color of the external
emulator ideally translates into TERM=screen-256color. I haven't heard of
any problems with this approach. (Well, strictly speaking you're still in
trouble if you launch screen from a 256-color emulator, detach and then
re-attach from an 8/16-color one.)
- Then ncurses added screen.xterm-256color, which, according to screen's
old-time behavior of prepending "screen." if such a definition is
available, messed up ssh'ing and friends. Of course given screen's
behavior, there's no way such a change could've been introduced without
such breakages.
- I don't understand why you're reluctant moving screen.xterm and
screen.xterm-256color from ncurses-term into ncurses-base. Of course it
wouldn't fix a thing now, but it's not clear to me what it'd break, and
it's desired to make screen.xterm{,-256color} widely available in the long
run. Please do it as soon as possible.
- On my machine (Ubuntu Artful) screen-256color and screen.xterm-256color
are not exactly the same file. We should investigate what's the difference
and why, and which one's the better to have.
- 256 colors became pretty standard perhaps like 5-7 years ago. Since then,
some of us put noticeable effort into pushing even further and have
truecolor support here and there (with less limited success than 256
colors, but it's already available at many places). Please, pretty please
don't make a step backwards and don't advocate solutions/workaround that
reduce the available colors to 8/16. Please don't recommend TERM=xterm or
TERM=screen as a workaround where the underlying terminal is known to
support 256 colors.
- A proper workaround might be to set screen-256color from screenrc, or
translate TERM=screen.xterm-256color into TERM=screen-256color in
/etc/bashrc.
- I've never seen anyone quoting from me; Sven, I'm happy to see you did :)
I can't remember where I wrote those exact words, but I've sure written
something analogous at multiple places. One day I might write a standalone
page summarizing all the issues and outlining a recommendation for
something better.
cheers,
egmon
Bug#899376: gnome-terminal: Ctrl-Shift-Enter/Ctrl-Enter in MC isn't working on Wayland
Hi, Terminal emulators don't send anything special on Ctrl-(Shift-)Enter, they can only send the same newline they do on Enter. MC has a hack called X11 support: Whenever it receives a newline from the terminal emulator, it queries the X server whether any modifier is pressed at that time. That's how Ctrl-(Shift-)Enter can have different actions. Give it a try under X11: do an "unset DISPLAY" and then start up "mc", these keys won't work specially anymore because mc can no longer find the X server. xterm still runs via the X compatibility layer called XWayland, that's why this hack still works there. GNOME Terminal, on the other hand, is a native Wayland app (if run under Wayland), there's no X server involved to connect to and query. I'm almost certain that Wayland's security model doesn't allow the same hack; but even if it does, it's not (yet) implemented in mc. Alt-Enter should still do the same as Ctrl-Enter used to do with the X11 hack, since in that case the terminal emulator sends a different sequence. I think the best you can do now is get used to Alt-Enter. I don't know off the top of my head how to bind some keypress to Ctrl-Shift-Enter's action, and wherever it's possible at all; you should consult mc's documentation. I guess mc should add some alternate keybinding by default. mc's manual mentions at C-Enter and C-Shift-Enter that "[m]ay not work on remote systems and some terminals" cheers, egmont
Bug#818434: libvte-2.91-0: Blink attribute doesn't work on VTE terminals such as terminator, gnome-terminal and so on.
This has just been implemented in upstream git, will be available in vte-0.52.
Bug#887649: cdebconf-gtk-terminal: Please don't depend on unmaintained vte
Hi guys, > We don't do c++ in d-i. Unfortunately this sounds really problematic. As of version 0.42 vte has been using (more and more) C++. This is not like Ubuntu's PCRE2 hack which is a matter of a few hours of work reverting and merging a few commits. It's reasonably impossible to revert to plain C and maintain that as a fork, and upstream has no intention to revert to C either. You might want to have a special libvte2.91 0.40 package, or revive libvte2.90 0.36 for the installer. These are also abandoned by upstream, but already significantly less buggier than 0.28, probably good enough for the installer (after all, 0.28 was good enough until now), and allow you to drop the gtk2 dependencies, potentially buying you many more years (perhaps you'll be good until you decide to replace gtk3 by gtk4 in the installer). I understand it's far from ideal. Other possibilities include ditching the "no c++" policy (pulling in a 1.5M lib for the sake of a 400k one, sigh), maybe seeing if there's a good enough "minimal" replacement for libstdc++ providing just the basics that are sufficient for VTE; or finding a different terminal emulator solution. cheers, egmont
Bug#887429: Depends on development and obsolete packages
Package: guake Version: 3.0.0.b2-1 The brand new package for Guake's GTK+3 version depends on certain development packages, such as libglib2.0-dev, libgtk-3-dev and libvte-2.91-dev. Presumably they pull in dozens of other packages as dependencies, if not hundreds (complete X11 development suite). Enduser applications should require solely non-development packages, such as libglib2.0-0, libgtk-3-0 and libvte-2.91-0. The package also requires libvte-common which belongs to the gtk2-based vte 0.28, and is about to be dropped from Debian real soon. The correct one is libvte-2.91-common, if required at all. Thanks, egmont
Bug#889898: Remove obsolete /usr/share/vte/termcap-2.91/xterm
Package: libvte-2.91-common Version: 0.50.2-4 The contents of /usr/share/vte/termcap-2.91/xterm have been unchanged at least since 0.28 (gtk2), about 6 years ago. xterm's terminfo description has changed significantly since then. VTE's behavior has changed a lot (got much closer to xterm). I don't think anyone locates that file there, no one would search for any file under that directory. VTE has defaulted to TERM=xterm-256color for quite some time now, so apps open the terminal description file "xterm-256color" and not "xterm", under whichever other directory. And xterm-256color is not even defined in this file. I'm quite certain this file isn't used by anyone (if it is, that's a huge problem), and its contents are heavily obsolete. Its presence might be misleading though for anyone looking at the package's contents.
Bug#890769: libslang2: incompatible with the extended terminfo format in ncurses 6.1
Hi Sven & Alastair, Thanks a lot for this bugreport and the quick fix! I've asked Slang's author to release version 2.3.2 in the near future to officially fix this issue, and he agreed to do so at the end of this month. See [1]. If that indeed happens, upgrading to 2.3.2 would be a cleaner, official fix, allowing you to drop the patch. Let's keep an eye on it. Cheers, egmont [1] http://lists.jedsoft.org/lists/slang-users/2018/000.html
Bug#908120: gnome-terminal: Cursor disappears when changing or moving window
Upstream gnome-terminal bugreport at: https://gitlab.gnome.org/ GNOME/gnome-terminal/issues/29 ... although chances are it's a bug in some other component, not gnome-terminal or vte. I'd appreciate if you could join our investigation there. thanks, egmont
Bug#890769: libslang2: incompatible with the extended terminfo format in ncurses 6.1
Hi, FYI: slang-2.3.2 is out now. cheers, e. On Wed, Feb 21, 2018 at 3:17 PM, Egmont Koblinger <egm...@gmail.com> wrote: > Hi Sven & Alastair, > > Thanks a lot for this bugreport and the quick fix! > > I've asked Slang's author to release version 2.3.2 in the near future > to officially fix this issue, and he agreed to do so at the end of > this month. See [1]. > > If that indeed happens, upgrading to 2.3.2 would be a cleaner, > official fix, allowing you to drop the patch. Let's keep an eye on it. > > Cheers, > egmont > > [1] http://lists.jedsoft.org/lists/slang-users/2018/000.html
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Hi, Just for the record, the test file is the same as in bug 912329, correct? In which direction do you move the other window? (I tried multiple possibilities.) I couldn't reproduce the bug on Ubuntu Cosmic, fvwm, and vte 0.54.2's test app. If you feel like, could you help trying out vte 0.54.2 and git master, compile the standard way (./autogen.sh or ./configure; make) and then run ./src/app/vte-2.91 ? In master we changed a couple of things around repainting. In particular, we always repaint entire lines, rather than just the desired characters. The actual repaint is I believe still limited to the bounding box GTK asks us to repaint (but I'm not absolutely sure about this), whereas this bounding box can be anything especially with non-compositing window managers. My expectation is that you'd be able to reproduce the bug with 0.54.2, but not with git master. I'm not certain in this outcome, though. And even if that's the case, probably the real bug isn't fixed, just mitigated. That fading line seems to be the cropped version of a steep line. Diagonal lines are drawn in src/vtedraw.cc, at the 0x2571 .. 0x2573 cases. Both kinds of lines are drawn from the top-whatever towards the bottom-whatever corner. So I'm a bit puzzled; if I'm on the right track so far then at one of them we forget to "lift up" the pencil before drawing the diagonal line, at the other one we forget to do this after. Or something like this... thanks a lot, egmont
Bug#912329: gnome-terminal: incorrect rendering of some box characters
Hi, Sorry, I missed that you actually attached a screenshot. I can see double lines there, on the outer frame of the first picture. Could you please elaborate what is the problem you're seeing? Thanks, egmont On Tue, Oct 30, 2018 at 1:57 PM Egmont Koblinger wrote: > Hi, > > Could you please post a screenshot? > > I get double lines in the outer rectangle of the first picture. > > The font should be irrelevant. These characters are drawn manually by VTE, > not taken by the font. Just to be sure, I've checked with your font too. I > get double lines, each 2px wide, with a 2px gap between. > > There's also a similar example at > https://gitlab.gnome.org/GNOME/vte/blob/0.54.1/doc/boxes.txt which we > used while implementing/testing these characters. > > cheers, > egmont >
Bug#912329: gnome-terminal: incorrect rendering of some box characters
Hi, Could you please post a screenshot? I get double lines in the outer rectangle of the first picture. The font should be irrelevant. These characters are drawn manually by VTE, not taken by the font. Just to be sure, I've checked with your font too. I get double lines, each 2px wide, with a 2px gap between. There's also a similar example at https://gitlab.gnome.org/GNOME/vte/blob/0.54.1/doc/boxes.txt which we used while implementing/testing these characters. cheers, egmont
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Note, mostly for myself: This reminds me of https://bugzilla.gnome.org/show_bug.cgi?id=721761#c47 . Could you please post a screenshot of the entire contents of your screen, or perhaps even a screencast? Details like the location of the previous/next character of whatever kind (e.g. manually drawn underline, replacement box etc.) might make a difference and might be the key to reproducing the issue. Thanks!
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Hi, Thanks for the screencast, I'll try to see if I can reproduce the bug based on that. (I noticed the glitch at the right side of the test file, at the X pattern too.) > It is better to move the window slowly Yes, that's what I did, pixel by pixel. > handled by VTE like the box ones? Yes, these diagonal lines (actually all in the U+2500 .. U+259F range) are painted manually. As for the font, only its dimensions should be relevant. > Note: I'm using the FVWM window manager, no desktop environment, > and the NVIDIA driver (provided by the official Debian packages). I have some ATI Radeon. According to my memories from a loong time ago, there used to be two nvidia drivers: an open-source non-accelerated and a closed-source accelerated one, one called nv and the other called nvidia (not sure which was which). I don't know if this is still the case. If so, do you happen to know which one you're using? Can you by any chance switch to the other one? And/or if you have another video card built in to the motherboard (typically Intel on laptops, really unsure about desktop), can you maybe try that? Unfortunately I cannot remember at all how to switch between them, so figuring out would be up to you. At this point I cannot rule out the possibility of this being a bug in the nvidia driver, or cairo, or somehow their interaction. But it also could be a bug in VTE. Thanks a lot, egmont
Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal
Hi, Sorry, I missed this bit: > I've just tried on another machine, which uses nouveau instead of > the nvidia driver, and I cannot reproduce the issue. Does that machine have the very same packages (e.g. both are an up-to-date sid), same cairo version, same configs (I know this one's impossible to tell)? If not then it could be purely a coincidence. But I tend to more and more suspect the nvidia driver at this point. cheers, e.
Bug#910208: Crash at encoding change
Package: libvte-2.91-0 Version: 0.54.0-1 Severity: grave Open gnome-terminal, and use its Terminal -> Set Character Encoding menu to switch to another encoding. Switch back, then again to something different. gnome-terminal crashes. Mainstream vte 0.54.1 fixes this issue. Could you please upgrade (or at least cherry-pick this fix)? Thanks, egmont
Bug#910078: the bold capability does not work after sgr0
Hi, At the end of your prompt you emit \e[37m, that is, change to the 7th palette color (typically light gray), rather than the default color of your emulator. That is, the status at the beginning of executing your command, the status used for the letter "A" is not the default status, not the one which you achieve using tput sgr0 or \e[m or \e[0m. This explains why "B" and "D" don't have the same attributes. Go to GNOME Terminal's preferences, switch to the Colors tab under your profile. You'll find the "Default color" (potentially overridden by "Use colors from system theme"), this is what sgr0 a.k.a. \e[m switches to. You'll also see the 2x8 "Color palette" entries, the upper right of them is selected by \e[37m. Even if these two have the very same RGB value, they might behave differently when combined with the ambiguous "bold/bright" flag. VTE 0.54 changed a couple of things in how it handles colors. The changes were intentional, made in the direction of separating the bold attribute from the colors. The bold counterpart of the default color used to be an automatically generated brighter variant of that color. If your default text color is a light shade of gray, the automatically generated brigher variant was most likely #FF. It's no longer the case, the combination of the bold flag with the default text color still uses the exact same text color, just with bold font. If you preferred the old behavior of making the text brighter, you should set whatever color you'd prefer here as the "Bold color". For the 7th palette color, the bold variant used to switch to the 15th palette color (the one shown underneath). Beginning with 0.54 this behavior is no longer mandatory, can be switched off by disabling "Show bold text in bright colors". (By the way, starting with 0.56 it'll be disabled by default for new users. The same checkbox will remain there for users to re-enable switching to the brighter counterpart.) I hope this clarifies what's going on. cheers, egmont
Bug#910078: the bold capability does not work after sgr0
A minor correction: The said changes appeared in vte 0.52 (gnome-terminal 3.28). Version 0.54 didn't change anything around colors.
Bug#909328: gnome-terminal: Crashes when using 'set lines=999' in Vim editor
Hello, I also tried and couldn't reproduce the problem. It's probably a race condition as gnome-terminal asks to be of size 999x999, and the window manager rejects it and forces a smaller one. How do you exactly set the size from vim? Do you put these lines in vimrc, or you type these commands interactively, etc., how exactly? I'm asking because let's say whether the two dimensions are modified in a single step or in two consecutive steps might make a difference. What's your display server (X vs. Wayland), what graphical desktop and window manager do you use? I'm asking because potentially all of them behaves somewhat differently. Does vim's startup always crash gnome-terminal for you? If not then approximately how often? A backtrace would indeed be great, I'd add to Bernhard's response that libvte-2.91-0 should also be compiled with debug symbols, since the crash is most likely inside vte. Thanks, egmont
Bug#909328: More information and new backtrace
Hi, I can also reproduce the problem under Wayland + gnome-shell (but not on X11). On Wayland the window is not forced to fit in the screen, on X11 it is (with gnome-shell). (I incorrectly thought I was testing with Wayland previously while I was actually on X11. I should've tried both, anyways, my bad.) The crash happens when the window size exceeds a constant somewhere slightly below 16384 pixels (about 100 pixels smaller or so) in either direction. Presence of the menu bar, tab bar also influence the number of maximum lines without crash, so it's the window size that matters, not the VTE widget size. - gnome-terminal-server requests some situation that gnome-shell could not > deliver, > therefore it should possibly avoid such a request. > Without having further studied what's exactly going on, I also assume it's something along these lines. We'd need to check if it's indeed gnome-terminal's responsibility to handle the error and try a smaller window size. Isn't it rather a bug somewhere in our underlying infrastructure: wayland, gnome-shell, gtk+ and friends? gnome-terminal, xfce4-terminal and roxterm (three native Wayland, VTE-based emulators that handle app-initiated resize) all crash with "Gdk-Message: 09:55:43.773: Error 71 (Protocol error) dispatching to Wayland display." - vim seems to have a problem to handle SIGHUPs while currently reacting to > user input. > Sending a SIGHUP while vim is idle does not produce a SIGSEGV. > Also I thought inside a signal handler should be done just the absolute > necessary, > at least stdio/printf or malloc is forbidden - does this apply to > sprintf too? > Sure, the less the signal handler does the better, to the extent that it could just flip a flag and do the rest from the app's main flow (check for the flag after the main pselect() which atomically blocks/unblocks the signals the app is interested in). I'm not sure about sprintf either. Vim is known not to handle correctly if two SIGWINCHes arrive quickly after each other. That is, something's not right with its main loop infrastructure. Knowing that, it's a bit less surprising that weird signal conditions can make it crash. cheers, egmont
Bug#899031: [roxterm] Please provide new roxterm packages
Hi, > it seems some people continued ROXTerm development on Github: I'd like to emphasize that it's not just "some people" who continue roxterm (maybe an unofficial fork or so). It's _the original author_ who moved it to a different location and is working on the project again. cheers, egmont
Bug#899031: [roxterm] Please provide new roxterm packages
... and he's also the maintainer of the Debian package, haha, I missed this bit :) Tony, do you feel like reviving maintenance of the Debian package, or perhaps finding a new maintainer for it? Thanks, egmont
