I'm blind:

http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/

Hey, as you've noticed we already have that COPR repo and even a Koji side tag [0], I'll be sending a mail to fedora/python devel about all that today, hang tight! :)

Matt

[0] https://fedorahosted.org/rel-eng/ticket/5884

I see that your koji build is hanging in the same place mine are :(.  I wonder what is different between the koji builders and the copr builders in this regard.  I can't reproduce locally either.

Created attachment 886645 [details]
strace of hanging test_subprocess_send_signal

It's hanging in the new asyncio tests - specifically test_subprocess_send_signal in test_asyncio/test_events.py.  Attached a relevant strace, looks like the parent process is stuck in epoll_wait().  Could this be caused by older kernels on the koji builders?

Filed upstream.

Looks like in the koji builds, the SIGHUP sigaction is set to SIG_IGN, which causes the processes that the python tests are trying to kill with SIGHUP not to die.  Perhaps the koji builders should not be doing that, perhaps the python tests should reset the SIGHUP sigaction to SIG_DFL.

(In reply to Orion Poplawski from comment #6)
> Looks like in the koji builds, the SIGHUP sigaction is set to SIG_IGN, which
> causes the processes that the python tests are trying to kill with SIGHUP
> not to die.  Perhaps the koji builders should not be doing that, perhaps the
> python tests should reset the SIGHUP sigaction to SIG_DFL.

We have had a similar problem within pexpect. The workaround is to redefine the correct SIGHUB behavior:
https://github.com/pexpect/pexpect/commit/1fbfddf33d196fd1f211fb95efdaa810b8b5dad3

Interesting! I have also some strange builds, which pass in koji, but not in Copr.

(In reply to Orion Poplawski from comment #3)
> I see that your koji build is hanging in the same place mine are :(.  I
> wonder what is different between the koji builders and the copr builders in
> this regard.  I can't reproduce locally either.

Yup, I initially thought this is a different bug I already had a workaround for :(

I figured this would be related to SIGHUP, since when you disable the test_subprocess_kill, the test suite still fails with

======================================================================
FAIL: test_send_signal (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.4.0/Lib/test/test_asyncio/test_subprocess.py", line 118, in test_send_signal
    self.assertEqual(-signal.SIGHUP, returncode)
AssertionError: -1 != 0

Looking at the Koji repo, in koji/__init__.py there's the following:

def daemonize():
    [...]
    signal.signal(signal.SIGHUP, signal.SIG_IGN)
    [...]

Signal dispositions are inherited by child processes [0], but but Koji never seems to change SIGHUP back to SIG_DFL. Methinks this is a bug in Koji, right?

[0] http://man7.org/linux/man-pages/man2/sigaction.2.html#NOTES

When having the problems with pexpect, I opened a ticked for koji:
https://fedorahosted.org/koji/ticket/270

Maybe opening a bug here at bugzilla would be a better option?

(In reply to Thomas Spura from comment #11)
> When having the problems with pexpect, I opened a ticked for koji:
> https://fedorahosted.org/koji/ticket/270
> 
> Maybe opening a bug here at bugzilla would be a better option?

I imagine so, I'll do it.

Seeing as resolving rhbz#1088233/pybt#21247 is probably going to take a while and since COPR and local builds are just fine, I'm going to go for the simplest solution: disable the affected tests for now and build without them.

Sounds good to me.

It looks like ensurepip doesn't function at all if pip isn't already installed into the system. It fails with:

[root@test ~]# python3 -m ensurepip
Traceback (most recent call last):
  File "/usr/lib64/python3.4/runpy.py", line 171, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.4/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib64/python3.4/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/usr/lib64/python3.4/ensurepip/__init__.py", line 233, in _main
    default_pip=args.default_pip,
  File "/usr/lib64/python3.4/ensurepip/__init__.py", line 97, in bootstrap
    dep_records = rewheel.find_system_records([p[0] for p in _PROJECTS])
  File "/usr/lib64/python3.4/ensurepip/rewheel/__init__.py", line 51, in find_system_records
    records.append(os.path.join(path, 'RECORD'))
  File "/usr/lib64/python3.4/posixpath.py", line 83, in join
    path += b
TypeError: unsupported operand type(s) for +=: 'NoneType' and 'str'

Yes, you're right, I forgot to add pip and setuptools to Requires. Thanks for letting me know. :)

(In reply to Donald Stufft from comment #15)
> It looks like ensurepip doesn't function at all if pip isn't already
> installed into the system. It fails with:
> 
> [root@test ~]# python3 -m ensurepip
> Traceback (most recent call last):
>   File "/usr/lib64/python3.4/runpy.py", line 171, in _run_module_as_main
>     "__main__", mod_spec)
>   File "/usr/lib64/python3.4/runpy.py", line 86, in _run_code
>     exec(code, run_globals)
>   File "/usr/lib64/python3.4/ensurepip/__main__.py", line 4, in <module>
>     ensurepip._main()
>   File "/usr/lib64/python3.4/ensurepip/__init__.py", line 233, in _main
>     default_pip=args.default_pip,
>   File "/usr/lib64/python3.4/ensurepip/__init__.py", line 97, in bootstrap
>     dep_records = rewheel.find_system_records([p[0] for p in _PROJECTS])
>   File "/usr/lib64/python3.4/ensurepip/rewheel/__init__.py", line 51, in
> find_system_records
>     records.append(os.path.join(path, 'RECORD'))
>   File "/usr/lib64/python3.4/posixpath.py", line 83, in join
>     path += b
> TypeError: unsupported operand type(s) for +=: 'NoneType' and 'str'

*** Bug 1095069 has been marked as a duplicate of this bug. ***

Python3.4 has landed on Rawhide repos.
Shouldn't this be closed?

(In reply to Onyeibo from comment #18)
> Python3.4 has landed on Rawhide repos.
> Shouldn't this be closed?

It should. :)