[Reproducible-builds] Bug#829113: Bug#829113: reprotest: Should unset $DISPLAY to avoid GUI popups from some build tools

[Axel Beckert]

Hi,

Jérémy Bobbio wrote:
> Axel Beckert:
> > Running
> > 
> > $ reprotest 'dpkg-buildpackage -b' ../debian-paketmanagement-buch_0\~2016.06.29_all.deb
> > 
> > from a git checkout of commit 5f069a920df4e6f20a8eb9309c20c39ad60e6132
> > under X to see if my $SOURCE_DATE_EPOCH implementation in that commit is
> > working correctly.
> > 
> >    * What was the outcome of this action?
> > 
> > Two GUI popups from ebook-convert (from the package calibre) moaning
> > about non-existent $HOME and hence unreadable $HOME/.config/…
> > 
> >    * What outcome did you expect instead?
> > 
> > No interactivity, especially no GUI interactivity at all.
> > 
> > Unsetting $DISPLAY should this issue.
> > 
> > (I'm not sure if setting and not setting $DISPLAY is or should be one of
> > the not explicitly listed variations. But since I got that popup twice,
> > I assume not.)
> 
> I don't think this is a bug in reprotest. As far as I can see by looking
> in dpkg source tree, `dpkg-buildpackage` doesn't do anything to the
> DISPLAY variable etiher.

I wondered about that, too, but came to a different conclusion:

dpkg-buildpackage is a rather low-level build tool. It IMHO also needs
to work in some (non-Debian) cases where some interaction is needed
during the build.

reprotest, pbuilder and friends on the other hand are meant to be
fully-automatic tools geared towards no user interaction at all.

This also fits with Mattia's comment that pbuilder also unsets
$DISPLAY and it's on the same kind of level as reprotest.

(I though surely won't object if someone manages to get that into
dpkg-buildpackage. :-)

> So I would assume building the package might
> fail just as well without reprotest.

JFTR: It doesn't fail. It's just stopped and waiting for user input.

And no, it doesn't make those popups on a normal build, probably
because $HOME exists.

> If building the package requires to unset DISPLAY, I think this
> should be done in `debian/rules`…

I'm torn here. While I see your point, I think that's something that
should be done generally in the tool chain. It's though debatable
_where_ in the tool-chain it should be done.

> One take though, maybe reprotest should ensure that $HOME is set to an
> existing (temporary) directory; other building tools might get unhappy.

Yes, that would help in this case, too.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE