Bug 164210 - disable Tek support by default
disable Tek support by default
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-25 18:48 EDT by dann
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-04 09:21:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dann 2005-07-25 18:48:23 EDT
Description of problem:
xterm is compiled with Tek support by default. 
It is doubtful that there are any Tek terminals around... 

Disabling Tek support reduces the binary size: 
size -f xterm.disable.tek xterm
   text    data     bss     dec     hex filename
 172799   15376    6684  194859   2f92b xterm.disable.tek
 196140   17580    8284  222004   36334 xterm

This is with xterm-202 configured with ./configure --disable-tek4014 for
xterm.disable.tek and just ./configure for xterm on a FC4 x86 system.


Version-Release number of selected component (if applicable):
xterm-200-6
Comment 1 Thomas E. Dickey 2005-08-07 17:50:24 EDT
iirc, gnuplot has a driver for this.
Comment 2 Mike A. Harris 2005-08-30 12:14:52 EDT
dann:  Sounds reasonable to me.  If we disable it in rawhide right now,
there is oodles of time for people to test rawhide prior to FC5 being
released.  If anyone out there uses tek terminal support and files a bug
report, we can always re-enable it before FC5 ships.

I'll update it in the next xterm build.
Comment 3 Mike A. Harris 2005-08-30 13:02:00 EDT
Added to xterm-200-8 in rawhide.
Comment 4 Fedora Update System 2005-11-07 14:34:36 EST
From User-Agent: XML-RPC

xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 5 Fedora Update System 2005-11-14 13:05:25 EST
From User-Agent: XML-RPC

xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 6 Chris Adams 2005-11-14 14:18:19 EST
I use the Tek support occasionally, as does my father; it is one of the useful
features in xterm vs. most other terminal emulators.

If someone doesn't want Tek4014 support they can always use something else. 
Reducing the size of the binary should not be a primary goal at the cost of
features that aren't available in anything else.
Comment 7 Chris Adams 2005-11-14 14:20:01 EST
Also, features should NOT be removed mid-stream.  If the decision to drop
Tek4014 support is made, it should only apply to future releases, not FC4.
Comment 8 dann 2005-11-14 14:43:17 EST
(In reply to comment #6)
> I use the Tek support occasionally, as does my father; it is one of the useful
> features in xterm vs. most other terminal emulators.

Just curious, what do you use the Tek support for? Do you have a machine with
a Tektronix terminal? 
Comment 9 Chris Adams 2005-11-14 14:57:48 EST
No, I don't have a true Tek terminal; that's why I use xterm's Tek4014 emulation
mode (just like people use xterm's VT102/VT220 emulation mode because they don't
have a standalone terminal).  I've got a VT102, but it is much nicer to use
xterm for most things.

Maybe there's a misunderstanding here: xterm emulates multiple terminal types. 
What most people use is the VT102/VT220 emulation mode.  There is also a Tek4014
emulation mode that is useful if you have programs that generate Tek4014 vector
graphics; they can be run in an xterm.  AFAIK there is no other Tek4014 emulator
available.

I occasionally use gnuplot with Tek4014 output instead of direct X11 output (it
can be easier to script).  My father (and a bunch of the people he works with)
uses a custom graphing program that has Tek4014 output as an option (but IIRC it
doesn't support X11).
Comment 10 Chris Adams 2005-11-23 14:33:59 EST
There is still a bug here.  Either:

- you have removed functionality (tek4014 emulation) during a "stable" release

or

- you have removed functionality without fixing the spec file to document it
(the %description still says "and Tektronix 4014".

I still think that removing working functionality (that is not duplicated in any
other package that I am aware of) for the sole reason of slightly reducing the
binary size is a bad idea.  The only way to get tek4014 emulation under X is to
use xterm with it built in, so the only way this could even show up in Fedora
Extras is to take the xterm source RPM and rebuild it without --disable-tek4014
(but Extras packages aren't supposed to replace Core, so that wouldn't be allowed).
Comment 11 Mike A. Harris 2005-11-23 17:52:53 EST
Ok, so it seems like some people do use tek support...  That seems like
a good reason to re-enable it IMHO, as people who don't need it can just
not use it, but people who do need it don't have it right now.

However... the xterm package baton has recently been passed on to
another developer...

reassigning...
Comment 12 Jason Vas Dias 2005-12-21 17:31:49 EST
OK, tek4014 mode is back, with xterm-207-2.FC4, and xterm-207-10 (FC-5).
You can build the SRPM with '--define _with_tek4014 0' to disable it again.
Comment 13 Fedora Update System 2005-12-21 18:05:12 EST
From User-Agent: XML-RPC

xterm-207-2.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 14 Fedora Update System 2006-01-09 13:59:05 EST
From User-Agent: XML-RPC

xterm-207-2.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 15 Chris Adams 2006-02-04 09:21:40 EST
Yes, I see tek mode back.

Note You need to log in before you can comment on or make changes to this bug.