NetBSD Problem Report #41971

From kre@munnari.OZ.AU  Tue Sep  1 15:56:57 2009
Return-Path: <kre@munnari.OZ.AU>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id ACEB963BAC2
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  1 Sep 2009 15:56:57 +0000 (UTC)
Message-Id: <200909011556.n81Fup5I025508@jade.coe.psu.ac.th>
Date: Tue, 1 Sep 2009 22:56:51 +0700 (ICT)
From: kre@munnari.OZ.AU
To: gnats-bugs@gnats.NetBSD.org
Subject: graphics/dia-python cannot find pygtk module (py25-gtk2 is installed)
X-Send-Pr-Version: 3.95

>Number:         41971
>Category:       pkg
>Synopsis:       graphics/dia-python cannot find pygtk module (py25-gtk2 is installed)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 01 16:00:00 +0000 2009
>Last-Modified:  Sun May 13 23:25:01 +0000 2012
>Originator:     Robert Elz
>Release:        NetBSD 4.0 / i386  pkgsrc-current
>Organization:
	Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE (JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008 kre@jade.coe.psu.ac.th:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
	graphics/dia-python (dia-python-0.96.1nb4) claims to be unable to
	locate the pygtk module during its configure stage.

	pkgsrc has installed py25-gtk2-2.14.1nb2 as a dependency.

>How-To-Repeat:
	I use pkg_comp with libkver and NetBSD 4.0 sets installed
	to simulate a NetBSD 4.0 release environment (using pkgsrc
	modular xorg instead of the x* sets).   I doubt any of that
	is relevant.

	In that environment I see ...

checking if Python version >= 1.5.2... okay
checking local Python configuration... checking for  script directory... /usr/pkg/lib/python2.5/site-packages
checking for  extension module directory... /usr/pkg/lib/python2.5/site-packages looks good
checking for python module gtk... no
configure: error: could not find pygtk module
*** Error code 1

	From the config.log, this looks like it might be a case
	of the config script attempting to connect to the X server
	(which it cannot do in my pkg_comp sandbox, there is no authorisation
	inside there.   I surmise that from ...

configure:25062: checking for python module gtk
The application '-c' lost its connection to the display localhost:14.0;
most likely the X server was shut down or you killed/destroyed
the application.
configure:25091: result: no
configure:25093: error: could not find pygtk module

>Fix:
	Find some way to fix configure to avoid dynamically using
	gtk just to discover if it exists (I guess).

>Audit-Trail:
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module
 (py25-gtk2 is installed)
Date: Fri, 25 Sep 2009 20:54:15 +0900

 On Wed, 02 Sep 2009 01:00:01 +0900, <kre@munnari.oz.au> wrote:

 > 	From the config.log, this looks like it might be a case
 > 	of the config script attempting to connect to the X server
 > 	(which it cannot do in my pkg_comp sandbox, there is no authorisation
 > 	inside there.   I surmise that from ...
 >
 > configure:25062: checking for python module gtk
 > The application '-c' lost its connection to the display localhost:14.0;
 > most likely the X server was shut down or you killed/destroyed
 > the application.
 > configure:25091: result: no
 > configure:25093: error: could not find pygtk module

 What is DISPLAY "localhost:14.0"?
 Even if I set DISPLAY=localhost:14.0, and without X for the DISPLAY:

 configure:25062: checking for python module gtk
 /usr/pkg/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display
    warnings.warn(str(e), _gtk.Warning)
 configure:25088: result: yes

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

     Date:        Fri, 25 Sep 2009 11:55:01 +0000 (UTC)
     From:        "OBATA Akio" <obache@NetBSD.org>
     Message-ID:  <20090925115501.D25F863B850@www.NetBSD.org>

   |  What is DISPLAY "localhost:14.0"?

 It would have been X forwarding from the ssh connection I used
 to start the pkg_comp process that was doing the build.  The
 "server" would have existed, and an inet type connection woould
 have received a TCP syn ack (I assume), but inside the sandbox
 created by pkg_comp there's no way it could have accessed any
 authentication credentials to permi a successful connection, the
 ssh [rocess would have summarily executed it.

   |  Even if I set DISPLAY=localhost:14.0, and without X for the DISPLAY:

 I guess the test behaves differently when it cannot connect at all,
 as compared to when it can connect, but is refused permission.
 Why it would make that distinction I have no idea, that's not
 rational.

 Either that, or somthing has changed since that PR was filed, I'll
 give it another go (with the same basic environment) soon.

 kre

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

     Date:        Fri, 25 Sep 2009 11:55:01 +0000 (UTC)
     From:        "OBATA Akio" <obache@NetBSD.org>
     Message-ID:  <20090925115501.D25F863B850@www.NetBSD.org>

   |  configure:25062: checking for python module gtk
   |  /usr/pkg/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display
   |     warnings.warn(str(e), _gtk.Warning)
   |  configure:25088: result: yes

 Yes, I see the exact same thing when DISPLAY is a random value.
 When it is a proper, but unauthorised, server, it still fails just the
 same way as described in the initial PR.

 That makes for a simple workaround to build the package, and suggests
 that the real problem here is very strange  behaviour of the pygtk
 module (&/or python) rather than a defect in this package itself.

 It isn't even clear why pygtk would want to make a connection to
 the X server when used the way it is by the tiny program configure runs
 to check that pygtk is present.

 A fairly easy fix (avoidance procedure) for this package would be to
 simply remove the test for pygtk from the configure script - pkgsrc
 knows (ensures) that pygtk is present using its dependency mechanism,
 there's no real need in a pkgsrc environment to test further for it.

 kre

From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module
 (py25-gtk2 is installed) 
Date: Sat, 26 Sep 2009 10:55:18 +0900

 On Sat, 26 Sep 2009 09:50:04 +0900, Robert Elz <kre@munnari.oz.au> wrote:

 >  That makes for a simple workaround to build the package, and suggests
 >  that the real problem here is very strange  behaviour of the pygtk
 >  module (&/or python) rather than a defect in this package itself.
 >
 >  It isn't even clear why pygtk would want to make a connection to
 >  the X server when used the way it is by the tiny program configure runs
 >  to check that pygtk is present.

 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.

 >  A fairly easy fix (avoidance procedure) for this package would be to
 >  simply remove the test for pygtk from the configure script - pkgsrc
 >  knows (ensures) that pygtk is present using its dependency mechanism,
 >  there's no real need in a pkgsrc environment to test further for it.

 First of all, you should fix your environment.
 Change DISPLAY to usable variable, or unset DISPLAY.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
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>
     Message-ID:  <20090926020008.B0A7563B850@www.NetBSD.org>

   |  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

From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
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> 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.

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,
	kre@munnari.OZ.AU
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module
	(py25-gtk2 is installed)
Date: Fri, 15 Jan 2010 18:05:15 +0000

 On Mon, Sep 28, 2009 at 12:30:05PM +0000, OBATA Akio wrote:
  >>    |  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.

 How hard would it be for pkg_comp to do display forwarding out of the
 sandbox as an option? It seems to me that having it clear $DISPLAY is
 the correct default behavior.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module (py25-gtk2 is installed)
Date: Sat, 16 Jan 2010 01:57:56 +0700

     Date:        Fri, 15 Jan 2010 18:10:07 +0000 (UTC)
     From:        David Holland <dholland-pbugs@NetBSD.org>
     Message-ID:  <20100115181007.3726C63C2E4@www.NetBSD.org>

   |  How hard would it be for pkg_comp to do display forwarding out of the
   |  sandbox as an option?

 True forwarding, quite difficult I expect - but it would probably be
 possible to copy in the XAUTHORISATION file and make sure DISPLAY was
 set to force a true network connection, and it would probably work.

   |  It seems to me that having it clear $DISPLAY is
   |  the correct default behavior.

 That's what I'm doing in the version of pkg_comp I'm using now, and
 I haven't seen any further problems - but I don't know that I have built
 anything that truly requires an X connection to build (if such a thing
 exists).

 kre

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module
	(py25-gtk2 is installed)
Date: Sun, 24 Jan 2010 01:54:06 +0000

 On Fri, Jan 15, 2010 at 07:00:06PM +0000, Robert Elz wrote:
  >    |  How hard would it be for pkg_comp to do display forwarding out of the
  >    |  sandbox as an option?
  >  
  >  True forwarding, quite difficult I expect -

 There's code in openssh that one might be able to steal. Although it's
 probably grotty, and pkg_comp doesn't really need to be so elaborate.

  >  - but it would probably be
  >  possible to copy in the XAUTHORISATION file and make sure DISPLAY was
  >  set to force a true network connection, and it would probably work.

 That would probably do, yeah.

  >    |  It seems to me that having it clear $DISPLAY is
  >    |  the correct default behavior.
  >  
  >  That's what I'm doing in the version of pkg_comp I'm using now, and
  >  I haven't seen any further problems - but I don't know that I have built
  >  anything that truly requires an X connection to build (if such a thing
  >  exists).

 If we find any, maybe we ought to have pkgsrc infrastructure to
 provide a dummy X server for such packages, so they build
 consistently.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module
 (py25-gtk2 is installed)
Date: Sun, 13 May 2012 07:51:36 +0000

 On Sun, Jan 24, 2010 at 01:55:02AM +0000, David Holland wrote:
  >   >    |  It seems to me that having it clear $DISPLAY is
  >   >    |  the correct default behavior.
  >   >  
  >   >  That's what I'm doing in the version of pkg_comp I'm using now, and
  >   >  I haven't seen any further problems - but I don't know that I have built
  >   >  anything that truly requires an X connection to build (if such a thing
  >   >  exists).
  >  
  >  If we find any, maybe we ought to have pkgsrc infrastructure to
  >  provide a dummy X server for such packages, so they build
  >  consistently.

 At this point I think we can say with confidence (after paying a lot
 more attention to bulk build results over the last couple years) that
 there is exactly one such package in pkgsrc: misc/hanzim. It does some
 index generation at install time that (for no particularly good reason)
 runs behind a tcl/tk event loop.

 It is not worth setting up infrastructure to support that; it would be
 much less trouble to fix the package.

 Should the change to clear DISPLAY in pkg_comp be merged into the
 pkgsrc version of pkg_comp? If so, let's do it; otherwise, I think we
 can close this PR.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/41971: graphics/dia-python cannot find pygtk module (py25-gtk2 is installed)
Date: Mon, 14 May 2012 06:24:36 +0700

     Date:        Sun, 13 May 2012 07:55:02 +0000 (UTC)
     From:        David Holland <dholland-pbugs@NetBSD.org>
     Message-ID:  <20120513075502.CA0B963B86B@www.NetBSD.org>

   |  Should the change to clear DISPLAY in pkg_comp be merged into the
   |  pkgsrc version of pkg_comp?

 I think so, yes.

   | If so, let's do it;

 I can't easily send a diff (other than by making the change again to a
 fresh copy of the sources) - my version has myriad changes, but for this
 one, all I did was add

 	unset DISPLAY

 between the args="$*" line and the beginning of the definition of the
 internal readconf() function.

   | otherwise, I think we can close this PR.

 You can most likely do that anyway.

 kre

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.