Bug 1631922 - No text in Blender UI due to bpy incompatible with python 3.7
Summary: No text in Blender UI due to bpy incompatible with python 3.7
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: blender
Version: 29
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Luya Tshimbalanga
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 1638592 1638999 (view as bug list)
Depends On:
Blocks: PYTHON37
TreeView+ depends on / blocked
 
Reported: 2018-09-22 01:16 UTC by Artem
Modified: 2018-11-04 06:51 UTC (History)
19 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-11-04 06:51:47 UTC


Attachments (Terms of Use)
Blender no text (297.41 KB, image/png)
2018-09-22 01:16 UTC, Artem
no flags Details
blender startup log (58.04 KB, text/plain)
2018-09-25 05:39 UTC, Artem
no flags Details

Description Artem 2018-09-22 01:16:03 UTC
Created attachment 1485834 [details]
Blender no text

Description of problem:
No text in UI.

Version-Release number of selected component (if applicable):
2.79b-7

How reproducible:
Run Blender.

Actual results:
No text and other UI elements. Blender unusable.

Expected results:
As before.

Additional info:
Blender from Steam and from official Blender site run ok.

Comment 1 Luya Tshimbalanga 2018-09-25 05:23:25 UTC
Hello Artem,

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

Comment 2 Artem 2018-09-25 05:39 UTC
Created attachment 1486621 [details]
blender startup log

Comment 3 Artem 2018-09-25 05:41:47 UTC
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.

Comment 4 Nicolas Chauvet (kwizart) 2018-09-25 05:55:35 UTC
(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)?

Comment 5 Artem 2018-09-25 06:06:07 UTC
(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.

Comment 6 Nicolas Chauvet (kwizart) 2018-09-25 06:50:01 UTC
I should reproduce on f29, It was on f28...

Comment 7 Artem 2018-09-25 06:54:03 UTC
(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.

Comment 8 Luya Tshimbalanga 2018-09-28 06:44:15 UTC
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.

Comment 9 Miro Hrončok 2018-09-29 06:44:47 UTC
Marcel, could you please look at this?

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

Thank you very much.

Comment 10 Marcel Plch 2018-10-02 13:23:21 UTC
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.

Comment 11 Marcel Plch 2018-10-10 15:56:24 UTC
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.

Comment 12 Luya Tshimbalanga 2018-10-11 08:50:01 UTC
Just got a result on Blender development:
https://developer.blender.org/search/query/uuadOfAnF6Df/#R

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

Comment 13 Petr Viktorin 2018-10-11 09:15:55 UTC
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.

Comment 14 Victor Stinner 2018-10-11 12:37:26 UTC
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.

Comment 15 Luya Tshimbalanga 2018-10-11 15:27:13 UTC
Filed bug on https://developer.blender.org/T56969

Comment 16 Miro Hrončok 2018-10-11 15:46:58 UTC
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.

Comment 17 Luya Tshimbalanga 2018-10-15 03:50:41 UTC
*** Bug 1638999 has been marked as a duplicate of this bug. ***

Comment 18 Luya Tshimbalanga 2018-10-21 17:53:15 UTC
(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.

Comment 19 Andrea Bruna 2018-11-02 10:40:20 UTC
(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.

Comment 20 Miro Hrončok 2018-11-02 10:43:47 UTC
Another workaround is flatpak https://flathub.org/apps/details/org.blender.Blender

Comment 21 Petr Viktorin 2018-11-02 15:05:19 UTC
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

Comment 22 Luya Tshimbalanga 2018-11-02 17:57:54 UTC
(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.

Comment 23 Luya Tshimbalanga 2018-11-02 18:47:42 UTC
*** Bug 1638592 has been marked as a duplicate of this bug. ***

Comment 24 Fedora Update System 2018-11-02 20:32:26 UTC
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

Comment 25 Fedora Update System 2018-11-03 00:55:50 UTC
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

Comment 26 Fedora Update System 2018-11-04 06:51:47 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.