Re: [Pgbuildfarm] buildfarm olinguito vs python
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.
In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?
Thanks for any and all pointers.
Davin
----- Forwarded message from "Davin M. Potts" <davin@discontinuity.net> -----
Date: Mon, 25 May 2015 11:12:53 -0500
From: "Davin M. Potts" <davin@discontinuity.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, "pgbuildfarm@lists.commandprompt.com"
<pgbuildfarm@lists.commandprompt.com>
Subject: Re: [Pgbuildfarm] buildfarm olinguito vs python
I have rebuilt python to ensure that the relatively new dependency on
the shared-lib is satisfied. This addresses the previous error that
terminated the configure step with the complaint that the shared-lib was
not found.
However, a new complaint is now encountered, complaining that
"threaded Python not supported on this platform" despite the configure
successfully verifying that Python was indeed compiled with thread
support. Looking in python.m4, I see specifically:
---------------
# threaded python is not supported on OpenBSD
AC_MSG_CHECKING(whether Python is compiled with thread support)
pythreads=`${PYTHON} -c "import sys; print(int('thread' in
sys.builtin_module_na
mes))"`
if test "$pythreads" = "1"; then
AC_MSG_RESULT(yes)
case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
---------------
Looking at the history on python.m4, this has been present for quite a
while, originating back to Bruce Momjian's commits from 2005.
I was convinced that I was able to successfully use the PL/Python
interface on OpenBSD in the past though admittedly I've exclusively
been doing so on other platforms in recent years.
The nature of the errors that were seen back in 2005/2006 are not easily
found. Can somebody point me in the right direction? Or have folks
like Peter Eisentraut tested this recently to verify that the problem
persists with modern builds of Python on OpenBSD? (I can always disable
this test in the configure to see it build but it might not prove much
if I don't try to provoke the previously seen issues.)
Davin
On Tue, May 19, 2015 at 10:55:40AM -0300, Alvaro Herrera wrote:
Davin M. Potts wrote:
It may help to understand that olinguito uses the same build of python
(same directory) for happily building all the REL9_X branches and only
HEAD seems to have this problem. I have tried cleaning everything (not
just cache but blowing away the directories and doing a clean git pull
with new, fresh directories) but HEAD's problems persist. If you look
back in the history, HEAD used to build happily on this system with this
python build. This seems to support the idea that we are looking at a
regression.It's a deliberate change, not a regression. See here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d664a10f9623fd2198b257e513bce849d439a773--
�lvaro Herrera http://www.twitter.com/alvherre
----- End forwarded message -----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/25/2015 12:38 PM, Davin M. Potts wrote:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?Thanks for any and all pointers.
I'm inclined just to remove this in config/python.m4 and see what happens:
case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
;;
esac
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Davin M. Potts wrote:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?
/messages/by-id/20061015211642.GF381@nasby.net
/messages/by-id/42F0D5B1.2060601@dunslane.net
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/25/2015 03:35 PM, Andrew Dunstan wrote:
On 05/25/2015 12:38 PM, Davin M. Potts wrote:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?Thanks for any and all pointers.
I'm inclined just to remove this in config/python.m4 and see what
happens:case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
;;
esac
Oh, I see see what's happening, kinda. Is your threaded python linked
against libc or libc_r?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Davin M. Potts" <davin@discontinuity.net> writes:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.
In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?
I'm fairly sure that the errors were blatantly obvious, ie failure to
build or failure to pass even basic regression tests. If you can tell
us that that configure check is inappropriate on modern openbsd, I'd
be happy to see it go.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 25, 2015 at 04:37:11PM -0400, Tom Lane wrote:
"Davin M. Potts" <davin@discontinuity.net> writes:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?I'm fairly sure that the errors were blatantly obvious, ie failure to
build or failure to pass even basic regression tests. If you can tell
us that that configure check is inappropriate on modern openbsd, I'd
be happy to see it go.
With Tom's bit of encouragement, I removed these four lines from the
config/python.m4 file:
case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
;;
esac
Though in truth, I did take the shortcut of not actually regenerating
the configure file from it and instead I simply commented out those same
exact four lines from the configure and did a proper clean build of HEAD.
The net result is that everything passed from configure through check and
the contrib checks too -- to the extent that we have tests for PL/Python,
all of those tests pass with Python 2.7.10 on OpenBSD (olinguito in the
buildfarm).
To verify that I hadn't done something boneheaded, I manually connected
with psql and did a couple of "CREATE FUNCTION ... LANGUAGE plpythonu;"
and exercised those new functions successfully.
PL/Python appears happy and healthy on OpenBSD, as best as I can tell
from the test suites passing and my own manual poking. I suggest those
four lines specific to OpenBSD can be removed from the configure check.
Though I have only verified this against HEAD, if this change is made
across all the active branches, we will see its impact on olinguito's
buildfarm-builds of those branches too. Or, I can walk through and
manually test each branch if that's preferred?
Davin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 25, 2015 at 04:35:11PM -0300, Alvaro Herrera wrote:
Davin M. Potts wrote:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?/messages/by-id/20061015211642.GF381@nasby.net
/messages/by-id/42F0D5B1.2060601@dunslane.net
Slightly ironic is that at the moment I received this email from �lvaro,
I was sitting across from Jim Nasby (see first link) in a coffeeshop.
Davin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 25, 2015 at 04:26:02PM -0400, Andrew Dunstan wrote:
On 05/25/2015 03:35 PM, Andrew Dunstan wrote:
On 05/25/2015 12:38 PM, Davin M. Potts wrote:
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?Thanks for any and all pointers.
I'm inclined just to remove this in config/python.m4 and see what
happens:case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
;;
esacOh, I see see what's happening, kinda. Is your threaded python
linked against libc or libc_r?
It's built against libc -- I don't think we have libc_r on OpenBSD or if
it used to be there, it looks to be gone now.
Davin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Davin M. Potts" <davin@discontinuity.net> writes:
On Mon, May 25, 2015 at 04:37:11PM -0400, Tom Lane wrote:
I'm fairly sure that the errors were blatantly obvious, ie failure to
build or failure to pass even basic regression tests. If you can tell
us that that configure check is inappropriate on modern openbsd, I'd
be happy to see it go.
With Tom's bit of encouragement, I removed these four lines from the
config/python.m4 file:
case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
;;
esac
[ and it worked ]
Cool.
Though I have only verified this against HEAD, if this change is made
across all the active branches, we will see its impact on olinguito's
buildfarm-builds of those branches too. Or, I can walk through and
manually test each branch if that's preferred?
I see no need for that; as you say, if it's somehow broken in a back
branch the buildfarm will soon tell us. I will go remove that configure
check.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers