Hi Roger, On Mon, May 30, 2011 at 07:41:16PM +0100, Roger Leigh wrote: > I was wondering whether or not this is still an issue for upstart? > > As far as I understand, the build is failing because we run > dpkg-buildpackage without a controlling TTY. This has been the > historical behaviour of sbuild (though for a short while the > behaviour was removed).
It's still a problem yes, but arguably, it is a problem with Upstart. It should only test controlling terminal logic if one is available. > From the sbuild POV, the question is whether or not this is > appropriate, and if we should continue to do this. However, while > sbuild explicitly calls setsid, one consideration is that when > run by buildd, buildd is itself already detached from its CTTY > when it dæmonises, as a result any change in sbuild would only > have an effect when run interactively. Right. > If we were to alter sbuild's behaviour, we would have to create > a PTY, run dpkg-buildpackage on the slave side and have sbuild > record the build log from the master side. > > On the other hand, if upstart requires a CTTY for its tests, it > would make sense for the test code to create a dedicated PTY for > its tests to ensure that the tests will always run connected to > a terminal. A simple openpty(3) would be sufficient if you > dup() stdin/out/err for the child after fork so that the test > runs on the PTY slave. I would tend to agree in this case. -Kees -- Kees Cook @debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
