Bug 671284 - Blender 2.56 is missing user interface
Summary: Blender 2.56 is missing user interface
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: blender
Version: rawhide
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jochen Schmitt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 689051 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-21 00:00 UTC by Tom
Modified: 2011-04-13 14:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-13 14:30:28 UTC
Type: ---


Attachments (Terms of Use)

Description Tom 2011-01-21 00:00:23 UTC
Description of problem:
Blender 2.56 does not display user interface buttons. Menu, selections, etc. are missing from the headers and nearly all windows. User interface is missing with both the default setup and my previous 2.49 setup.

When installing Blender 2.56 I get these warnings in yum:
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
Unknown media type in type 'uri/mms'
Unknown media type in type 'uri/mmst'
Unknown media type in type 'uri/mmsu'
Unknown media type in type 'uri/pnm'
Unknown media type in type 'uri/rtspt'
Unknown media type in type 'uri/rtspu'
Unknown media type in type 'interface/x-winamp-skin'
Warning in file "/usr/share/applications/gnome-nautilus-folder-handler.desktop": usage of MIME type "x-directory/gnome-default-handler" is discouraged ("x-directory" is an old media type that should be replaced with a modern equivalent)
Warning in file "/usr/share/applications/gnome-nautilus-folder-handler.desktop": usage of MIME type "x-directory/normal" is discouraged ("x-directory" is an old media type that should be replaced with a modern equivalent)

When starting Blender 2.56 I get this followed by lots of ImportError:
/usr/bin/blender: line 74: [: too many arguments
bpy: couldnt find 'scripts/modules', blender probably wont start.

Version-Release number of selected component (if applicable):
blender-2.56-5.fc15.i686

How reproducible:
Everytime

Steps to Reproduce:
1.Update Blender from 2.49 to 2.56
2.No user interface available
3.Erasing Blender 2.56 and reinstalling doesn't help

Actual results:
Blender is unusable

Expected results:
All menu options in Blender displayed

Additional info:
Maybe rebuilding Blender from a different SVN version will work better.

Comment 1 Richard Shaw 2011-02-22 16:40:03 UTC
I'm working on the same problem for F14. There may be some helpful/relevant info in my bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=679197

Comment 2 Richard Shaw 2011-02-22 21:53:42 UTC
All I can find is the following upstream bug which seems to indicate it's a problem with python caused by not using the embedded python version:

http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=24454

I've tried building against Python 3.1 from F14 (using --without py32) and Python 3.2 from rawhide with the same result.

Comment 3 Richard Shaw 2011-02-22 23:38:29 UTC
Ok, more info that may or may not be related. The bash script that actually loads blender creates a lot of directories in your home folder and copies/symlinks files from /usr/share/blender and /usr/lib64/blender

It creates two directories that the system equivalents for no longer exist as far as I can tell.

/usr/share/blender/scripts/bpymodules (supposed to just be modules now?)
/usr/share/blender/scripts/bpydata (and a few subfolders)

If blender doesn't look in /usr/share/blender automatically and depends on the right files/symlinks to be available in ~/.blender then this could be the problem.

Comment 4 Richard Shaw 2011-02-25 14:53:07 UTC
I finally remembered to use a little friend called strace and found why it's not finding the modules directory, it's looking in the wrong places:


stat("/usr/bin/2.56/scripts/modules", 0x7fff63a70b20) = -1 ENOENT (No such file or directory)
stat("/home/richard/.blender/2.56/scripts/modules", 0x7fff63a70c00) = -1 ENOENT (No such file or directory)
stat("/home/richard/release/scripts/modules", 0x7fff63a70920) = -1 ENOENT (No such file or directory)
stat("/usr/bin/release/scripts/modules", 0x7fff63a70920) = -1 ENOENT (No such file or directory)
stat("/usr/local//share/blender/2.56/scripts/modules", 0x7fff63a70920) = -1 ENOENT (No such file or directory)

I tried patching environment-unix to get it to look at /usr/share instead of /usr/local/share but it didn't seem to have any effect.

Also, by default blender 2.5+ includes the version number in the path. I'm not sure we want this behavior on the system installed files but I haven't figured out how to turn it off.

This also means that the wrapper script that actually loads blender no longer creates the right ~/.blender structure.

Comment 5 Tom 2011-03-01 02:48:01 UTC
Thanks for the info. Right now I'm just using this version from its folder without installing.
http://download.blender.org/release/Blender2.56abeta/blender-2.56a-beta-linux-glibc27-i686.tar.bz2

Comment 6 Richard Shaw 2011-03-01 19:17:39 UTC
Update from continuing conversation on the blender linux mailing list:

As suggested I downloaded the Suse src RPM and reviewed their spec file which not only uses cmake instead of scons for building, it looks like a *lot* of work has gone into it. 

I don't think we can use it directly as there seemed to be some suse specific macros but I think 90% could be reused for our package.

Anyone see a problem with doing this?

Comment 7 Richard Shaw 2011-03-08 18:33:38 UTC
Still working on a better solution. Although this bug report is specifically about rawhide/F15 I have a question maybe someone can answer.

Current SVN builds require python 3.2 and of course F14 only has 3.1. Is it possible to bundle 3.2 just for blender? I know it's frowned upon but I don't see any alternative to get blender 2.56 for F14.

Comment 8 Tom 2011-03-10 01:02:04 UTC
I've had troubles in the last few day trying to launch precompiled versions of Blender, but now I'm able to build trunk SVN Blender on Rawhide using this 'user-config.py'

BF_FFMPEG_INC = '${BF_FFMPEG}/include/ffmpeg'

BF_PYTHON = '/usr'
BF_PYTHON_LIBPATH = '${BF_PYTHON}/lib'
BF_PYTHON_VERSION = '3.2'
BF_PYTHON_INC = '${BF_PYTHON}/include/python${BF_PYTHON_VERSION}mu'
BF_PYTHON_BINARY = '${BF_PYTHON}/bin/python${BF_PYTHON_VERSION}'
BF_PYTHON_LIB = 'python${BF_PYTHON_VERSION}mu'
BF_PYTHON_LINKFLAGS = ['-Xlinker', '-export-dynamic']

(from http://projects.blender.org/tracker/?func=detail&atid=498&aid=26255&group_id=9)
and also doing:
su -c 'ln -s /usr/lib/libgettextlib-0.18.1.so /usr/lib/libgettextlib.so'

Comment 9 Richard Shaw 2011-03-10 01:11:49 UTC
I'm working on getting a new source package put together that will work on both F14 and F15/Rawhide. 

I'm also collaborating with the Suse package maintainer to see if we can get a unified source RPM since they are almost identical (RPM based)

After a certain svn revision blender requires python 3.2 and was no longer compatible with python 3.1. I have current svn build with reverse patches for python 3.1 for Fedora 14. 

My package uses the recommended cmake over scons and creates several packages:

blender
blender-devel
blender-doc
blender-debuginfo

If you want to try it I'll update my spec file and build a F15 or rawhide package.

Comment 10 Richard Shaw 2011-03-11 00:31:23 UTC
I'm working on getting a new source package put together that will work on both F14 and F15/Rawhide. 

I'm also collaborating with the Suse package maintainer to see if we can get a unified source RPM since they are almost identical (RPM based)

After a certain svn revision blender requires python 3.2 and was no longer compatible with python 3.1. I have current svn build with reverse patches for python 3.1 for Fedora 14. 

My package uses the recommended cmake over scons and creates several packages:

blender
blender-devel
blender-doc
blender-debuginfo

If you want to try it I'll update my spec file and build a F15 or rawhide package.

Comment 11 Jochen Schmitt 2011-04-06 18:33:24 UTC
I have built blender-2.56-9.svn36007 for rawhide. It may be nice, if you can try out it.

Comment 12 Tom 2011-04-07 01:05:49 UTC
Better, but the buttons appear black, and I can't read their text. I get this warning with glxinfo:
nvfx_screen_get_param:85 -  Warning: unknown PIPE_CAP 36
nvfx_screen_get_param:85 -  Warning: unknown PIPE_CAP 43
nvfx_screen_get_param:85 -  Warning: unknown PIPE_CAP 44
but an old Blender 35596 SVN still appears fine. (Sorry, but I don't have time right now to try recent SVN.)

Comment 13 Jochen Schmitt 2011-04-07 20:18:10 UTC
Thank you for your feedback. I have found the reason of this issue and have created blender-2.56-10.svn36007 on rawhide which should fix the issue.

Comment 14 Jochen Schmitt 2011-04-07 20:19:19 UTC
*** Bug 689051 has been marked as a duplicate of this bug. ***

Comment 15 Tom 2011-04-08 23:37:11 UTC
Sorry for the delay, but this blender has missing header menus on the windows.

Comment 16 Jochen Schmitt 2011-04-12 16:54:28 UTC
Thank you for your feedback. Unfortunately something was going wrong with me. Now I have created a new release which should works. It may be nice, if you can tryout blender-2.56-11.svn36007 from rawhide.

Comment 17 Tom 2011-04-13 09:12:28 UTC
Yes, all menus work for me now. Thanks!


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