Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 272861 - media-gfx/blender-2.49 ebuild request
Summary: media-gfx/blender-2.49 ebuild request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Luca Barbato
URL: http://www.blender.org
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-06 08:42 UTC by Christian Strahl
Modified: 2009-07-05 06:07 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
test overlay for blender 2.49 (blender-2.49.-r1.tar.gz,5.18 KB, application/x-tar-gz)
2009-06-09 06:01 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49 (blender-2.49-r06092009.tar.gz,5.43 KB, application/x-tar-gz)
2009-06-10 05:46 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49 (blender-2.49-r06112009.tar.gz,6.68 KB, application/x-tar-gz)
2009-06-11 08:50 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49 (blender-2.49-r06202009.tar.gz,12.65 KB, application/x-tar-gz)
2009-06-21 08:10 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49 (blender-2.49-r06212009.tar.gz,12.67 KB, application/x-tar-gz)
2009-06-21 20:17 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49a (blender-2.49a-r06212009.tar.gz,14.65 KB, application/x-tar-gz)
2009-06-22 03:06 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49a (blender-2.49a-r06222009.ebuild,18.03 KB, application/x-tar-gz)
2009-06-23 06:00 UTC, biohazrd
Details
overlay for media-gfx/blender-2.49a (blender-2.49a-r06222009.tar.gz,17.84 KB, application/x-tar-gz)
2009-06-23 06:11 UTC, biohazrd
Details
media-gfx/blender-2.49a overlay (blender-2.49a-r06282009.tar.gz,15.97 KB, application/x-tar-gz)
2009-06-28 18:45 UTC, biohazrd
Details
media-gfx/blender-2.49a overlay (blender-2.49a-r06282009.tar.gz,15.90 KB, application/x-tar-gz)
2009-06-29 03:45 UTC, biohazrd
Details
media-gfx/blender-2.49a overlay (blender-2.49a-r07012009.tar.gz,15.99 KB, application/x-tar-gz)
2009-07-02 05:39 UTC, biohazrd
Details
Fixes openjpeg link error, use bundled svg icon, add openjpeg dependency (blender-2.49a-r07022009.ebuild,4.76 KB, text/plain)
2009-07-02 15:01 UTC, Hans Nieser
Details
ebuild patch from r07012009 to r07022009 (ebuild-patch-against-r07012009.patch,867 bytes, patch)
2009-07-02 15:02 UTC, Hans Nieser
Details | Diff
Patch to blender scons tools for adding system openjpeg to linker flags (blender-2.49a-sys-openjpeg.patch,452 bytes, patch)
2009-07-02 15:04 UTC, Hans Nieser
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Strahl 2009-06-06 08:42:06 UTC
Please add new ebuild for media-gfx/blender.

Reproducible: Always

Steps to Reproduce:
1. emerge blender

Actual Results:  
blender 2.48.1 is installed

Expected Results:  
blender 2.49 should be installed
Comment 1 biohazrd 2009-06-09 06:01:40 UTC
Created attachment 193965 [details]
test overlay for blender 2.49 

untar in /usr/local/portage/media-gfx/  (or whatever overlay you use.)
Comment 2 biohazrd 2009-06-09 06:06:20 UTC
I have created an ebuild that successfully builds blender 2.49 based on the ebuild from 2.48a.  I am certainly no professional at this, but I think I captured all of the current working USE flag options. If the USE flag player is enabled, you have to use the blender-game USE flag.  There is hack test for this which fails with a die message if the wrong combo is encountered. I found this make issue on blender.org. 

I have not tested all various options related to combos of various flags but I have tested no USE flags and the basic package compiles with no options and it also compiled with all USE flags set. 

Maybe some tests and feed back would be in order.  I still have to check with lu_zero, the maintainer and submit this for upstream for fine tuning and ultimate integration.  But give it a try.
Comment 3 SATtva 2009-06-09 10:51:47 UTC
I've encountered one problem: if Python Scripts path in Blender settings points to the user-defined scripts directory (i.e. /home/user/blender/scripts), then global scripts in /usr/share/blender/scripts aren't registered in the program.
Comment 4 biohazrd 2009-06-10 05:21:38 UTC
Comment on attachment 193965 [details]
test overlay for blender 2.49 

not a great name convention for ebuild test.  Have an updated one.
Comment 5 biohazrd 2009-06-10 05:46:10 UTC
Created attachment 194081 [details]
overlay for media-gfx/blender-2.49

I found that in blender-2.49 that the default scripts are hard coded to look for them in ~/.blender/scripts. I removed the old overlay tarball as the name convention was not well thought out by me.  As it is merely an ebuild in progress I titled it by date and think I fixed the issue of it not finding the python script directory.  

In short I edited the blender.desktop folder to call blender-start, which is a script that I created to test on each run if ~./blender/scripts exists.  If not it makes the directory and creates a symlink to /usr/share/blender/scripts.  You should still be able to add another path, but this should be the default. I thought a symlink would be better than copying it as each time blender is updated it would update the symlink to the most current python scripts and not have the user having to update his script folders. It should also do this for each user's session. 

I still have some research on USE flags and confirming that each item configured for build time actually builds. After talking with some blender coders, openssl is no longer a RDEPEND as encryption for the game engine has changed.  Also I was told quicktime does not work with linux in blender so I removed it. I added BSD in the license as I found that ODE has that license type. (I think that was the right thing to do.)

I suppose documenting a CHANGELOG would be in order?  I need some guidance from the maintainer on this on how to eventually work this into at least sunrise. 

But for now, let me know if you experience any more issues. .. as usual untar in /usr/local/portage/media-gfx or whatever overlay you use.
Comment 6 SATtva 2009-06-10 15:52:30 UTC
Latest ebuild works correctly. I had to ln -s /usr/share/blender/scripts ~/.blender/scripts to get all scripts (bundled as well as user installed) appear in the program.
Comment 7 biohazrd 2009-06-11 08:50:29 UTC
Created attachment 194223 [details]
overlay for media-gfx/blender-2.49 

06112009 has it so the CFLAGS/CXXFLAGS used in make.conf get passed to user-config.py at build time.  As an additional treat I included a patch to increase the max threads from 8 to 16.  People with dual quad core Nehalem's running virtual cores may want to experiment with it.  It seemed to work fine on my system. You will have to uncomment the epatch for it in the ebuild and digest before building.

I noticed however that it set the default threads to 1 when it was first started.  I believe there is other code that tests CPU count that doesn't read it right with the patch, but you can manually set the thread count to 16.
Comment 8 SATtva 2009-06-14 18:36:26 UTC
Again, the latest one builds correctly. Everything's working fine for the last days.
Comment 9 Francesco Proietti 2009-06-18 08:02:28 UTC
I emerged the last ebuild some days ago and all is working right. BTW I had to ln -s /usr/share/blender/scripts ~/.blender/scripts, too.
Thank you.
Comment 10 biohazrd 2009-06-18 13:31:26 UTC
What desktop are you both using?  I am using Gnome and it works fine.  I assume you may have started it with just running /usr/bin/blender.  The blender.desktop creates an icon in your Application menu and it actually calls /usr/bin/blender-start which tests for the symlink in ~./blender and creates it if it does not exist then starts blender.

Please try removing your symlink you manually made and using the menu to start blender and let me know how it works. If for some reason your desktop environment does not support menu's try just running /usr/bin/blender-start  

I may have to rethink the ebuild install, but I wanted to avoid flat out copying the scripts to each users home on installation of blender as it would not be able to do it for new users added. Hence the startup script.
Comment 11 SATtva 2009-06-18 15:06:44 UTC
I use Fluxbox which doesn't process .desktop files automatically.
Comment 12 SATtva 2009-06-18 15:09:45 UTC
BTW I think the current approach with blender-start startup script as an optimal one. But one thing I can suggest is adding post-install info text into ebuild to inform a user to the issue and advice him to call blender-start manually if he doesn't use fullsized desktop environment.
Comment 13 biohazrd 2009-06-19 05:42:20 UTC
Do you feel putting it in an elog would be the best approach? I can certainly do that. I have tried to think this through for the vast user base and different setups and I agree so far this was the best I could come up with.  If anyone has any other ideas let me know.

If I understood lu_zero I think he would prefer it to auto merge blender-game if player is selected without blender-game USE flags.  blender-game will build without player, but player will not build without blender-game.  I currently have it die with a message for the user to use both flags if player is selected alone.  At least they are aware of the conflict and can make the choice on their own.  

How do you guys feel about forcing blender-game to build if player is selected, knowing that blender-game is a separate USE flag? 
Comment 14 SATtva 2009-06-19 05:46:58 UTC
I have no objections. Maybe not quite intuitive, but at least you let the emerge die and give a hint about what happened and how to fix that.
Comment 15 Francesco Proietti 2009-06-20 10:07:24 UTC
I'm using Gnome and starting Blender from a custom icon on gnome-panel, so I had to manually create the symlink. Starting Blender from the Application menu works as expected, creating the symlink if necessary.
I think that auto-selecting blender-game if only player is selected is a good solution, instead of letting the ebuild die, but I'd like a post-install message saying "The blender-game USE flag has been auto-selected, it's needed to build the player".
Comment 16 biohazrd 2009-06-21 08:10:45 UTC
Created attachment 195325 [details]
overlay for media-gfx/blender-2.49 

This should sum up the changes requested by everyone here. I don't have developer status to put this in the tree. But it works on ~amd64 so it is keyworded as such. If anyone runs with this code, please at least reference me for my work.

Thanks..
Comment 17 SATtva 2009-06-21 09:28:34 UTC
Minor corrections for the elog info message:

1. s/smylink/symlink/
2. Add line wrap at column 80, otherwise text is displayed ugly on standard terminals.
Comment 18 biohazrd 2009-06-21 20:17:04 UTC
Created attachment 195391 [details]
overlay for media-gfx/blender-2.49

Guess I take for granted working on a wide screen monitor.

Thanks.
Comment 19 biohazrd 2009-06-22 03:06:42 UTC
Created attachment 195411 [details]
overlay for media-gfx/blender-2.49a

I noticed today that they released 2.49a.  I included an updated ebuild for it.  This overlay has 2.49 and 2.49a ebuilds.  

Let me know if you run into any issues.
Comment 20 SATtva 2009-06-22 06:59:51 UTC
2.49a works fine to me.
Comment 21 zolar czakl 2009-06-22 22:50:44 UTC
Few ideas.
- ode is deprecated (and broken IFAIK)
- missing dep  +jpeg2k (media-libs/openjpeg)
- openexr is (almost) mandatory (for render purpose)
  a reference here "
  http://www.blender.org/development/release-logs/blender-242/high-dynamic-range-graphics/"   §"Multi-layer, Multi-pass, tile-based files"
- problem: if you link the scripts dir, you cannot add new plugins as user
  possible solution: create a scripts dir in ~/.blender and then link in this way

  $ ls -l .blender/scripts
  lrwxrwxrwx 1 bpydata -> default/bpydata
  lrwxrwxrwx 1 bpymodules -> default/bpymodules
  lrwxrwxrwx 1 default -> /usr/share/blender/scripts


- if we rename the real binary blender.bin (or blender249a) and the wrapper 
  blender, I think (not tested), we remove the .desktop issue.

- what about a better .png icon from ./release/freedesktop/icons/scalable blender.svg


Forgive my English :|
Comment 22 biohazrd 2009-06-23 04:03:12 UTC
(In reply to comment #21)
> Few ideas.
> - ode is deprecated (and broken IFAIK)

Yes it is depreciated but it still works according to the folks in #blendercoders, so I left the USE flag.

> - missing dep  +jpeg2k (media-libs/openjpeg)

This is and has been handled by several versions of blender to use the openjpeg libs that come with the source code.  I suppose it could be patched to use local libs, or punch down changes in user-config.py, but it does not appear to have been in the past, so I didn't change it.  So it is not truly a build dependency as far as the ebuild goes.  However media-libs/jpeg is a valid option. Please unpack the source and look over config/linux2-config.py.  You will find:

WITH_BF_OPENJPEG = True 
BF_OPENJPEG = '#extern/libopenjpeg'
BF_OPENJPEG_LIB = ''
BF_OPENJPEG_INC = '${BF_OPENJPEG}'
BF_OPENJPEG_LIBPATH='${BF_OPENJPEG}/lib'

> - openexr is (almost) mandatory (for render purpose)
>   a reference here "

You are right, blender is pretty much useless without openexr, but when I first went at this and speaking to the people in #blendercoders it was also not a requirement for it to build. In hind sight I suppose this should be changed.
  
> http://www.blender.org/development/release-logs/blender-242/high-dynamic-range-graphics/"
>   §"Multi-layer, Multi-pass, tile-based files"
> - problem: if you link the scripts dir, you cannot add new plugins as user
>   possible solution: create a scripts dir in ~/.blender and then link in this
> way
> 


>   $ ls -l .blender/scripts
>   lrwxrwxrwx 1 bpydata -> default/bpydata
>   lrwxrwxrwx 1 bpymodules -> default/bpymodules
>   lrwxrwxrwx 1 default -> /usr/share/blender/scripts


blender-2.49 looks for the default scripts in ~/.blender/scripts. You can still add your own path in the application and it will use both the default and your custom path. (Read comment #6 from SATtva.) He was able to also set a user defined script location.  I assume something like ~/.blender/myscripts would suffice.  Let me know if this does not work for you.

I asked again tonight in #blendercoders and they again confirmed this. The benefit of the symlink is it always updates the users default scripts to the most current versions installed on any update. I suppose I can try to use the old blender-2.44-scriptsdir.patch, but I suspect that it will no longer work with 2.49 and the changes in the hard coded default.

Please elaborate what the the first 2 links will solve.  They are already a level below in the path of the symlinked scripts.  The last symlink you have takes care of the path search for the first 2 from what I see. Both your links for bpydata and bpymodules point to a symlink outside the users directory and would not solve custom scripts that I can see.
> 
> 
> - if we rename the real binary blender.bin (or blender249a) and the wrapper 
>   blender, I think (not tested), we remove the .desktop issue.

True, I did not think of that, however I suspect no matter what the decision is, it won't work for someones setup. Maybe we just elog the whole issue and let the user decide what to do?  Again it comes down to the issue with scripts...
> 
> - what about a better .png icon from ./release/freedesktop/icons/scalable
> blender.svg

The scalable icon would not be difficult to include and I will change that.


I also noticed they have not updated the source code to include another older CVE patch, which I will fix.  The ffmpeg patches appear to be useless now as the default is to build with the systems ffmpeg libs.
 
> 
> Forgive my English :|
> 
Your English is fine.  Forgive my coding... I know very little about ebuilds.  This is my first attempt at overhauling one.


SATtva... Will you please reconfirm that everything works for your custom scripts and the default ones with the symlink method?  I don't have any custom ones to test. Maybe you can make a suggestion on how you set yours up?
Comment 23 biohazrd 2009-06-23 06:00:51 UTC
Created attachment 195525 [details]
overlay for media-gfx/blender-2.49a

I didn't obsolete the previous one as I am not so sure about the direction I used in this.  I removed several use flags that are defaults anyhow with the linux2-config.py script and forced them as dependencies at build time.

I left flags that I would consider optional.  I did add the scalable .svg icon and the blender-2.46-cve-2008-1103-1.patch back in as I see the source still has not been fixed for that issue.


I did try to force building with locally installed openjpeg libs instead of the included versions and ran into massive compile fails over and over.  I will still play with it, but it appears to be easier just to roll with what is in the source as the previous ebuilds did.

I still think that the basic requirements should be what is mandatory to build it, and have the user select USE flags to enable/disable certain functions per their needs.
Comment 24 biohazrd 2009-06-23 06:11:12 UTC
Created attachment 195527 [details]
overlay for media-gfx/blender-2.49a

sorry I am half awake and named the previous file incorrectly...
Comment 25 SATtva 2009-06-23 07:40:23 UTC
(In reply to comment #22)
> SATtva... Will you please reconfirm that everything works for your custom
> scripts and the default ones with the symlink method?  I don't have any custom
> ones to test. Maybe you can make a suggestion on how you set yours up?

Symlinking method proposed by zolar czakl works fine. One benefit I see in it is that user could place custom scripts in the default search path in ~/.blender/scripts instead of creating another directory and defining it in Blender configuration (and many tutorials and scripts installation instructions list ~/.blender/scripts explicitly as installation path). Maybe this approach is more foolproof and should be followed. (It won't affect "updateability" of bundled scripts on new version installation.)

However, this approach has one issue. As we need to symlink both bpydata and bpymodules (and scripts use these directories to store their settings), custom scripts placed in ~/.blender/scripts couldn't store their settings as user don't have write permissions to /usr/share/blender/scripts/{bpydata,bpymodules}.
Comment 26 Francesco Proietti 2009-06-23 22:05:27 UTC
Some little typo errors in the latest ebuild.

In blender-2.49a-r06222009.tar.gz the ebuild has a wrong name, blender-2.49a-r06212009.ebuild instead of blender-2.49a-r06222009.ebuild.


In blender-2.49a-r06222009.ebuild, in pkg_postinst():
elog "blender-start will automatically test a symlink to /usr/share/bledner/scripts"

should be:
elog "blender-start will automatically test a symlink to /usr/share/blender/scripts"

and:
elog "The blender.desktop file will also handle this automatically by calling"
elog "by calling blender-start."

should be:
elog "The blender.desktop file will also handle this automatically by calling"
elog "blender-start."


Am I the only one to get the message "Unable to save /home/francesco/tmp/quit.blend, check you have permissions" saving a modified blend?
This happens only with blender-2.49a-r06222009, while with blender-2.49-r06112009 no message appears when I quit Blender.
Comment 27 zolar czakl 2009-06-23 23:07:26 UTC
(In reply to comment #22)
> blender-2.49 looks for the default scripts in ~/.blender/scripts. You can still
> add your own path in the application and it will use both the default and your
> custom path. (Read comment #6 from SATtva.) He was able to also set a user
> defined script location.  I assume something like ~/.blender/myscripts would
> suffice.  Let me know if this does not work for you.
> 
> Please elaborate what the the first 2 links will solve.  They are already a
> level below in the path of the symlinked scripts.  The last symlink you have
> takes care of the path search for the first 2 from what I see. Both your links
> for bpydata and bpymodules point to a symlink outside the users directory and
> would not solve custom scripts that I can see.

The symlinks are not outside the user directory.

~/.blender/scripts/default/    
~/.blender/scripts/bpydata    <-- link to default/bpydata
~/.blender/scripts/bpymodules <-- link to default/bpymodules

Why?
Start blender from a terminal without the last two links.
In the scripts window select:
Scripts > Wizards > Tree from Curves
and looks what happen.


My suggestion is a way to remove the user intervention to have a fully functional installation but maybe is overcomplicated.
Forget all, sorry.


SATtva is absolutely right.
Some scripts needs write permission.

New plan (copy instead of symlink).
The ebuild can save the VERSION file somewhere, then the wrapper checks for that file (only one copy every new version).


And sorry for the other mistakes. :P
Comment 28 biohazrd 2009-06-24 01:02:06 UTC
Sorry the last ebuild was massive fail... I have not been feeling to well the last few days.  The error on the permissions is a result of the CVE-2.46-2008-1103-1.patch.  Which I did not have in the past ebuilds, but it appears that the blender source code has not been fixed for that vulnerability.  
(At least from what I can see in the source of what is getting patched)

My confusion I guess is coming from the last link of default to /usr/share/blender/scripts as the other 2 of default/bpydata and default/bpymodules by nature would circle back to /usr/share/blender/scripts/(bpydata)(bpymodules).  

Unless I am missing something, anything you put in ~/.blender/scripts/default would try to put it in /usr/share/blender/scripts 

~/.blender/scripts/default/ 
 
  lrwxrwxrwx 1 default -> /usr/share/blender/scripts

When I feel better I'll try to write a wrapper that tests for the existence of the users home scripts and copy them to it.  Either that or elog the whole thing and let each person decide what they want to do. Blanket copy to everyones home is out of the question in my mind.

Comment 29 SATtva 2009-06-24 11:36:47 UTC
(In reply to comment #26)

> Am I the only one to get the message "Unable to save
> /home/francesco/tmp/quit.blend, check you have permissions" saving a modified
> blend?
> This happens only with blender-2.49a-r06222009, while with
> blender-2.49-r06112009 no message appears when I quit Blender.

No, you aren't the only one, I got this error with every Blender version, but I don't see how (or does) it affects functionality. As I'm running Blender mostly on hardened kernel and hardened toolchain, I thought that is the reason.
Comment 30 Luca Barbato gentoo-dev 2009-06-25 15:11:43 UTC
could you please open another bug (and possibly one upstream) about the quit.blend issue ( do you have a ~/tmp dir btw? )

I hope to put the updated ebuild (pending some polishing to make repoman happy) from biohazrd in portage possibly once I'm back from linuxtag, sorry for the delay ^^;
Comment 31 SATtva 2009-06-25 15:56:34 UTC
Absence of ~/tmp indeed could be the issue. I've created a symlink to /tmp from the homedir, and since then didn't seen the error.
Comment 32 Francesco Proietti 2009-06-25 17:50:32 UTC
(In reply to comment #30)
> could you please open another bug (and possibly one upstream) about the
> quit.blend issue ( do you have a ~/tmp dir btw? )

I have ~/tmp and changing blender temp path to /tmp didn't change anything.
I get this error only if quit.blend exists in tmp dir otherwise it gets created as it should be and I get no error quitting Blender.

I will open a new bug here and upstream as soon as I'll get some free time to make some tests.
Comment 33 biohazrd 2009-06-27 19:21:03 UTC
The quit.blend issue happens when CVE-2008-1103 patch is applied.  It did not do it in my original ebuild because I didn't use the patch as I thought it was no longer needed.  But after looking at the source code in 2.49a; they appear to still not have the vulnerability fixed.  You can test it by commenting out the epatch for blender-2.46-CVE-2008-1103-1.patch, redigest and compile.  

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1103 <- if you want to read up on the potential issues of remote code execution.
 		
 	BLI_make_file_string("/", str, btempdir, "quit.blend");
 
-	file = open(str,O_BINARY+O_WRONLY+O_CREAT+O_TRUNC, 0666);
+	file = open(str,O_BINARY+O_WRONLY+O_CREAT+O_TRUNC+O_EXCL, 0666);
 	if(file == -1) {
 		error("Unable to save %s, check you have permissions", str);
 		return;

/tmp/quit.blend seems to be created upon exiting blender only if the project has been modified. Whatever the patch code above does to prevent the CVE issue also appears to prevent write permissions from the user upon exit the 2nd time.  The quit.blend file is created with the user:group of the user that created it, I question why the perms need global read perms in the first place.  (Should be 0660 in my mind.) 

But after speaking to the folks in #blendercoders they don't even see this CVE as being an issue.  It is still a candidate not confirmed and the nature of blender integration with python will always pose some risk with security. 

Creating your own ~tmp folder and setting it in the blender paths seems to cure the problem and is probably smarter anyhow.  Maybe the code should be patched that is the default to put it in ~/.blender/tmp.   

I'll get around to fixing the spelling errors on the build.

Is the consensus to just copy scripts into the users home then? 

Comment 34 SATtva 2009-06-27 19:46:17 UTC
> Is the consensus to just copy scripts into the users home then?

You mean bundled scripts? This is an overkill in my mind, and as any overcomplicated method could lead to edge cases we are not aware of. My vote is for the clean elog message explaining the issue and proposing a user with ways to deal with it (e.g. copy from /usr/share, symlink to /usr/share, etc), but if others can see the automatic way as more optimal, I'll revoke my vote.
Comment 35 biohazrd 2009-06-28 18:45:21 UTC
Created attachment 195980 [details]
media-gfx/blender-2.49a overlay

This should address the script issues.  It goes back to using the patches in the way the previous versions did.  I did remove the CVE-2008-1103-1.patch as it interferes with the autosave undo feature with quit.blender.  I did however include in the elog a message about changing /tmp to another location.  

blender-start has been removed and blender should work as before without ~/.blender/scripts

If I can get it to build with system openjpeg libs, I will include an update later, but for now it still builds with source provided openjpeg libs as it has in the past. (However it does use system ffmpeg and python)

Let me know how you guys feel about the CVE issue.  The folks in #blendercoders don't feel it is an issue and have not addressed it in the current code.  blender-2.5 is a major overhaul and will not only have UI changes but changes to how tmp files work.
Comment 36 Luca Barbato gentoo-dev 2009-06-29 01:55:43 UTC
Should be easy creating the home tmpdir inside .blender...

Beside that I still think that blender-game and player should be merged in a single useflag.

the ebuild should use tabs (if you are using emacs or vim you'll get the syntax automatically)

Returning from linuxtag had been a bit more rough than expected (and that's why you don't see blender in portage...)
Comment 37 biohazrd 2009-06-29 02:35:42 UTC
(In reply to comment #36)
 
> Beside that I still think that blender-game and player should be merged in a
> single useflag.
> 
What would you call that flag?? Just blender-game?? They are still 2 distinct components of blender, but after some thought you are right they should be merged together.  We can also remove the use flag altogether as I recall the default should be to build both blender-game and player.
Comment 38 Luca Barbato gentoo-dev 2009-06-29 03:09:39 UTC
I'd leave that optional but default on.
Comment 39 biohazrd 2009-06-29 03:45:56 UTC
Created attachment 196031 [details]
media-gfx/blender-2.49a overlay

Ok, this one replaces the one from earlier today.  blender-game and player are now one USE flag of blender-game.  Either both or neither get built with the one flag.

Syntax and tabs stuff should look right.  Thanks a lot Luca, I had to learn vim today :)

I have some obligations to attend too so this is probably the last you will see from me for about 2 weeks.  

Thanks all.
Comment 40 SATtva 2009-06-29 07:13:14 UTC
biohazrd, thank you much for your time and efforts, they're much appreciated!
Comment 41 biohazrd 2009-07-02 05:39:10 UTC
Created attachment 196313 [details]
media-gfx/blender-2.49a overlay

I had a comment from another user that he would like to see ffmpeg as an optional USE flag so this has been updated to reflect that. I also removed ode as I have heard other reports that it is depreciated. 

Also it now uses system openjpeg libs to build against, which was a request a few weeks back.  

Has anyone found any issues yet with amd64?  I am curious if anyone has tried other platforms. The person that suggested making ffmpeg an option told me that this ebuild actually fixed some floating point exception errors he had with ffmpeg.

I made an ebuild for blender-2.5 from SVN, but the code is a long ways off from being ready.  The new interface looks good. I will try to stay on top of the changes as it progresses.
Comment 42 Christian Strahl 2009-07-02 09:38:42 UTC
(In reply to comment #41)
> Has anyone found any issues yet with amd64?

no, everything works fine.

> I made an ebuild for blender-2.5 from SVN, but the code is a long ways off from
> being ready.  The new interface looks good. I will try to stay on top of the
> changes as it progresses.

excellent, please post your 2.5 ebuild here when its ready to test.
Or should we open a new bug for this?

Comment 43 Hans Nieser 2009-07-02 13:14:57 UTC
(In reply to comment #41)
> Created an attachment (id=196313) [edit]
> media-gfx/blender-2.49a overlay
> 
> I had a comment from another user that he would like to see ffmpeg as an
> optional USE flag so this has been updated to reflect that. I also removed ode
> as I have heard other reports that it is depreciated. 
> 
> Also it now uses system openjpeg libs to build against, which was a request a
> few weeks back.  
> 
> Has anyone found any issues yet with amd64?  I am curious if anyone has tried
> other platforms. The person that suggested making ffmpeg an option told me that
> this ebuild actually fixed some floating point exception errors he had with
> ffmpeg.
> 
> I made an ebuild for blender-2.5 from SVN, but the code is a long ways off from
> being ready.  The new interface looks good. I will try to stay on top of the
> changes as it progresses.

I'm having some issues with the new r07012009 ebuild on amd64 related to it now using system openjpeg, compilation fails when it tries to link 'blender' because for some reason -lopenjpeg is not added to the link flags (it errors with undefined references to a bunch of opj_* functions in jp2.c), I tried to figure out why but I have had no luck (so far).

Also it seems there is no dependency on media-libs/openjpeg which I guess should be added (I already have it installed though so it shouldn't be the cause of my linking errors, I think).

In any case thanks for your efforts on the 2.49 ebuild, it is much appreciated :)
Comment 44 Hans Nieser 2009-07-02 14:59:58 UTC
I have a patch that fixes the openjpeg linking issue (patch is for blender's scons tools to add BF_OPENJPEG_LIB to linking flags), and while at it I also patched the ebuild to add the media-libs/openjpeg dependency and to use the blender.svg that comes with the tarball instead of the one under files/ (saves portage from 15KB, yay! :P)

I'm not sure why I'm the only one so far that reported the linking issue with openjpeg, maybe there's something else going on on the two systems I tested on, in which case my scons tools patch may not neccessary.

I'll attach the scons tools patch, the full ebuild (I'll name it using your versioning scheme if that's okay) and a patch to the ebuild in case that is more convenient.
Comment 45 Hans Nieser 2009-07-02 15:01:30 UTC
Created attachment 196376 [details]
Fixes openjpeg link error, use bundled svg icon, add openjpeg dependency
Comment 46 Hans Nieser 2009-07-02 15:02:36 UTC
Created attachment 196380 [details, diff]
ebuild patch from r07012009 to r07022009
Comment 47 Hans Nieser 2009-07-02 15:04:21 UTC
Created attachment 196382 [details, diff]
Patch to blender scons tools for adding system openjpeg to linker flags
Comment 48 SATtva 2009-07-02 15:09:41 UTC
(In reply to comment #44)
> I'm not sure why I'm the only one so far that reported the linking issue with
> openjpeg, maybe there's something else going on on the two systems I tested on,
> in which case my scons tools patch may not neccessary.

I've built it only on one system yet (with media-libs/openjpeg-1.3-r2 installed) without any problem.
Comment 49 Francesco Proietti 2009-07-02 15:32:05 UTC
I can confirm the linking issue with openjpeg and that the proposed patches solve the problem.
Running Blender for a few hours showed no problems so far.
Thank you all!
Comment 50 Luca Barbato gentoo-dev 2009-07-02 20:34:25 UTC
Thank you all. I pushed the ebuild with some changes in portage, please tell me if it's fine for you.

Comment 51 Hans Nieser 2009-07-02 21:24:08 UTC
Thanks for the commit! I managed to compile and run it without any issues on ~amd64
Comment 52 biohazrd 2009-07-03 06:00:02 UTC
Guys, sorry I can't believe I spaced the dependency of openjpeg!  I even wrote it down as a too do.  Oh well, can't be perfect I guess.   This was my first attempt at modifying an ebuild. 

I'll integrate the openjpeg and .svg icon changes into the 2.5 SVN ebuild and post it under a new bug.  Be warned though... It is a project far from complete and the program does not work much at all.  But i will give you a feel for the new UI. I'll post the bug# back in here as this is where the interest came from.

Comment 53 biohazrd 2009-07-03 08:48:50 UTC
As promised... blender-2.5 SVN

bug #276338
Comment 54 SATtva 2009-07-03 16:07:35 UTC
Thank you much guys and especially biohazrd! 2.49a has been built without a hitch on amd64.
Comment 55 biohazrd 2009-07-05 06:07:59 UTC
BSD License can be removed.  ode USE flag is gone and it was the only license of that type.