1432867 - FYI: error: setupterm: could not find terminal

Status: NEW

(Firefox Build System :: General, defect)

Description

[ISHIKAWA, Chiaki (I will be tied up until Dec 14 with day job events.)]

This is an informative report to those unsuspecting developers who find something
strange happen under their rug after system upgrade, etc.

I am using GNU/Linux, Debian distribution at that.

After an OS package upgrade in mid-December,
 I could not run |mach build| on one of my PCs.
On another  PC, build runs fine.
But on the other, my main development PC, it does not.

It spews out the following error lines, and the crux of it is
|error: setupterm: could not find terminal|

---The log

Error running mach:

    ['--log-no-times', 'build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

error: setupterm: could not find terminal

  File "/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/mach_commands.py", line 171, in build
    mach_context=self._mach_context)
  File "/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/controller/building.py", line 944, in build
    footer = BuildProgressFooter(self.log_manager.terminal, monitor)
  File "/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozbuild/mozbuild/controller/building.py", line 576, in __init__
    Footer.__init__(self, terminal)
  File "/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozterm/mozterm/widgets.py", line 12, in __init__
    self.term = terminal or Terminal()
  File "/NREF-COMM-CENTRAL/comm-central/mozilla/python/mozterm/mozterm/terminal.py", line 49, in Terminal
    return blessings.Terminal(**kwargs)
  File "/NREF-COMM-CENTRAL/comm-central/mozilla/third_party/python/blessings/blessings/__init__.py", line 109, in __init__
    self._init_descriptor)
--- end log

This has made me really stumped for like 8 weeks because the solution/cause is at unexpected place.

I did not know exactly what the cause was. But a few e-mail exchanges let me learn that the code in question is from "blessing" package.
https://groups.google.com/forum/#!topic/mozilla.dev.apps.thunderbird/mzEu2KI9foA

Also I learned there was a bug report about it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1428494 

But even after the patch seems to have landed from it, my woe continued.

Anyway, I bit the bullet and tried to see if I can get down to the bottom of this "blessing" package issue. I hated to do extra work to poke into third party tool that is used in a non-essential manner, but I changed the code
in mozilla/third_party/python/blessings/blessings/
where setupterm is called, first, by changing the first |kind| argument  with
|'xterm'| and saw the build no longer failed. Great.

But to send in a bug report as complete as possible, and to see why it broke in the first place, I tried to see what is
handed as of now under my setup. Here is the changed code.

        if self.does_styling:
            # Make things like tigetstr() work. Explicit args make setupterm()
            # work even when -s is passed to nosetests. Lean toward sending
            # init sequences to the stream if it has a file descriptor, and
            # send them to stdout as a fallback, since they have to go
            # somewhere.
            # CI: force kind to 'xterm'
            print "kind=%s" % kind
            print "environ.get('TERM', 'unknown')=%s" % environ.get('TERM', 'unknown')
            print "environ.get('TERM', 'linux')=%s" % environ.get('TERM', 'linux')
            setupterm(kind or environ.get('TERM', 'unknown'),
                      self._init_descriptor)

        self.stream = stream


And I found this.
kind is always null.
And I seem to pass |'emacs') to |TERM| variable.
if I set TERM to xterm, it works as is expected.

Then why on earth on my original setup (which worked for many years) suddenly stopped working?

I set TERM to |emacs| for various reasons. One reason being that I 
often invoke my own script to invoke build under "shell-mode" of Emacs editor.
I want the invocation of the same script under other windows/terminal emulators 
resemble that of invocation under emacs shell-mode visually.

That I think caused a problem in my setup AFTER the OS package upgrade.

I think setting TERM to |emacs| let programs work basically the same as when TERM is to |dumb|.
See the GNU emacs FAQ about it:

https://www.gnu.org/software/emacs/manual/html_node/efaq/Termcap_002fTerminfo-entries-for-Emacs.html

So it *SEEMS* that somehow OS upgrade failed to update emacs entry for it.
*HOWEVER*, even after I set TERMCAP environment variable,
created |emacs| entry for TERMINFO (it seems Debian uses TERMINFO package),
blessing still spews out the same error message if I set TERM to |emacs| during |mach build|.
So for now, I set it to dumb (which is the default under shell-mode these days?)
Then |mach build| works.

There is a bug report about blessing that if TERM is not set, it does not work, etc.
https://github.com/erikrose/blessings/issues/39

But obviously my case is slightly different.

Anyway, this bugzilla entry is created in the hope that someone who gets bitten by strange behavior caused by OS package upgrade can figure out if the particular setting of TERM environment variable is the cause of his/her problem.

TIA

PS: Wait a second, is the following bug marked FIXED  essentially a dupe of what I am seeing in a disguise?
https://bugzilla.mozilla.org/show_bug.cgi?id=878089