Both debian ia64 and PPC are failing the mp test suite with the 
following error:

Re-running test 'test_multiprocessing' in verbose mode
test test_multiprocessing crashed -- <type 'exceptions.OSError'>: [Errno 
38] Function not implemented
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 554, in runtest_inner
    indirect_test()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/test/test_multiprocessing.py", line 1764, in test_main
    ProcessesMixin.pool = multiprocessing.Pool(4)
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/__init__.py", line 226, in Pool
    return Pool(processes, initializer, initargs)
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/pool.py", line 84, in __init__
    self._setup_queues()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/pool.py", line 131, in _setup_queues
    self._inqueue = SimpleQueue()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/queues.py", line 315, in __init__
    self._rlock = Lock()
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/synchronize.py", line 106, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1)
  File "/home/pybot/buildarea/trunk.klose-debian-
ppc/build/Lib/multiprocessing/synchronize.py", line 38, in __init__
    sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
OSError: [Errno 38] Function not implemented
[674193 refs]
make: *** [buildbottest] Error 1
program finished with exit code 2

Buildbots:
http://www.python.org/dev/buildbot/stable/ppc%20Debian%20unstable%20trun
k/builds/1607/step-test/0
http://www.python.org/dev/buildbot/stable/ia64%20Ubuntu%20trunk/builds/1
89/step-test/0

Sorry, should have been debian PPC and ubuntu ia64

This is also effecting gentoo x86. After speaking with Richard, he 
suggested that this could be a side-effect if the buildbot execution is 
happening in a chroot'ed environment.

Barry, do you know if this is the case?

I believe this is a Linux-specific problem relating to chroot jails 
missing the /dev/shm filesystem. 

I am suggesting we skip the test for now if /dev/shm does not exist, 
via:

if (sys.platform.startswith("linux"):
    if not os.path.exists("/dev/shm"):
        raise TestSkipped("Missing required /dev/shm device on Linux!")

at the top of test_multiprocessing.py

Anyone see a problem with this?

I don't see a problem with skipping it, but if chroot is the problem,
maybe the chroot environment should be fixed to include /dev/shm?

I agree, fixing the chroot is the long-term solution, however this gets us 
over the beta hump

I agree with your agreement.

Jesse, I say go ahead and make it so. I think you should make another
report thought to keep track of getting /dev/shm in the buildbot
enviroment. (Is that a buildbot bug?)

I committed the skip in r64356. Let's sit back and watch.

Did  you add the import and fix the syntax error

On Jun 17, 2008, at 6:44 PM, Benjamin Peterson  
<report@bugs.python.org> wrote:

>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> I committed the skip in r64356. Let's sit back and watch.
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3111>
> _______________________________________

1 for 2. :)

I apologize, I should have just posted the diff

On Jun 17, 2008, at 7:00 PM, Benjamin Peterson  
<report@bugs.python.org> wrote:

>
> Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
> 1 for 2. :)
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3111>
> _______________________________________

On Tue, Jun 17, 2008 at 6:08 PM, Jesse Noller <report@bugs.python.org> wrote:
>
> Jesse Noller <jnoller@gmail.com> added the comment:
>
> I apologize, I should have just posted the diff

It's not your fault. I'm impatient.

I switched to a more aggressive skip as it doesn't seem /dev/shm is the culprit (at least from overnight runs). I committed it in r64375 on trunk 
and I am going to wait for the build bots to run on trunk before merging.

> "as it doesn't seem /dev/shm is the culprit"

Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot)
environment, so for me it actually was the culprit. Perhaps you should
recheck your buildbots?

Setting this to a release blocker, because it is affecting Neal's
automated execution of the regression test suite with a debug build.

Scratch that - it's more likely to be Neal's setup which is at fault,
which I will be questioning on python-dev shortly (there are 3 other
tests which are failing/getting skipped in Neal's regression test suite)

Can this be closed as it looks to me like a 2 year old test error and not an extension module error, am I correct?  Refer to msg68349 and msg68363.

As no one is able to confirm that this is still an issue, I'm closing it. It can be reopened if necessary.

Doing cleanup:  This was marked as out of date in 2010 but somehow escaped being marked closed.  Closing now.