Re: pkg/41971: graphics/dia-python cannot find pygtk module (py25-gtk2 is installed)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/41971; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module (py25-gtk2 
is installed) 
Date: Sat, 26 Sep 2009 23:24:25 +0700

     Date:        Sat, 26 Sep 2009 02:00:08 +0000 (UTC)
     From:        "OBATA Akio" <obache%NetBSD.org@localhost>
     Message-ID:  <20090926020008.B0A7563B850%www.NetBSD.org@localhost>
 
   |  Not strange behaviour, because pygtk should be used with X,
   |  so it is reasonable to make a connection to the X server in
   |  its initialization.
 
 I'd agree with that, the question would be more when its initialisation
 should happen - I'd suggest not until it is really used, and simply
 mentioning it in the compilation unit (which is more or less all the
 program run by configure does, I think) shouldn't be enough - after all,
 a program might have an option whether it shoudl use a gui interface or not
 (several do) - we wouldn't want the program attempting to make a
 connection to an X server merely because it had been compiled to include
 a gui, when it was run with an option that causes the gui not to be used.
 
   |  First of all, you should fix your environment.
   |  Change DISPLAY to usable variable, or unset DISPLAY.
 
 My environment is fine - that's the point really, DISPLAY is actually a
 valid value (when it is bogus, the package builds).   The problem is that
 in the pkg_comp sandbox, there's no way the application can access the
 files needed to obtain correct authorisation - that's (part of) the whole
 point of using a sandbox.  So while I still believe there's some python,
 or pygtk, or similar problem here, it would also be reasonable to argue
 that there;s a pkg_comp bug as well, in that it should probably be unsetting
 DISPLAY before it starts any build, as (unless the X server is doing
 host based auth, which is even worse than its other methods) there's not
 going to be any way for the DISPLAY setting from outside pkg_comp to be
 useful inside.   I'll fix my pkg_comp to do that.
 
 This PR can probably close, however the problem is eventually resolved,
 it doesn't appear as if there's anything that dia-python could reasonbly
 do differently (except perhaps not bothering to do the autoconf test for
 pygtk).
 
 kre