Bug 1631922

Hello Artem,

Would you start blender from the terminal and post the verbose message?

Created attachment 1486621 [details]
blender startup log

Sure. How could i can forget about this. I attached startup log https://bugzilla.redhat.com/attachment.cgi?id=1486621

Something with Python probably.

Additional info if this could help: i am using nvidia-396.54-1.fc29.x86_64 driver from RPM Fusion.

(In reply to Artem from comment #3)
...
> Additional info if this could help: i am using nvidia-396.54-1.fc29.x86_64
> driver from RPM Fusion.
I'm not reproducing with nvidia drivers.

Have you made a particular action, can you retry from a clean blender profile ? (using a new account)?

(In reply to Nicolas Chauvet (kwizart) from comment #4)

> Have you made a particular action, can you retry from a clean blender
> profile ? (using a new account)?

Tried with new clean Blender profile - same issue.

I should reproduce on f29, It was on f28...

(In reply to Nicolas Chauvet (kwizart) from comment #6)
> I should reproduce on f29, It was on f28...

My Blender on F28 was ok without this issue too. And after upgrade F28 to F29 i got this.

It appears python 3.7 is currently incompatible with Blender 2.79a hence the traceback. https://blender.stackexchange.com/questions/115718/blender-as-python-module-link-to-the-correct-pythonxx-dll

Possible workaround is to rebuild against python36 for the time being. I will work on it.

Marcel, could you please look at this?

AFAIK you are highly qualified for both Blender and Python 3.7.

Thank you very much.

I am currently quite busy.
If nobody who'd like to take this on himself shows up in a few days, I'll investigate this issue and try to bring up some solution.

I was able to get quite far, but I have problems getting to the problem itself.
This will bring you to the point just before the first attribute error:

---------------
$ gdb blender
(gdb) br bpy_rna.c:7416
(gdb) r
---------------

What is failing here:
Blender initializes the python _bpy module (seemingly) without any problems. It then imports the public bpy module (python layer) as a sanity check.
This import triggers registration of python-ized blender types. The registration fails because it expects the type to have some attribute it doesn't have.
This is very hard to debug because something fails silently here and the registrations are scattered all over the code.

My suggestions what is going on:
*SOMEWHERE* in the code, some incompatibility occurs and
1. ... mangles flag that states if the attribute is optional.
2. ... mangles attribute that is being looked up.
3. Something totally different.

I suggest working with upstream, because this problem requires good knowledge of both python and blender internals.

I need to pay attention to other matters now.
I'll hopefully be able to get back to this soon.

Just got a result on Blender development:
https://developer.blender.org/search/query/uuadOfAnF6Df/#R

and found 
https://developer.blender.org/rB1db47a2ccd1e68994bf8140eba6cc2a26a2bc91f

That commit has "TODO(campbell): Use Python3.7x _PyObject_LookupAttr()"

I hope the upstream developer is aware that this is private, experimental API, which might be removed (or worse, change semantics) at any time.
It was added to Python here: https://github.com/python/cpython/pull/5222

I don't quite understand what the Blender code does. It would be useful to (get the Blender dev) summarize the problem _PyObject_LookupAttr would solve, so maybe it (or an even better API) can be bade public in Python 3.8.

I agree that private functions should not be used in 3rd party code. The Blender code was already wrong, it's just that Python 3.7 became more strict and so Blender has to be fixed: call PyErr_Clear() to not "leak" an exception since the exception wasn't handled properly.

Filed bug on https://developer.blender.org/T56969

Blender upstream says "The Blender 2.79b release was built with Python 3.5.3. There is no expectation that it runs with Python 3.7.". Maybe we need to explain:

 * that we build Blender in Fedora and not use prebuilt binaries
 * that Fedora updated Python to 3.7 and we rebuilt all stuff

Chances are upstream is not aware of how things work in Fedora.

Chances also are that upstream is not yet interested in Python 3.7 support and in that case we might need to deal with this alone. However other distros might be interested as well. CCing Matěj Cepl from openSUSE.

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

(In reply to Miro Hrončok from comment #16)
> Chances also are that upstream is not yet interested in Python 3.7 support
> and in that case we might need to deal with this alone. However other
> distros might be interested as well. CCing Matěj Cepl from openSUSE.

Fortunately, Blender upstream is investigating their codes due to the reveal from #14.

(In reply to Luya Tshimbalanga from comment #18)
> Fortunately, Blender upstream is investigating their codes due to the reveal
> from #14.

Does anybody have any idea for a possible workaround for the time being, apart downloading and using the prebuild binaries from Blender foundation? 

It does not look we can rely on a swift solution upstream (that "normal priority" assigned and the lack of any update of feedback ever since October the 12th do not look very promising) and Fedora Blender package is essentially unusable despite F29 Final being released a couple of days ago. 

I would gladly help but, sadly, I am afraid I lack the (python) skills and knowledge to be ever remotely helpful.

Another workaround is flatpak https://flathub.org/apps/details/org.blender.Blender

For an immediate fix, apply the patch from https://developer.blender.org/rB1db47a2ccd1e68994bf8140eba6cc2a26a2bc91f

I've made a pull request for f29 here: https://src.fedoraproject.org/rpms/blender/pull-request/2

(In reply to Petr Viktorin from comment #21)
> For an immediate fix, apply the patch from
> https://developer.blender.org/rB1db47a2ccd1e68994bf8140eba6cc2a26a2bc91f
> 
> I've made a pull request for f29 here:
> https://src.fedoraproject.org/rpms/blender/pull-request/2

Pull merged. I successfully test the scratch and confirm the fix. Update coming shortly.

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

YafaRay-3.3.0-13.fc29 blender-2.79b-9.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-baaa0f8a07

YafaRay-3.3.0-13.fc29, blender-2.79b-9.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-baaa0f8a07

YafaRay-3.3.0-13.fc29, blender-2.79b-9.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.