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: Fri May 12 09:55:01 +0000 2023
>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
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: Fri, 12 May 2023 07:39:04 +0000
On Sun, May 13, 2012 at 11:25:02PM +0000, Robert Elz wrote:
> | 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.
Neither of these landmarks exists in the current pkg_comp, nor does it
appear to unset anything else so there isn't an obvious place to put
it.
> | otherwise, I think we can close this PR.
>
> You can most likely do that anyway.
Eh, it should get fixed... one of these years...
--
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: Fri, 12 May 2023 16:52:50 +0700
Date: Fri, 12 May 2023 07:40:02 +0000 (UTC)
From: David Holland <dholland-pbugs@netbsd.org>
Message-ID: <20230512074002.2B8431A923C@mollari.NetBSD.org>
| Neither of these landmarks exists in the current pkg_comp, nor does it
| appear to unset anything else so there isn't an obvious place to put
| it.
What was pkg_comp back then is pkg_comp1 now, and that still retains
the landmarks.
What pkg_comp (the new one) does I have no idea, never used that version,
and I'm unlikely ever to, packages that unilaterally install stuff in
root's crontab are not what I want installed on my system.
kre
(Contact us)
$NetBSD: gnats-precook-prs,v 1.4 2018/12/21 14:20:20 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.