On Fri, Feb 12, 2010 at 12:16:16PM +0100, Loïc Minier wrote:
> 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...
Rocky, any thoughts? I guess at the worst case we could simply disable
the tests if no tty is available.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
