This package fails to compile on an unstable system. Attached relevant logs and emerge --info
Created attachment 708015 [details] emerge_info emerge --info
Created attachment 708018 [details] docutils-0.16-r1:20210513-091152.log build log
Something absurd is going on here * Using python3.9 in global scope * python3_9: running distutils-r1_run_phase python_compile_all python3.9: /var/tmp/notmpfs/portage/media-gfx/freecad-0.19.2/work/FreeCAD-0.19.2/src/Base/BaseClass.cpp:97: static void Base::BaseClass::initSubclass(Base::Type&, const char*, const char*, Base::Type::instantiationMethod): Assertion `parentType != Base::Type::badType()' failed. /var/tmp/portage/dev-python/docutils-0.16-r1/temp/environment: line 3433: 355 Aborted "${EPYTHON}" buildhtml.py --input-encoding=utf-8 --stylesheet-path=../html4css1.css, --traceback ../docs * ERROR: dev-python/docutils-0.16-r1::gentoo
I'm guessing that FreeCAD installs some modules that are loaded magically.
# cat /etc/env.d/99freecad PYTHONPATH=/usr/lib64/freecad/Ext:/usr/lib64/freecad/Mod:/usr/lib64/freecad/lib64
(In reply to Jaak Ristioja from comment #5) > # cat /etc/env.d/99freecad > PYTHONPATH=/usr/lib64/freecad/Ext:/usr/lib64/freecad/Mod:/usr/lib64/freecad/ > lib64 As a workaround you could comment out that line when compiling docutils. For me the problem only occurred during the system update from python3.8 to 3.9.
AFAIK there's no magic module loading of freecad happening. The way 0.19.2 and 9999 are currently build is to install the freecad main module into site-packages, which installs a freecad/__init__.py file, which loads the actual FreeCAD modules. Those reside still in the paths exported by the PYTHONPATH env variable. This way, one can simply 'import freecad' inside a python shell. Is there another way to tell python where so search for python packages / modules? Would unsetting PYTHONPATH in the docutils ebuild help?
I can confirm that this occurs with docutils-17.1, if freecad is installed. Unsetting PYTHONPATH in the shell prior to emerging docutils is a workaround. export PYTHONPATH="" emerge docutils Unsure about the proper fix.
I just tried this in my test chroot, having python-2.7 and python-3.{9,10} installed, with a freecad build against python-3.9 and the issue didn't occur. When I first heard about this, last Friday or Saturday on #gentoo, the user confirmed me, that clearing PYTHONPATH and re-sourcing the environment before installing docutils does build the package. Would it be feasible to add PYTHONPATH to the list of unset variables?
I have the same problem, freecad-9999 installed but the PYTHONPATH variable was not set in the shell where I have issued the emerge command resulting in docutils failure. Nevertheless I get the same problem. # echo $PYTHONPATH #
I just ran into this with docutils-0.17.1 too. Perhaps we can mark this bug as confirmed since it seems to have multiple reports?
FWICS the env.d file was removed from FreeCAD: commit 5927fa068889aa555a1f9657e27305eb11ffae37 Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2022-03-18 10:12:08 +0100 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-03-19 17:14:22 +0100 media-gfx/freecad: drop environment file Setting PYTHONPATH seems no longer be needed and raises incompatibilities with other packages. Is there anything else to do here?
Closing as resolved.
Just wanted to add: I just ran into this bug because I had media-gfx/freecad-0.19.2-r6 installed, had python3_10 installed, and trying to upgrade to docutils-0.19. I ended up tricking portage by renaming the FreeCAD python directories out of the way so it would have no chance of finding them, and then renaming it back after docutils merged. As far as I can tell this is water under the bridge at this point except for those who tried to cross the river before finding the bridge. In my opinion a more proper fix is to have dev-python/docutils ignore PYTHONPATH inside the ebuild when it's being installed, so that it would not get thrown off when trying to read the environment files in. However indeed this is a hack too and whether there are more packages out there that provide broken modules that get loaded by other packages, or whether there is a legitimate reason to set PYTHONPATH before merging a package?
This should happen anymore with current versions of freecad installed. FreeCAD no longer exports the PYTHONPATH variable
(In reply to Bernd from comment #15) > This should happen anymore with current versions of freecad installed. > FreeCAD no longer exports the PYTHONPATH variable This doesn't help people upgrading older systems. I think we could probably add some guard in docutils at least, but it's still merge order dependent :(