Bug 1900512
| Summary: | python-markdown-math fails to build with Python 3.10: AssertionError: '<scr[97 chars]pt>\n\n<script type="math/tex; mode=display">\[38 chars]t>\n' != '<scr[97 chars]pt>\n<script type="math/tex; mode=display">\n [36 chars]t>\n' | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomáš Hrnčiar <thrnciar> |
| Component: | python-markdown-math | Assignee: | José Matos <jamatos> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | jamatos, mhroncok, thrnciar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-01-03 20:50:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1890881 | ||
I reported this issue uptream: https://github.com/mitya57/python-markdown-math/issues/29 According to the project maintainer the issue should be solved in the next stable release. The commit messages hint for the new release soon as the release number is already set in a commit previous to the bug report. OK. I did not had anytia following this project. This is now fixed. Version 0.8 was released in November. After the exchange with upstream author it seems that the error reported here is unrelated with python 3.10. The problem was the tests running against python-markdown 3.3 (that currently only ships on rawhide), the new version 0.8 fixes this issue. I have update python-markdown-math in rawhide to 0.8 and the tests pass. On the other hand the tests fail now on Fedora 33 because it only ships python-markdown 3.2. :-) Since the change is very small I will let Fedora 32 and 33 with version 0.7 unless python-markdown is updated there. |
python-markdown-math fails to build with Python 3.10.0a2. ====================================================================== FAIL: test_standalone_gitlab (__main__.MathTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/python-markdown-math-0.7/test.py", line 17, in <lambda> return lambda self: self.verify(mkd_name, html_name, config=config) File "/builddir/build/BUILD/python-markdown-math-0.7/test.py", line 14, in verify self.assertEqual(html, md.convert(mkd) + '\n') AssertionError: '<scr[97 chars]pt>\n\n<script type="math/tex; mode=display">\[38 chars]t>\n' != '<scr[97 chars]pt>\n<script type="math/tex; mode=display">\n [36 chars]t>\n' <script type="math/tex; mode=display"> e^{i \varphi} = \cos \varphi + i \sin \varphi </script> - <script type="math/tex; mode=display"> \text{one more math block} </script> For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/01773221-python-markdown-math/ For all our attempts to build python-markdown-math with Python 3.10, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/python-markdown-math/ 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.10: https://copr.fedorainfracloud.org/coprs/g/python/python3.10/ Let us know here if you have any questions. Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10. 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.