Created attachment 790268 [details] notmuch-0.34.2-r1.ebuild.diff On transition from python3.9 to 3.10 notmuch fails to build when sphinx has not been rebuild yet. The attached diff should fix this (Thanks Sam!)
ack, but not sure if it's 100% correct. sphinx is called by makefile and matching python compat does not matter at all. all it needs is working sphinx. but seems here interpreter is set-up with newer python, while sphinx is not rebuilt yet, so it fails with EPYTHON=python3.10 which is set by python_setup at the top of src_compile. notmuch is a bit of a mess of everything, it can use distutils, python-any and those can have different requirements. let me check twice before I commit. matching compat approach will work ofc, but it does not make it correct =)
(In reply to Georgy Yakovlev from comment #1) > ack, but not sure if it's 100% correct. > sphinx is called by makefile and matching python compat does not matter at > all. all it needs is working sphinx. > > but seems here interpreter is set-up with newer python, while sphinx is not > rebuilt yet, so it fails with EPYTHON=python3.10 which is set by > python_setup at the top of src_compile. It must match the Python chosen by python_setup, and the way to do that is using python_check_deps (and gen_any_dep). It does not have to match the Python implementations used in the ebuild, that's why we're not doing a straight [${PYTHON_USEDEP}] in BDEPEND. Having _just_ dev-python/sphinx, on the other hand, like it is now, is too light, and it means the chosen Python for global scope stuff doesn't need to have a working Sphinx. The original suggestion was to do that, which would work, but would be excessive. (Compare with distutils_enable_sphinx in distutils-r1.eclass). > > notmuch is a bit of a mess of everything, it can use distutils, python-any > and those can have different requirements. exactly. That's what it does.
(In reply to Sam James from comment #2) > (In reply to Georgy Yakovlev from comment #1) > > ack, but not sure if it's 100% correct. > > sphinx is called by makefile and matching python compat does not matter at > > all. all it needs is working sphinx. > > > > but seems here interpreter is set-up with newer python, while sphinx is not > > rebuilt yet, so it fails with EPYTHON=python3.10 which is set by > > python_setup at the top of src_compile. > > It must match the Python chosen by python_setup, and the way to do that is > using python_check_deps (and gen_any_dep). > > It does not have to match the Python implementations used in the ebuild, > that's why we're not doing a straight [${PYTHON_USEDEP}] in BDEPEND. > > Having _just_ dev-python/sphinx, on the other hand, like it is now, is too > light, and it means the chosen Python for global scope stuff doesn't need to > have a working Sphinx. By the way, you can see it working (with the patch) with the nice python_setup/python_check_deps output in configure now: >>> Configuring source in /var/tmp/portage/net-mail/notmuch-0.34.2-r1/work/notmuch-0.34.2 ... * Checking whether python3_10 is suitable ... * >=dev-lang/python-3.10.4:3.10 ... [ ok ] * python_check_deps ... * dev-python/sphinx[python_targets_python3_10(-)] ... [ ok ] * Using python3.10 in global scope
oh, I get your point now -- I'm wondering if it's because we call python_setup, it ends up trying to find a sphinx for that python, but if we didn't call it at all, it'd Just Work?
I think yes, it will call sphinx, python-exec will call it from available impls (which should be 3.9 for this scenario)
Any news on this one? I think any solution is better than the current state...
(In reply to Marc Schiffbauer from comment #6) > Any news on this one? I think any solution is better than the current > state... Thinking about it again, it sounds like we're trying to have it both ways. Either we need python_setup in the ebuild because it actually tries to import sphinx or something (then we need check_deps), or we don't need it at all and we can simply BDEPEND on it. And it does try to actually import Sphinx, at least for a configure test: https://github.com/notmuch/notmuch/blob/master/configure#L935. Let's just add check_deps and move on.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8e4a0100e36949f4c4887f00f7dd438dd5a1be75 commit 8e4a0100e36949f4c4887f00f7dd438dd5a1be75 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-08-23 05:28:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-23 05:28:12 +0000 net-mail/notmuch: use python_check_deps for Sphinx The configure script tries to import Sphinx so we need Sphinx to be installed for the same Python. Either we need python_setup in the ebuild because it actually tries to import sphinx or something (then we need check_deps), or we don't need it at all and we can simply BDEPEND on it. And it does try to actually import Sphinx, at least for a configure test: https://github.com/notmuch/notmuch/blob/master/configure#L935. Closes: https://bugs.gentoo.org/856628 Signed-off-by: Sam James <sam@gentoo.org> net-mail/notmuch/notmuch-0.34.2-r1.ebuild | 306 ++++++++++++++++++++++++++++++ 1 file changed, 306 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07fd9cde32eb83dd60c1b69a34dbacf114b5271e commit 07fd9cde32eb83dd60c1b69a34dbacf114b5271e Author: Sam James <sam@gentoo.org> AuthorDate: 2022-08-23 18:27:38 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-23 18:34:13 +0000 net-mail/notmuch: fix Sphinx dep python_check_deps doesn't do anything w/ distutils-r1, so we settle for the slight over-dep (note that the configure script imports, so we need the [${PYTHON_USEDEP}]) Bug: https://bugs.gentoo.org/856628 Closes: https://bugs.gentoo.org/866117 Fixes: 8e4a0100e36949f4c4887f00f7dd438dd5a1be75 Signed-off-by: Sam James <sam@gentoo.org> net-mail/notmuch/notmuch-0.34.2-r1.ebuild | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
