2.15.10 FTBS

[Nicholas Bamber]

On 15. 11. 15 12:14, Osamu Aoki wrote:
> Hi,
>
> I use pbuilder(cowbuilder to be precise).
>
> On Sat, Nov 14, 2015 at 01:55:46PM +0000, Nicholas Bamber wrote:
>> Osamu,
>> 	I am getting the following FTBS when I attempt to build in sbuild:
>>
>>
>> uupdate: Auto-generating foo_1.0-1.debian.tar.xz
>> /<<PKGBUILDDIR>>/scripts/uupdate: line 1060: /dev/tty: No such device or
>> address
>
> This is odd.  Normal environment have /dev/tty
>
> $ ls -l /dev/tty
> crw-rw-rw- 1 root tty 5, 0 Nov 15 07:59 /dev/tty
>
> You need to mount this device in chroot via sbuilder configuration.
>
> In line 1060:
> cp -i $DEBIANFILE ${NEW_DEBIANFILE} 2>/dev/tty
>
> This redirection is needed to show prompt to the console when uscan runs
> uupdate and capture both stdout and stderr.  This was quick trick.  Of
> course, we can move all outputs to stdout only and let uscan capture
> only stdout, then I do not need /dev/tty.
>
> Roger (sbuild upstream) said:
>   https://lists.debian.org/debian-devel/2014/01/msg00066.html
>
> This is OK for "build"-phase but not so nice for"test"-phase
> But this may be something to worry and be considerate.
>
> Osamu
>

Osamu,
	I am not sure I am interpreting Roger's post quite the same way as you. 
To quote:

"You aren't guaranteed to have a controlling terminal, particularly when
run via buildd.  ...  If you
need to output anything, then just use stdout/err as appropriate and it
will be logged, but /dev/tty may well be unavailable.  I would
recommend not using `tty` or doing any IO on /dev/tty since in all
likelihood isatty/ttyname(_r) will most likely return ENOTTY and any
IO on /dev/tty will simply fail. We have looked at using ptys in the 
past for running the builds in
order to guarantee a tty, but decided against it.  Too many programs
make the assumption that they are interactive and freeze the build
waiting on IO that never happens and then block forever. "


Everything about those two paragraphs reeks to me off "DO NOT ASSUME 
/dev/tty". Since we are looking at code and not test code, and I do not 
know this code, I won't run an experiment myself, but have you considered:

cp -i $DEBIANFILE ${NEW_DEBIANFILE} 2>&1


In fact since we are looking at code rather than test code, that makes 
it worse since conceivably people could be using the code in ways you 
don't expect. You might be breaking something by introducing a 
dependency on /dev/tty.