878089 - mach: blessings/curses fails to setup terminal when TERM is not set

Status: RESOLVED FIXED

(Firefox Build System :: Mach Core, enhancement)

Description

[Landry Breuil (:gaston)]

With 22.0b3, running configure within tmux (TERM=screen)

creating ./config.status
Traceback (most recent call last):
  File "./config.status", line 1008, in <module>
    config_status(**args)
  File "/usr/obj/firefox-22.0beta3/mozilla-beta/build/ConfigStatus.py", line 117, in config_status
    log_manager.add_terminal_logging(level=log_level)
  File "/usr/obj/firefox-22.0beta3/mozilla-beta/python/mach/mach/logging.py", line 177, in add_terminal_logging
    if self.terminal:
  File "/usr/obj/firefox-22.0beta3/mozilla-beta/python/mach/mach/logging.py", line 149, in terminal
    terminal = blessings.Terminal(stream=sys.stdout)
  File "/usr/obj/firefox-22.0beta3/mozilla-beta/python/blessings/blessings/__init__.py", line 98, in __init__
    self._init_descriptor)
_curses.error: setupterm: could not find terminal

python 2.7.4

Comment 1

[Landry Breuil (:gaston)]

Same problem outside of tmux with TERM=xterm

Comment 2

[Landry Breuil (:gaston)]

Running mach itself from trunk is fine, fwiw.

Comment 3

[Landry Breuil (:gaston)]

Same with 22.0b1

Comment 4

[Landry Breuil (:gaston)]

In a python shell, import curses + from curses import tigetstr, tigetnum, setupterm, tparm
doesnt throw an exception.

Comment 5

[Landry Breuil (:gaston)]

import sys
import blessings
blessings.Terminal(stream=sys.stdout)

also works in a shell, so mach might be doing something strange here.

Comment 6

[Landry Breuil (:gaston)]

Interestingly, running gmake -f client.mk configure from a mozilla-beta tree works fine on the same host. So something in the configure machineray ? In the build env ?

Comment 7

[Landry Breuil (:gaston)]

Ah, running configure directly from the 22.0b3 tarball seems to pass :

mozilla-beta/ $CC=egcc CXX=eg++ ./configure --disable-necko-wifi

so probably something in the build env set by our port infrastructure....

Comment 8

[Landry Breuil (:gaston)]

Ok, found it, and it's nasty.

our build infrastructure ignores the environment via env -i, so TERM is unset when it reaches blessings -> boom.

$env -i CC=egcc CXX=eg++ ./configure --disable-necko-wifi 

that reproduces the issue here.

So:
- i can workaround this locally by setting TERM in the port build env, but this is ugly
- blessings/python curses ought to fallback sanely if TERM is empty/not set ?

Comment 9

[Landry Breuil (:gaston)]

Easily reproducible in a shell:

Python 2.7.4 (default, May 20 2013, 14:23:42) 
[GCC 4.2.1 20070719 ] on openbsd5
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
>>> from curses import setupterm
>>> setupterm('unknown',1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_curses.error: setupterm: could not find terminal
>>> setupterm('screen',1)
>>>

Comment 10

[Gregory Szorc [:gps]]

Attachment: mach shouldn't fail if terminal couldn't be configured

Comment 11

[Gregory Szorc [:gps]]

Attachment: mach shouldn't fail if terminal couldn't be configured

Comment 12

[Landry Breuil (:gaston)]

Comment on attachment 760556 [details] [diff] [review]
mach shouldn't fail if terminal couldn't be configured

Review of attachment 760556 [details] [diff] [review]:
-----------------------------------------------------------------

Att 760555 & 760556 were the same, was this intended ?

While i dont really like the idea of silently ignoring an error (i'd rather have blessings default to xterm or smth instead of 'unknown' when TERM is unset..) , with that patch i can run make configure in my ffx 22.0b3 port (which unsets TERM in the infrastructure) it doesnt blow, and i still get the output of configure & build logged on the terminal.

Comment 13

[Gregory Szorc [:gps]]

Without blessings configured, you would miss out on color and the build footer. That set may increase over time, of course. i.e. output would look very similar to |make -f client.mk|.

Comment 14

[(not currently active) Ted Mielczarek]

Comment on attachment 760556 [details] [diff] [review]
mach shouldn't fail if terminal couldn't be configured

Review of attachment 760556 [details] [diff] [review]:
-----------------------------------------------------------------

::: python/mach/mach/logging.py
@@ +157,4 @@
>  
> +                if terminal.is_a_tty:
> +                    self._terminal = terminal
> +            except Exception as e:

Don't really need the "as e" bit here if you're just going to ignore it.

Comment 15

[Gregory Szorc [:gps]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6fac977ad9ea

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6fac977ad9ea

Comment 17

[Landry Breuil (:gaston)]

Needs backport to aurora/beta..

Comment 18

[Gregory Szorc [:gps]]

Why should we backport this? Just build those trees without mach. It should be a trivial backport if we want to take it though.

Comment 19

[Landry Breuil (:gaston)]

It's not a question of mach. I first saw the issue (see comment #1) when running the configure script from the 22.0b3 tarball, not planning at all to call mach.....

Comment 20

[Landry Breuil (:gaston)]

I'm afraid this will hit distributors who build in a clean environment and will end up failing to run configure, but at that point it's too late for 22.0 which is already at candidate build2...