Hi
On Fri, Dec 11, 2009, Lucas Nussbaum wrote:
> Relevant part:
Actually that's not the whole relevant part; there's also:
checking whether make sets $(MAKE)... yes
get_processor:3: command not found: ps
./ok4zshdb.sh:43: command not found: -if
checking Checking whether /bin/zsh is compatible with zshdb... Your zsh doesn't
have the fc -l patches.
yes!
checking for diff... /usr/bin/diff
adding -w to diff in regression tests
This particular problem is due to a missing build-dep on procps which
provides ps, used in test/zsh/ok4zshdb.sh:get_processor().
(debootstrap --variant=buildd wont pull procps)
> > /build/user-zshdb_0.03+git20090920-1-amd64-hSCnaM/zshdb-0.03+git20090920/lib/processor.sh:37:
> > no such file or directory:
That's the meat of the problem: lib/processor.sh:37 breaks the build
because it uses $TTY:
# For zsh, using this builtin parameter $TTY seems preferred over &0
# because it will find/fake a terminal when &0 might not be one.
exec {_Dbg_fdi}<$TTY
TTY isn't set
I managed to reproduce the problem in my build environment with:
sudo mv /dev/tty /dev/tty.bak
env -i dpkg-buildpackage -b </dev/null >log 2>&1
(obviously this might break your system)
So I believe the buildd environment has a partial /dev without
/dev/tty.
I tried replacing $TTY with &0, and a real file, but that didn't work
(hit the same test failures), and with a fifo, but that hanged the
build waiting for the fifo to fill in.
I'm not familiar with zshdb, but I suspect it might need a TTY during
debug sessions which might be why the testsuite would use one as well.
Someone more familiar with zshdb could perhaps check whether we can use
coproc here, or a pair of fifos (adding code to properly close them as
well), to replace the use of $TTY. Perhaps another way would be to
pass a script (list of commands to run) to zshdb.
As a last resort, I tried running make check under "expect", but oddly
that failed in the same way. While expect correctly sets up stdin,
stdout, stderr on a pty,
test/integration/check-common.sh:run_test_check() ruins that effort by
using redirections:
(cd $srcdir && run_debugger $debugged_script 2>&1 >$TEST_FILE
</dev/null)
so zsh sees that stdin, stdout, and stderr aren't ttys and falls back
to /dev/tty (which doesn't exist apparently).
So I tried working around that with:
expect -c 'spawn zsh -c "ZSH_TTY=\$$TTY $(MAKE) check"; expect'
and changing lib/processor.sh to use ZSH_TTY. I don't know why *that*
still fails.
So it seems the only way is to rework the testsuite to not rely on
using a real tty...
Bye
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
