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

["OBATA Akio" <obache%netbsd.org@localhost>]

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

From: "OBATA Akio" <obache%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module
 (py25-gtk2 is installed) 
Date: Mon, 28 Sep 2009 21:29:16 +0900

 On Sun, 27 Sep 2009 01:30:05 +0900, Robert Elz <kre%munnari.oz.au@localhost> 
wrote:
 
 >    |  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.
 
 Such matters should be sent to upstream.
 They are not pkgsrc problems.
 Talking here will not resolve anything.
 
 >    |  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.
 
 It is just because your environment is not fine to use with pkg_comp.
 As you know, some packages require to access X.