NetBSD Problem Report #45345
From www@NetBSD.org Thu Sep 8 20:58:18 2011
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id 92E0063BBFF
for <gnats-bugs@gnats.NetBSD.org>; Thu, 8 Sep 2011 20:58:18 +0000 (UTC)
Message-Id: <20110908205817.BA3DD63BB48@www.NetBSD.org>
Date: Thu, 8 Sep 2011 20:58:17 +0000 (UTC)
From: pallegra@gmail.com
Reply-To: pallegra@gmail.com
To: gnats-bugs@NetBSD.org
Subject: lang/python31 wrongly builds pyexpat
X-Send-Pr-Version: www-1.0
>Number: 45345
>Category: pkg
>Synopsis: lang/python31 wrongly builds pyexpat
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: dholland
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Sep 08 21:00:00 +0000 2011
>Closed-Date: Thu Jul 04 05:33:17 +0000 2013
>Last-Modified: Thu Jul 04 05:33:17 +0000 2013
>Originator: Pierre Allegraud
>Release: Current
>Organization:
>Environment:
>Description:
lang/python31 builds pyexpat module (which should be built by textproc/py-expat). This module isn't linked with libexpat.so.
>How-To-Repeat:
>Fix:
Replace "expat" by "pyexpat" in patch-am.
I m using this patch:
Index: lang/python31/PLIST.common
===================================================================
--- lang/python31/PLIST.common
+++ lang/python31/PLIST.common
@@ -1707,11 +1707,10 @@
lib/python${PY_VER_SUFFIX}/lib-dynload/math.so
lib/python${PY_VER_SUFFIX}/lib-dynload/mmap.so
lib/python${PY_VER_SUFFIX}/lib-dynload/nis.so
lib/python${PY_VER_SUFFIX}/lib-dynload/operator.so
lib/python${PY_VER_SUFFIX}/lib-dynload/parser.so
-lib/python${PY_VER_SUFFIX}/lib-dynload/pyexpat.so
lib/python${PY_VER_SUFFIX}/lib-dynload/resource.so
lib/python${PY_VER_SUFFIX}/lib-dynload/select.so
lib/python${PY_VER_SUFFIX}/lib-dynload/syslog.so
lib/python${PY_VER_SUFFIX}/lib-dynload/termios.so
lib/python${PY_VER_SUFFIX}/lib-dynload/time.so
Index: lang/python31/distinfo
===================================================================
--- lang/python31/distinfo
+++ lang/python31/distinfo
@@ -5,11 +5,11 @@
Size (Python-3.1.4.tar.bz2) = 9887870 bytes
SHA1 (patch-aa) = ae156c486007cfd14d378dd211108d3af4b841b1
SHA1 (patch-ab) = 7d4d6aa9239f53f1ce9ecd377890d71557c58ca4
SHA1 (patch-ah) = f93c0aab7b0d5e8e9f80433dda5ed5a22861f6b9
SHA1 (patch-al) = 48e348c64cf54756cf5b10254661ac089bec3e0a
-SHA1 (patch-am) = 7943623eba8aaa0c10ef8c55407045fb2eba5305
+SHA1 (patch-am) = 47d6b7993c1c8e3e203490eb14bf66888f3e39d6
SHA1 (patch-an) = 933acde107b735931d26ace4eef251000b9f07ba
SHA1 (patch-ao) = dca396744edc5c0f86c8912bf54347a630cd865b
SHA1 (patch-au) = a2cefb240d91121315d02104416324c971af6a20
SHA1 (patch-av) = dcbcd47a50b56d1fd8b5e5594b94a155c52d5e39
SHA1 (patch-aw) = 598e4710c426110012048946786a6d72f050e0fc
Index: lang/python31/patches/patch-am
===================================================================
--- lang/python31/patches/patch-am
+++ lang/python31/patches/patch-am
@@ -5,11 +5,11 @@
@@ -17,7 +17,7 @@ from distutils.command.install_lib impor
from distutils.spawn import find_executable
# This global variable is used to hold the list of modules to be disabled.
-disabled_module_list = []
-+disabled_module_list = ["_bsddb", "_curses", "_curses_panel", "_elementtree", "_sqlite3", "_tkinter", "_gdbm", "expat", "readline"]
++disabled_module_list = ["_bsddb", "_curses", "_curses_panel", "_elementtree", "_sqlite3", "_tkinter", "_gdbm", "pyexpat", "readline"]
def add_dir_to_list(dirlist, dir):
"""Add the directory 'dir' to the list 'dirlist' (at the front) if
@@ -362,9 +362,15 @@ class PyBuildExt(build_ext):
os.unlink(tmpfile)
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: pkg-manager->reed
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Thu, 08 Sep 2011 21:21:57 +0000
Responsible-Changed-Why:
Over to importer.
Responsible-Changed-From-To: reed->obache
Responsible-Changed-By: obache@NetBSD.org
Responsible-Changed-When: Sat, 10 Sep 2011 09:31:09 +0000
Responsible-Changed-Why:
I'll take this.
State-Changed-From-To: open->closed
State-Changed-By: obache@NetBSD.org
State-Changed-When: Sat, 10 Sep 2011 11:24:32 +0000
State-Changed-Why:
Committed fixes. Thanks!
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/45345 CVS commit: pkgsrc/lang/python31
Date: Sat, 10 Sep 2011 11:23:13 +0000
Module Name: pkgsrc
Committed By: obache
Date: Sat Sep 10 11:23:13 UTC 2011
Modified Files:
pkgsrc/lang/python31: Makefile PLIST.common distinfo
pkgsrc/lang/python31/patches: patch-am
Log Message:
Fixes disabling pyexpat module.
PR pkg/45345 by Pierre Allegraud.
Bump PKGREVISION.
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 pkgsrc/lang/python31/Makefile
cvs rdiff -u -r1.2 -r1.3 pkgsrc/lang/python31/PLIST.common \
pkgsrc/lang/python31/distinfo
cvs rdiff -u -r1.1.1.1 -r1.2 pkgsrc/lang/python31/patches/patch-am
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Jeremy C. Reed" <reed@reedmedia.net>
To: gnats-bugs@netbsd.org
Cc: pallegra@gmail.com, obache@netbsd.org
Subject: Re: pkg/45345: lang/python31 wrongly builds pyexpat
Date: Thu, 10 Nov 2011 08:02:43 -0600 (CST)
After upgrading python31 on one of my systems, my software began to
fail:
Traceback (most recent call last):
File
"/Local/Users/jreed/opt/pkg/lib/python3.1/xml/etree/ElementTree.py",
line 1103, in __init__
from xml.parsers import expat
File "/Local/Users/jreed/opt/pkg/lib/python3.1/xml/parsers/expat.py",
line 4, in <module>
from pyexpat import *
ImportError: No module named pyexpat
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/b/work/BIND10-systest/20111110114500-MacOS/build/src/bin/stats/tests/b10-stats-httpd_test.py",
line 139, in test_do_GET
root = xml.etree.ElementTree.parse(response).getroot()
File
"/Local/Users/jreed/opt/pkg/lib/python3.1/xml/etree/ElementTree.py",
line 846, in parse
tree.parse(source, parser)
File
"/Local/Users/jreed/opt/pkg/lib/python3.1/xml/etree/ElementTree.py",
line 576, in parse
parser = XMLTreeBuilder()
File
"/Local/Users/jreed/opt/pkg/lib/python3.1/xml/etree/ElementTree.py",
line 1106, in __init__
"No module named expat; use SimpleXMLTreeBuilder instead"
ImportError: No module named expat; use SimpleXMLTreeBuilder instead
Installing py31-expat-0nb5 fixed the problem but is that correct? The
python31 package provided lib/python3.1/xml/etree/ElementTree.py which
used its provided lib/python3.1/xml/parsers/expat.py which required
outside package py31-expat-0nb5 which provides only
lib/python3.1/lib-dynload/pyexpat.so (not other files).
Is it okay for the provided python3.1 modules to require an outside
module?
Then again maybe that is okay since that is the way I have been using
python31's sqlite3 for over a year.
State-Changed-From-To: closed->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 13 Nov 2011 19:13:54 +0000
State-Changed-Why:
That seems wrong.
reopen the PR to make sure what was just posted gets seen...
From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Sun, 13 Nov 2011 22:36:02 +0100
On Sun, Nov 13, 2011 at 07:13:55PM +0000, dholland@NetBSD.org wrote:
> State-Changed-Why:
> That seems wrong.
It isn't. It is the same situation with every other Python package and
short of requiring all the dependencies on the main package, it is
unlikely to get fixed.
Joerg
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Sun, 13 Nov 2011 22:19:36 +0000
On Sun, Nov 13, 2011 at 09:40:04PM +0000, Joerg Sonnenberger wrote:
> From: Joerg Sonnenberger <joerg@britannica.bec.de>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
> Date: Sun, 13 Nov 2011 22:36:02 +0100
>
> On Sun, Nov 13, 2011 at 07:13:55PM +0000, dholland@NetBSD.org wrote:
> > State-Changed-Why:
> > That seems wrong.
>
> It isn't. It is the same situation with every other Python package and
> short of requiring all the dependencies on the main package, it is
> unlikely to get fixed.
Eh?
The base Python package should not depend on modules that are packaged
separately. We explicitly yanked out the expat module (as well as a
few others) to avoid having the base Python package depend on expat
(as well as a few other things), which is generally a good thing.
However, if we're going to do that we ought to do it fully or not at
all. That is, anything in the base Python package that depends on
modules we split out should itself be split out, or we should give up
on trying to split some or all of these things out at all. Otherwise,
things just break in bizarre ways, as per the previous mail.
--
David A. Holland
dholland@netbsd.org
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Mon, 14 Nov 2011 09:50:28 +0900
On Mon, 14 Nov 2011 04:13:55 +0900, <dholland@netbsd.org> wrote:
> That seems wrong.
>
> reopen the PR to make sure what was just posted gets seen...
It's not only for python31, but python2[4-7] also.
Then, what do you want to do about this issue?
1. Merge textproc/py-expat to base python package?
2. Move py-expat related files in base python package to textproc/py-expat?
--
OBATA Akio / obache@NetBSD.org
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Mon, 14 Nov 2011 15:29:59 +0000
On Mon, Nov 14, 2011 at 12:55:02AM +0000, OBATA Akio wrote:
> On Mon, 14 Nov 2011 04:13:55 +0900, <dholland@netbsd.org> wrote:
>
> > That seems wrong.
> >
> > reopen the PR to make sure what was just posted gets seen...
>
> It's not only for python31, but python2[4-7] also.
I thought the disentanglement had already been done for the older
Python versions.
> Then, what do you want to do about this issue?
>
> 1. Merge textproc/py-expat to base python package?
> 2. Move py-expat related files in base python package to textproc/py-expat?
I think it's probably ok in general for Python to depend on expat;
expat is pretty harmless.
The problem I guess is that because expat is builtin on base if and
only if using native X, depending on expat would make the official
binary packages for all Python stuff useless to people using pkgsrc
X. And that's not good.
But in any case I don't think the base Python package should depend on
py-expat being installed. I'm not sure how much work (2) entails; if
it's not a lot, it's cleaner that way, but if it is, it's probably not
worth doing and we should go ahead and adopt (1).
The real fix for the packaging problem is for expat to be in base
base, not base xsrc. People have been suggesting that for a while, but
I'm not sure what the current status is.
Meanwhile I think Jeremy Reed's immediate problem is that
textproc/py-elementtree should depend on py-expat but doesn't.
(When I first saw that mail I thought py-elementtree was part of the
base Python, meaning that doing (2) would require splitting it and
maybe other things into their own packages. But it isn't, and even in
python31 there doesn't seem to be anything else in the base
distribution that depends on expat stuff.)
--
David A. Holland
dholland@netbsd.org
Responsible-Changed-From-To: obache->dholland
Responsible-Changed-By: obache@NetBSD.org
Responsible-Changed-When: Sun, 20 Nov 2011 05:53:29 +0000
Responsible-Changed-Why:
I don't think this issue must be handled.
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Sun, 20 Nov 2011 15:01:25 +0900
On Tue, 15 Nov 2011 00:30:06 +0900, David Holland <dholland-pbugs@netbsd.org> wrote:
> > Then, what do you want to do about this issue?
> >
> > 1. Merge textproc/py-expat to base python package?
> > 2. Move py-expat related files in base python package to textproc/py-expat?
> I think it's probably ok in general for Python to depend on expat;
> expat is pretty harmless.
> The problem I guess is that because expat is builtin on base if and
> only if using native X, depending on expat would make the official
> binary packages for all Python stuff useless to people using pkgsrc
> X. And that's not good.
> But in any case I don't think the base Python package should depend on
> py-expat being installed. I'm not sure how much work (2) entails; if
> it's not a lot, it's cleaner that way, but if it is, it's probably not
> worth doing and we should go ahead and adopt (1).
> The real fix for the packaging problem is for expat to be in base
> base, not base xsrc. People have been suggesting that for a while, but
> I'm not sure what the current status is.
Due to too TEOKURE release cycle of NetBSD, it is not happy using base expat.
> Meanwhile I think Jeremy Reed's immediate problem is that
> textproc/py-elementtree should depend on py-expat but doesn't.
No. py-elementtree package depend on py-xml, and py-xml contains own pyexpat.
> (When I first saw that mail I thought py-elementtree was part of the
> base Python, meaning that doing (2) would require splitting it and
> maybe other things into their own packages. But it isn't, and even in
> python31 there doesn't seem to be anything else in the base
> distribution that depends on expat stuff.)
How do you think about databases/py-sqlite3? it is same situation.
${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
--
OBATA Akio / obache@NetBSD.org
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Mon, 21 Nov 2011 12:43:36 +0000
On Sun, Nov 20, 2011 at 06:05:03AM +0000, OBATA Akio wrote:
> > The real fix for the packaging problem is for expat to be in base
> > base, not base xsrc. People have been suggesting that for a while, but
> > I'm not sure what the current status is.
>
> Due to too TEOKURE release cycle of NetBSD, it is not happy using
> base expat.
?
expat hasn't been updated since long before netbsd-5 shipped.
> > Meanwhile I think Jeremy Reed's immediate problem is that
> > textproc/py-elementtree should depend on py-expat but doesn't.
>
> No. py-elementtree package depend on py-xml, and py-xml contains
> own pyexpat.
...then why is it not working?
> How do you think about databases/py-sqlite3? it is same situation.
> ${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
I think that's wrong too.
However, obviously this is a can of worms and I guess it should be
left alone unless an experienced Python hacker (that is, not me) wants
to take charge of it.
--
David A. Holland
dholland@netbsd.org
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Mon, 21 Nov 2011 22:40:51 +0900
On Mon, 21 Nov 2011 21:45:02 +0900, David Holland <dholland-pbugs@netbsd.org> wrote:
> On Sun, Nov 20, 2011 at 06:05:03AM +0000, OBATA Akio wrote:
> > > The real fix for the packaging problem is for expat to be in base
> > > base, not base xsrc. People have been suggesting that for a while, but
> > > I'm not sure what the current status is.
> >
> > Due to too TEOKURE release cycle of NetBSD, it is not happy using
> > base expat.
> ?
> expat hasn't been updated since long before netbsd-5 shipped.
It's just a lucky.
(for netbsd-4, no releases including fixes for CVE-2009-3560 and CVE-2009-3720 yet)
> > > Meanwhile I think Jeremy Reed's immediate problem is that
> > > textproc/py-elementtree should depend on py-expat but doesn't.
> >
> > No. py-elementtree package depend on py-xml, and py-xml contains
> > own pyexpat.
> ...then why is it not working?
The problem is in builtin etree module, not external elementree module.
> > How do you think about databases/py-sqlite3? it is same situation.
> > ${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
> I think that's wrong too.
Then, this issue should be send to upstream first.
I think that it is the default behavior of python distribution.
--
OBATA Akio / obache@NetBSD.org
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Tue, 29 Nov 2011 02:53:00 +0000
On Mon, Nov 21, 2011 at 01:45:02PM +0000, OBATA Akio wrote:
>>>> The real fix for the packaging problem is for expat to be in base
>>>> base, not base xsrc. People have been suggesting that for a while, but
>>>> I'm not sure what the current status is.
>>>
>>> Due to too TEOKURE release cycle of NetBSD, it is not happy using
>>> base expat.
>> ?
>> expat hasn't been updated since long before netbsd-5 shipped.
>
> It's just a lucky.
> (for netbsd-4, no releases including fixes for CVE-2009-3560 and CVE-2009-3720 yet)
I didn't realize expat was even in netbsd-4's X11... but apparently it
is.
this should be fixed. let's open a fresh PR for it.
> > > > Meanwhile I think Jeremy Reed's immediate problem is that
> > > > textproc/py-elementtree should depend on py-expat but doesn't.
> > >
> > > No. py-elementtree package depend on py-xml, and py-xml contains
> > > own pyexpat.
> > ...then why is it not working?
>
> The problem is in builtin etree module, not external elementree module.
argh, I can never keep all that straight.
>>> How do you think about databases/py-sqlite3? it is same situation.
>>> ${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
>> I think that's wrong too.
>
> Then, this issue should be send to upstream first.
> I think that it is the default behavior of python distribution.
I don't think so. Both py-sqlite3 and py-expat are built out of the
main python distfile. And look at the first hunk of
lang/python26/patches/patch-am, which suppresses the standard build of
those and other builtin modules.
--
David A. Holland
dholland@netbsd.org
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Tue, 29 Nov 2011 15:48:34 +0900
On Tue, 29 Nov 2011 11:55:01 +0900, David Holland <dholland-pbugs@netbsd.org> wrote:
> >> expat hasn't been updated since long before netbsd-5 shipped.
> >
> > It's just a lucky.
> > (for netbsd-4, no releases including fixes for CVE-2009-3560 and CVE-2009-3720 yet)
> I didn't realize expat was even in netbsd-4's X11... but apparently it
> is.
> this should be fixed. let's open a fresh PR for it.
No need to file new PR, just NetBSD-4.0.2 (or 4.1) release is required.
> >>> How do you think about databases/py-sqlite3? it is same situation.
> >>> ${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
> >> I think that's wrong too.
> >
> > Then, this issue should be send to upstream first.
> > I think that it is the default behavior of python distribution.
> I don't think so. Both py-sqlite3 and py-expat are built out of the
> main python distfile. And look at the first hunk of
> lang/python26/patches/patch-am, which suppresses the standard build of
> those and other builtin modules.
It's just exactly disabling to built those modules, or builtin sqlite3 libraries may
be detected (It is not expected behavior).
--
OBATA Akio / obache@NetBSD.org
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Mon, 5 Dec 2011 16:43:12 +0000
On Tue, Nov 29, 2011 at 06:50:04AM +0000, OBATA Akio wrote:
> > >> expat hasn't been updated since long before netbsd-5 shipped.
> > >
> > > It's just a lucky.
> > > (for netbsd-4, no releases including fixes for CVE-2009-3560 and CVE-2009-3720 yet)
> > I didn't realize expat was even in netbsd-4's X11... but apparently it
> > is.
> > this should be fixed. let's open a fresh PR for it.
>
> No need to file new PR, just NetBSD-4.0.2 (or 4.1) release is required.
oh. well, that's not going to happen, as far as I know.
> > >>> How do you think about databases/py-sqlite3? it is same situation.
> > >>> ${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
> > >> I think that's wrong too.
> > >
> > > Then, this issue should be send to upstream first.
> > > I think that it is the default behavior of python distribution.
> > I don't think so. Both py-sqlite3 and py-expat are built out of the
> > main python distfile. And look at the first hunk of
> > lang/python26/patches/patch-am, which suppresses the standard build of
> > those and other builtin modules.
>
> It's just exactly disabling to built those modules, or builtin
> sqlite3 libraries may be detected (It is not expected behavior).
Right. But the reason it does that is that we build the sqlite
material separately in the py-sqlite3 package.
That is, that separation is something we did, not part of the default
behavior of Python. There would be no point contacting upstream.
--
David A. Holland
dholland@netbsd.org
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/45345 (lang/python31 wrongly builds pyexpat)
Date: Tue, 06 Dec 2011 09:55:58 +0900
On Tue, 06 Dec 2011 01:45:01 +0900, David Holland <dholland-pbugs@netbsd.org> wrote:
> > > >>> How do you think about databases/py-sqlite3? it is same situation.
> > > >>> ${PYLIB}/sqlite3/* exists in base python package, but lack of _sqlite3.so.
> > > >> I think that's wrong too.
> > > >
> > > > Then, this issue should be send to upstream first.
> > > > I think that it is the default behavior of python distribution.
> > > I don't think so. Both py-sqlite3 and py-expat are built out of the
> > > main python distfile. And look at the first hunk of
> > > lang/python26/patches/patch-am, which suppresses the standard build of
> > > those and other builtin modules.
> >
> > It's just exactly disabling to built those modules, or builtin
> > sqlite3 libraries may be detected (It is not expected behavior).
> Right. But the reason it does that is that we build the sqlite
> material separately in the py-sqlite3 package.
> That is, that separation is something we did, not part of the default
> behavior of Python. There would be no point contacting upstream.
No.
Your question point is that *.py files depending on expat and sqlite3 modules
will be installed even if those modules are not installed (disabled or depending
libraries are not found).
It is the default behavior and you can do change request to upstream.
--
OBATA Akio / obache@NetBSD.org
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 04 Jul 2013 05:33:17 +0000
State-Changed-Why:
The remaining real problem here was fixed by obache in 2012. The python
packaging stuff is tilting at windmills and probably best dropped.
>Unformatted:
(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.
Home