python-pexpect fails to build with Python 3.9.0a5. =================================== FAILURES =================================== _________________ InteractTestCase.test_interact_exit_unicode __________________ self = <tests.test_interact.InteractTestCase testMethod=test_interact_exit_unicode> def test_interact_exit_unicode(self): " Ensure subprocess receives utf8. " p = pexpect.spawnu('{self.interact_py} --utf8'.format(self=self), timeout=5, env=self.env) p.expect('READY') p.send('É‘') # >>> map(ord, u'É‘'.encode('utf8')) p.expect('201<STOP>') # [201, 145] p.expect('145<STOP>') p.send('Î’') # >>> map(ord, u'Î’'.encode('utf8')) p.expect('206<STOP>') # [206, 146] p.expect('146<STOP>') p.send('\x00') if not os.environ.get('TRAVIS', None): # on Travis-CI, we sometimes miss trailing stdout from the # chain of child processes, not entirely sure why. So this # is skipped on such systems. > p.expect('0<STOP>') tests/test_interact.py:91: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ pexpect/spawnbase.py:343: in expect return self.expect_list(compiled_pattern_list, pexpect/spawnbase.py:372: in expect_list return exp.expect_loop(timeout) pexpect/expect.py:179: in expect_loop return self.eof(e) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <pexpect.expect.Expecter object at 0x7f19e4e8ea30> err = EOF('End Of File (EOF). Exception style platform.') def eof(self, err=None): spawn = self.spawn spawn.before = spawn._before.getvalue() spawn._buffer = spawn.buffer_type() spawn._before = spawn.buffer_type() spawn.after = EOF index = self.searcher.eof_index if index >= 0: spawn.match = EOF spawn.match_index = index return index else: spawn.match = None spawn.match_index = None msg = str(spawn) msg += '\nsearcher: %s' % self.searcher if err is not None: msg = str(err) + '\n' + msg exc = EOF(msg) exc.__cause__ = None # in Python 3.x we can use "raise exc from None" > raise exc E pexpect.exceptions.EOF: End Of File (EOF). Exception style platform. E <pexpect.pty_spawn.spawn object at 0x7f19e4e8e460> E command: /usr/bin/python3 E args: [b'/usr/bin/python3', b'interact.py', b'--utf8'] E buffer (last 100 chars): '' E before (last 100 chars): '\r\nEscaped interact\r\n' E after: <class 'pexpect.exceptions.EOF'> E match: None E match_index: None E exitstatus: None E flag_eof: True E pid: 348 E child_fd: 16 E closed: False E timeout: 5 E delimiter: <class 'pexpect.exceptions.EOF'> E logfile: None E logfile_read: None E logfile_send: None E maxread: 2000 E ignorecase: False E searchwindowsize: None E delaybeforesend: 0.05 E delayafterclose: 0.1 E delayafterterminate: 0.1 E searcher: searcher_re: E 0: re.compile('0<STOP>') pexpect/expect.py:122: EOF ----------------------------- Captured stdout call ----------------------------- tests.test_interact.InteractTestCase.test_interact_exit_unicode For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01330118-python-pexpect/ For all our attempts to build python-pexpect with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/python-pexpect/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
This does not fail in another Copr with Python 3.8, so I have ruled out a Copr related issue. Setting the severity to high. This package is part of the initial bootstrap sequence. Without it, we cannot proceed with the Python 3.9 bootstrap in a Koji side tag. https://fedoraproject.org/wiki/Changes/Python3.9#Important_dates_and_plan The current plan is to follow the "ideal point when we can start rebuilding in Koji" -- that is we need to get this bug fixed approximately in 1 month and 1 week. That includes potential uncovered bugs in packages that depend on this one. Please acknowledge that you have read this message and that you can dedicate time to fix it. If you know already that you won't be able to fix it by the deadline, please let us know ASAP, so we can allocate resources to do that. Thank You.
> For all our attempts to build python-pexpect with Python 3.9, see: > https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/python-pexpect/ The successful build (version 4.8.0-1.fc33) is with tests disabled.
Since I broke this, I'll fix it. :)
This should be fixed, I think. Appears to have been a COPR issue rather than something to do with Python 3.9.
(In reply to Miro Hrončok from comment #1) > This does not fail in another Copr with Python 3.8, so I have ruled out a > Copr related issue. (In reply to Scott Talbert from comment #4) > This should be fixed, I think. Appears to have been a COPR issue rather > than something to do with Python 3.9. Curiouser and curiouser :D Anyway, hope that setting that TRAVIS env won't come back and bite you. Thanks for the fix!
(In reply to Miro Hrončok from comment #5) > (In reply to Miro Hrončok from comment #1) > > This does not fail in another Copr with Python 3.8, so I have ruled out a > > Copr related issue. > > (In reply to Scott Talbert from comment #4) > > This should be fixed, I think. Appears to have been a COPR issue rather > > than something to do with Python 3.9. I know, but it failed for me in a newly created rawhide COPR, so <shrug> > Anyway, hope that setting that TRAVIS env won't come back and bite you. I think it should be okay. Those tests are evidently flaky on travis too (likely for the same reason) so that's how upstream is filtering them out.
As long as upstream keeps using TRAVIS to skip stuff, we are good. The kick I had in mind is when it starts doing other things as well. But well, if that ever happens, we'll change it, so there is no real issue here.
(In reply to Miro Hrončok from comment #7) > As long as upstream keeps using TRAVIS to skip stuff, we are good. The kick > I had in mind is when it starts doing other things as well. But well, if > that ever happens, we'll change it, so there is no real issue here. Yep. Or they decide to switch to CircleCI or some other CI service... But yeah this is probably good enough for now.