Python 3.1 head is reporting failures in test_strptime under OpenIndiana 147. For example http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/3/steps/test/logs/stdio


Python 2.7 and 3.2 heads are working fine.

I have access to the machine, so if somebody want to do some kind of test, just ask.

AssertionError: strftime does not support standard '%d' format (day of month as number (00-31))

Sounds pretty self-explainatory.  I kind of doubt, however, that OpenIndiana's strftime is that broken.  Jesús, can you test it?

OS stock python:

"""
jc@pythonbuildbot.uk.openindiana.org:~$ python
Python 2.6.4 (r264:75706, Sep 12 2010, 18:46:30) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime("%d")
'22'
"""

Buildbots for 2.7 and 3.2 are working nicely. There is something fishy there.

Building 3.1 head, I get:

"""
jc@pythonbuildbot.uk.openindiana.org:/tmp/z/build# export LD_LIBRARY_PATH=/tmp/z/build
jc@pythonbuildbot.uk.openindiana.org:/tmp/z/build# ./python
Python 3.1.3rc1+ (release31-maint:86646, Nov 21 2010, 20:07:38) 
[GCC 4.3.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime("%d")
'%'
"""

That is clearly incorrect. Don't seems to be a problem with OpenIndiana, since 2.7 and 3.2 heads are OK.

I have spend the afternoon doing bisection on the buildslave. The problem was introduced in r73043:

"""
------------------------------------------------------------------------
r73043 | martin.v.loewis | 2009-05-30 08:13:40 +0200 (Sat, 30 May 2009) | 2 lines

Issue #5562: Use wcsftime for time.strftime where available.

------------------------------------------------------------------------
"""

I confirm that 2.7 and 3.x buildbots are green for this particular test.
Only 3.1 is affected, in this particular buildslave.

Martin, could you check it? Thanks!.

> Martin, could you check it? Thanks!.

Not in the foreseeable future, sorry.

I verified that the bug was present too in the py3k patch sometime ago, but not currently. So I have spend some time doing bisection in the py3k branch to know WHEN the problem was solved.

If was solved in r81583:

"""
------------------------------------------------------------------------
r81583 | martin.v.loewis | 2010-05-28 17:44:20 +0200 (Fri, 28 May 2010) | 9 lines

Merged revisions 81582 via svnmerge from 
svn+ssh://pythondev@svn.python.org/python/trunk

........
  r81582 | martin.v.loewis | 2010-05-28 17:28:47 +0200 (Fr, 28 Mai 2010) | 2 lines
  
  Issue #1759169: Drop _XOPEN_SOURCE on Solaris.
........

------------------------------------------------------------------------
"""

The fix was ported from trunk (2.7) to py3k branch, but it was not applied to 3.1 branch, though. I don't know why, but seems to be an oversight.

Since the patch has been "tested" in py3k branch since late May, it is simple and solves the problem in 3.1 branch, I request this patch to be applied to 3.1 too.

Martin, do you have an opinion?.

Must the release manager to be involved?.

PS: I have verified that with the change, the buildslave in OpenIndiana passes the test.

The issue is that we have checks for "SunOS/5.10", but OpenIndiana and the new Solaris 11 Express are "SunOS/5.11". We have to add them.

> The fix was ported from trunk (2.7) to py3k branch, but it was not
> applied to 3.1 branch, though. I don't know why, but seems to be an
> oversight.

No, it was deliberate: it was not backported all, neither to 3.1, nor
to 2.6. I was concerned that doing so may break stuff that currently
works.

> Since the patch has been "tested" in py3k branch since late May, it
> is simple and solves the problem in 3.1 branch, I request this patch
> to be applied to 3.1 too.
> 
> Martin, do you have an opinion?.

I remain skeptical. The test on the 3k branch is irrelevant; the

> Must the release manager to be involved?.

At this point: definitely. After the 3.1.3 release: the test in the
2.7 release may not give significant insight yet.

> The issue is that we have checks for "SunOS/5.10", but OpenIndiana
> and the new Solaris 11 Express are "SunOS/5.11". We have to add
> them.

That is fine.

I have made several experiments to get the minimal patch. It is committed in r86752.

It is trivial enough, and risk-free enough, to commit even in RC state (In my opinion).

Python 2.7 and 3.2 are not affected. They don't look for "SunOS/5.10" in their configure script.

The buildslave is now green. Finally. http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/36