new version released http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73#Blender_2.73_Release_Notes Reproducible: Always
Version 2.74 was released (see URL).
Renaming 2.72b-r3 to 2.74 and removing "${FILESDIR}"/${PN}-2.72-T42797.diff patch got me to compile the latest version. It seems to work okay.
Whithout addons, cuda, openvdb, and osl agane???
go here for improving the ebuild https://github.com/hasufell/media-overlay/tree/master/media-gfx/blender if it works well, we can import it
The ebuild from https://github.com/hasufell/media-overlay/tree/master/media-gfx/blender (2.74) works flawlessly for me, I vote for importing it to the main tree :)
Could we directly bump to the more recent version 2.75, which was just released yesterday? http://www.blender.org/features/2-75/
at the moment we have a fail at emerge process in media-gfx/blender-2.75::media-overlay. [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/view_map/SteerableViewMap.cpp.o [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/view_map/ViewEdgeXBuilder.cpp.o [ 90%] [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/view_map/ViewMap.cpp.o Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/view_map/ViewMapBuilder.cpp.o [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/view_map/ViewMapIO.cpp.o [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/view_map/ViewMapTesselator.cpp.o [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/Curvature.cpp.o [ 90%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WEdge.cpp.o [ 91%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WFillGrid.cpp.o [ 91%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WSFillGrid.cpp.o [ 91%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WXEdge.cpp.o [ 91%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WXEdgeBuilder.cpp.o [ 91%] Building CXX object source/blender/freestyle/CMakeFiles/bf_freestyle.dir/intern/winged_edge/WingedEdgeBuilder.cpp.o Linking CXX static library ../../../lib/libbf_freestyle.a [ 91%] Built target bf_freestyle Makefile:146: recipe for target 'all' failed make: *** [all] Error 2 * ERROR: media-gfx/blender-2.75::media-overlay failed (compile phase): * emake failed
Created attachment 406342 [details] /var/tmp/portage/media-gfx/blender-2.75/temp/build.log
I could file this under a separate bug, but want to put it here first to get feedback. Blender will build and work with opencolorio-1.0.9-r1 if its yaml5 patch is updated to match what current in the git head for opencolorio. I'm attaching the patch if anybody can confirm that blender works for them with yaml5 + opencolorio with this patch.
Created attachment 407748 [details, diff] opencolorio yaml5 patch
*** Bug 551090 has been marked as a duplicate of this bug. ***
With regards comment #7, make -j1 works for me (with -collada).
1) Why you so slow to add cuda support to blender's ebuild?????? This is killer feature for cycles render 2) Where is the contrib addons in blender's ebuild (all)???? 3) Why there is no opencl/osl/opensubdiv/openvdb support? Add this ebuilds, please. 4) Why sooo slooowly adds new versions? I can't to work on blender from 2014 year! Thank's
(In reply to brothermechanic from comment #13) > 1) Why you so slow to add cuda support to blender's ebuild?????? > This is killer feature for cycles render > 2) Where is the contrib addons in blender's ebuild (all)???? > 3) Why there is no opencl/osl/opensubdiv/openvdb support? > Add this ebuilds, please. > 4) Why sooo slooowly adds new versions? > I can't to work on blender from 2014 year! > Thank's Uhm? I don't get paid, so maybe you should omit your "Why you so slow". Instead you could contribute the missing features. That's how opensource works, you know. Comment #4 already gave a link for anyone who wants to work on 2.75.
> Comment #4 already gave a link for anyone who wants to work on 2.75. I can confirm that using a blender-2.75a ebuild from here: https://github.com/rasdark/overlay/tree/master/media-gfx/blender works and compiles ok. I have to mention that I used package.env in order to avoid any LTO related CFLAGS. Blender was built with these {C|XX}FLAGS : CFLAGS=" -march=native -O2 -pipe -fno-lto -fno-use-linker-plugin" CXXFLAGS="${CFLAGS}" #CXXFLAGS="-std=c++11 ${CFLAGS} " LDFLAGS="" Should the ebuild be moved to portage tree and develop another for 2.76?
Created attachment 412660 [details] 2.75a ebuild
(In reply to Petros from comment #15) > > Comment #4 already gave a link for anyone who wants to work on 2.75. > > I can confirm that using a blender-2.75a ebuild from here: > https://github.com/rasdark/overlay/tree/master/media-gfx/blender > I don't work on that overlay.
(In reply to Julian Ospald (hasufell) from comment #17) > I don't work on that overlay. I know, but I think if many of us can confirm that the ebuild is working, it could be moved to the portage tree so that other users can enjoy Blender-2.75a. :)
http://www.blender.org/download/ 2.76 is out. The ebuild for 2.75a I uploaded, works for 2.76, if you rename it as blender-2.76.ebuild and create the manifest file in your local overlay. Go ahead and give it a shot ;) I will upload a tar with the files that have to exist in your OVERLAY_DIR/media-gfx/blender/files
Created attachment 414470 [details] files
I can confirm that it works, but it still fails to compile for me when I enable the collada USE flag, whereas the 2.72b-r3 ebuild in the official tree compiles fine with collada.
(In reply to Watcom from comment #21) > I can confirm that it works, but it still fails to compile for me when I > enable the collada USE flag, whereas the 2.72b-r3 ebuild in the official > tree compiles fine with collada. I can confirm exactly what you wrote. So I am forced not to use collada.
*** Bug 562934 has been marked as a duplicate of this bug. ***
https://github.com/hasufell/media-overlay/commit/81d3e0e5ce82c4d7c86f1e526f17ea68ecbcfb2a opencollada support is removed and only available in the live ebuild, see https://github.com/KhronosGroup/OpenCOLLADA/issues/339 https://developer.blender.org/T45300
and blender-9999 works with opencollada-9999 https://github.com/hasufell/media-overlay/commit/1c3d2d7e7b1b628570a7e812350b53a19877b545#diff-6498c6367a5f1a4912c9d76fa10c0435R68 This will stay until upstream knows what releases are.
@hasufell Still no cuda support! Ok, ok >:|
(In reply to brothermechanic from comment #26) > @hasufell > Still no cuda support! Ok, ok >:| What do you mean? I'm using CUDA with the 2.76 ebuild and it works fine.
this version in media-overlay dont compile anymore. https://bugs.gentoo.org/show_bug.cgi?id=566442
Hello This issue seems a bit all over the place so I need to ask: what is the recommended source for getting a 2.76b ebuild?
(In reply to DrSlony from comment #29) > Hello > This issue seems a bit all over the place so I need to ask: what is the > recommended source for getting a 2.76b ebuild? Read comments #16 and #20. Download the files and untar them in the proper file's directory for the blender ebuild, in your local overlay. Rename the 2.75a ebuild as 2.76b, create the manifest file and hopefully you are ready to go. mkdir -p $LOCAL_OVERLAY_DIR/media-gfx/blender/files untar the files.tar.xz in files and after puting the ebuild in the blender dir, rename it to blender-2.76b.ebuild. ebuild blender-2.76b.ebuild manifest as a last step
Created attachment 422978 [details] improved ebuild work with blender-7.6b and all gcc compilers including gcc-5.3.0 written by hasufell (https://github.com/hasufell), my contribution is simply to have used it for some months in an ~amd64 build with gcc-5.2.0 and gcc-5.3.0, and confirmed that the version bump to 2.76b also works well. Also compiles and runs cleanly with older gccs (tested with gcc-4.9.4).
Please consider merging (or using) the 2.76b ebuild I've attached, written by Julian Ospald (hasufell on github). I've used it for months, and unlike all the other ebuilds I've tried from virtually any overlay I can find, it works with the latest blender and the latest gcc. In my case, I've compiled and used blender using gcc-4.9.4, gcc-5.2.0 and gcc-5.3.0 on an ~amd64 system, and Julian's ebuild not only "just works", but works really well.
Myabe add path https://github.com/thankjura/overlay/blob/master/media-gfx/blender/files/adaptive_stopping.patch as flag? Source: https://developer.blender.org/D808 For cycles increases the speed of rendering 300%
(In reply to Jean-Michel Smith from comment #31) > Created attachment 422978 [details] > improved ebuild work with blender-7.6b and all gcc compilers including > gcc-5.3.0 > > written by hasufell (https://github.com/hasufell), my contribution is simply > to have used it for some months in an ~amd64 build with gcc-5.2.0 and > gcc-5.3.0, and confirmed that the version bump to 2.76b also works well. > Also compiles and runs cleanly with older gccs (tested with gcc-4.9.4). on this link https://github.com/hasufell is an interesting overlay: media-overlay but there is no ebuild for version blender-7.6b. there is only version: 2.76 listed. its the same?
What is holding this back? Can we assist somehow to finally bump blender? Blender is actively developed but we have a version from 2014-10-04 in the tree.
*** This bug has been marked as a duplicate of bug 578112 ***
*** Bug 578112 has been marked as a duplicate of this bug. ***
Why do we rename bugs!??? If you create a bug "Update Blender to 2.73" and version 2.74 came out - create a new bug and close the old one!!! But do not rename it. Previous comments and patches may have nothing to do with the new title and that's chaotic.
reassigned this bug after one month to co maintainer. Reason: https://bugs.gentoo.org/show_bug.cgi?id=578112#c4
There is a blocker to Blender 2.77a as it needs the the latest opencolorio trunk code otherwise you get a segmentation fault. I will investigate what specific patch it needs to stop the fault. I have a feeling I know what it is. Once I know, I will post a bug report for opencolorio to get that patch in the tree and then this bug will need to depend on that one and that one will block this one. :P I have modified ebuilds for both blender and opencolorio and they work. FYI, the Blender ebuild for 2.77 in the nightmare overlay did not compile 2.77a for me and had to modify it heavily. For now, you can compile Blender with -colorio use flag if you don't need it.
*** Bug 583672 has been marked as a duplicate of this bug. ***
Blender 2.77a requires fixes from opencolorio master branch, so I made an ebuild with a lot of fixes which I submitted here: https://bugs.gentoo.org/show_bug.cgi?id=583890 If you need colorio use flag on blender then you need to read that bug report carefully as there are specific instructions. I have tried this and it works great now with no crashing! The following posts will be the new 2.77a ebuilds. Please try out and report back. Thanks.
Created attachment 435104 [details] blender-2.77a.ebuild
Created attachment 435106 [details] Manifest
Created attachment 435108 [details, diff] files/blender-2.68-doxyfile.patch
Created attachment 435110 [details, diff] files/blender-2.68-fix-install-rules.patch
Created attachment 435112 [details, diff] files/blender-2.77-sse2.patch
Screenshot proof of 2.77a working on my system. http://imgur.com/Fti8zXB With the versions of opencolorio in Gentoo, 1.0.9 and 1.0.9-r1, Blender wouldn't even start because of a segfault on loading the colorio library. Point being, you do need the new version of opencolorio that I linked earlier. My useflags: [ebuild R ] media-gfx/blender-2.77a::misc USE="boost bullet colorio cycles dds elbeem ffmpeg fftw game-engine nls openexr openimageio openmp opennl player sdl tiff -c++0x -debug -doc -jack -jpeg2k -libav -ndof -openal -redcode -sndfile" CPU_FLAGS_X86="sse sse2" PYTHON_SINGLE_TARGET="python3_5 -python3_4" PYTHON_TARGETS="python3_4 python3_5" Enjoy. :)
@Jon Thanks, it works great. I don't use the colorio USE flag so I can't speak for that. As a side note, I wasted some time figuring out it requires Python 3.5 so I would change the line PYTHON_COMPAT=( python3_4 python3_5 ) to PYTHON_COMPAT=( python3_5 )
@Watcom: I mainly use python 3.5, so I completely forgot about that line when I read the dependencies on the Blender page. Sorry about that. There are a few others that need tweaking, so I will fix those later as well. ColorIO does make it a pain, but some people need it, as I read in previous bug reports that are now closed, so I had to get that working. Thanks for testing. :)
Created attachment 435588 [details, diff] Fix for C++0x use flag (missing header in svm.cpp) Blender 2.77 and 2.77a are missing an #include <algorithm.h> in svm.cpp which prevents building with the c++0x use flag. With this patch and Jon's ebuild for 2.77a from Comment #42 I have been able to build and run blender successfully on amd64
Is any of you willing to proxy maintain this? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to Pacho Ramos from comment #52) > Is any of you willing to proxy maintain this? > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers I guess I'm already doing that now. :P Well, many, many years I was invited by a dev to become a dev myself, but life got in the way and just didn't have the time. I'll keep updating the ebuild here. :) And the OpenColorIO ebuild as that seems abanded as well. @Adrian: Thanks for the patch! Though, this was an issue with 2.77, so why they didn't fix it in 2.77a, I'll never know. I use Blender for a 3D course I'm taking, so it's very important to me that Blender is working right.
I will CC proxy maintainers then to assist in the process of officially proxy maintaining blender finally ;) Thanks!
(In reply to Pacho Ramos from comment #54) > I will CC proxy maintainers then to assist in the process of officially > proxy maintaining blender finally ;) > > Thanks! Thanks. :) Just to give an idea of how much work is needed, I made a small todo list with some things that I found on a quick run through, so a more thorough one is needed. ------------- Set min CMake to 3.0.0 OPTIONS: OpenSubDiv - http://graphics.pixar.com/opensubdiv/docs/intro.html OpenVDB Headless (renderfarm) Enable Ocen Mod? Jack/SDL dynamic load? LibMV - Motion tracking Cycles Standalone/GUI Cycles with CUDA (nVida only)/CUDA dynamic load Build with LLVM JEMALLOC? Debug Valgrind support? Check New Internal Depends Listings to Update Required USE Flags. --------------- However, to support some of those new features, some new programs need to be added to the main tree. Thus, would it be better if I finally got around to learning how to use Git properly and made a pull request with all OpenColorIO changes, blender changes, and new ebuilds? Though, if a compile test goes alright, then I'll be attaching a new ebuild with some ebuild cleanups, the C++0x fix and also one more embedded piece of software removed -- LZO is now set to system.
Well, proxy-maint people will tell you their preferred method and workflow... anyway I think that will likely suggest you to work with github pull requests mostly Regarding the new packages that are needed, if they are optional, I would start with updating blender even with some features disabled to avoid the new deps and, later, start adding the new features progressively when you feel ok with maintaining all the new packages
Created attachment 435626 [details] blender-2.77a.ebuild Changelog: Added C++0x compile fix Enabled the use of one more system program, so included version isn't used Started to re-organise the ebuild a bit
Created attachment 435628 [details] Manifest Use this for the correct names and hashes of files used.
Created attachment 435632 [details, diff] blender-2.77-C++0x-build-fix.patch Changed to standard a and b paths for consistency with Gentoo patches. Description box uses the name of patch in the ebuild. Many thanks to Adrian Grigo for the bug report
Building the documentation requires latex and dvips to be installed, ie we should add a dependency on texlive when the doc use flag is specified. The only place it is used is to build a tiny image form_0.png which says Ax=b and is used in /usr/share/doc/blender-2.77a/API/blender/d6/de3/classEigen_1_1ConstrainedConjugateGradient.html
(In reply to Adrian Grigo from comment #60) > Building the documentation requires latex and dvips to be installed, ie we > should add a dependency on texlive when the doc use flag is specified. > > The only place it is used is to build a tiny image form_0.png which says > Ax=b and is used in > /usr/share/doc/blender-2.77a/API/blender/d6/de3/ > classEigen_1_1ConstrainedConjugateGradient.html Is that really the only place latex is used and more specifically, divpsk package, to make that one small image? If so, I think I'd rather have that image pre-made and patch out the use of latex. Then have the doc compiler use the pre-made image. I'm trying to find that usage in the source code now to see what can be done.
Created attachment 435646 [details] blender-2.77a.ebuild Looked it up. Turns out that a lot of documentation needs latex, including doxygen's own. But to compile the docs for Blender, Sphinx needs to be compiled with latex, so I changed the depend on sphinx to have it compiled with latex. No need to hard depend on latex, as this will pull the minimal amount needed for sphinx and doxygen to work right.
Created attachment 435648 [details] Manifest
Created attachment 435650 [details, diff] files/blender-2.77-C++0x-build-fix.patch Forgot to add files/ to the name the first time I uploaded it. I'm a bit OCD.
@Jon Thanks for adding the latex dependency. I can confirm that the ebuild in Comment #62 successfully compiles blender with all use flags enabled (barring libav as I am using ffmpeg)
Created attachment 435712 [details, diff] blender-2.77a-alter-use-flags.patch I have been thinking about the USE flags for blender 2.77a. Some USE flags could be removed: - opennl is no longer used (it is replaced by eigen3 and some code in intern/eigen as per https://developer.blender.org/D1662) - redcode is no longer used in Blender (it has been disabled for a long time and possibly not widely used according to https://developer.blender.org/D1751, the functionality is replaced by ffmpeg as per https://www.blender.org/features/2-77/). Some USE flags could be updated: - debug currently does nothing in the ebuild. It should turn on at least WITH_CXX_GUARDEDALLOC, WITH_ASSERT_ABORT. I am not certain whether it should turn on WITH_CYCLES_DEBUG and WITH_GHOST_DEBUG as well. GHOST_DEBUG prints *every* single mouse event and keypress to the console. This is unlikely to help most users. Blender compiles when enabling CYCLES_DEBUG but currently I need to manually delete and recompile the cuda kernel after enabling or disabling the USE flag to prevent access violations. After this cycles renders successfully I can't see any debug output in the console window, so I have left this out pending further testing Some USE flags could be added easily: - test could turn on the unit tests (WITH_GTESTS). Am I going about this the right way? I tried adding test to package.use but the flag is not set when I emerge blender. I was only able to run the tests after putting FEATURES="test" into make.conf,or using ebuild blender-2.77a test. On my system they take about 4 minutes. - man could create the blender man page (WITH_DOC_MANPAGE) - jemalloc could control the use of jemalloc (WITH_MEM_JEMALLOC). It is actually on by default and Blender will automatically use jemalloc if the dev-libs/jemalloc is installed, but the flag would allow pulling in the dependency and also turning it off when you don't want to use it in blender but need it elsewhere. Enabling/disabling it did not affect my GPU Blenchmark, perhaps it is more useful for larger scenes like Sintel. - valgrind adds support for memory debugging using dev-util/valgrind (WITH_MEM_VALGRIND). This appears to work - blender runs really slowly (the default cube takes 45 seconds instead of 2 seconds and appears to be leaking 80 bytes or so. I am including a patch against the ebuild (at Comment 62) to do the above, and also delete a duplicate line in the ebuild which forces WITH_SYSTEM_LZO on twice.
i am using libav mainly, so it not possible to make libav also working with blender instead of ffmpeg?
@tman It is possible to use this ebuild of blender with libav. I switched to libav by putting the USE flags "libav -ffmpeg" in make.conf and dealt with all the blockers for the other (non-blender related) packages preventing me from updating my system. Then I emerged blender again and it switched to using libav. I was able to render a simple avi animation using it.
@Adrian: If you look up, you took care of most of the todo list I made. :P My first step was to get a working ebuild before going in and tweaking everything. Thanks for your help. @All: Just to warn you, the official Blender page does warn that libav is not supported by the developers, but "should work". If there are bugs against libav, chances are they may not fix them. They use recent versions of ffmpeg, so there may be a time when they diverge. If you noticed in my later ebuild, I changed ffmpeg/libav to an exactly-one-of feature of portage.
Been running into a bit of an issue. I was adding in the official minimal supported versions for dependencies according to this page: https://wiki.blender.org/index.php/Dev:Doc/Building_Blender The official version of OpenEXR that is needed is 2.2.0. However, that is masked. Also, the only version of ImageMagick that supports 2.2 is the 7.x series, which is also masked as it breaks a lot of things. So, ImageMagick 7.x will not be unmasked anytime soon. However, Blender compiles fine against OpenEXR 2.1.x, but it may have quirks that aren't supported. Which means if there's issues, upstream will say to upgrade to OpenEXR 2.2.0. I unmasked the latest versions of those programs and doing a full dependency rebuild against the new upgraded versions. I'll let you know later. Also, in other news, I'm changing the OpenColorIO ebuild to pull from a git revision rather than have a huge patchset. The patchset will be growing, and if you don't delete the files from your distdir, then you just download the new deltas. In case you are wondering, all ebuilds will be here: https://github.com/dracwyrm/gentoo-ebuilds Yep. Dracwyrm (means Dragon Worm in Latin) is me. :P This will allow Pull Requests and easy downloads.
@Jon There is a new ebuild for opencolorio in portage today. It needs a patch (see bug 584654) to properly work under EAPI6. The code looks quite different from the patch you supplied, but I think it was pulled from a more recent git repository. With 1.0.9-r2 installed, blender starts successfully (no segfault), renders and image and allows me to fiddle with all the settings under Color Management, so I think it appears to have fixed the issue.
Created attachment 435932 [details] blender-2.77a.ebuild -Added new features based on Adrians patch -Added minimum version supported by the developers for external dependencies. -Changed depend on OpenColorIO to support the -r2 version now in portage. Will still maintain the patchset one as it has lots more fixes in it, and will be getting some more. :) Now on to adding in the other options as they need ebuilds. Enjoy.
Created attachment 435934 [details] Manifest
(In reply to Adrian from comment #71) > @Jon There is a new ebuild for opencolorio in portage today. It needs a > patch (see bug 584654) to properly work under EAPI6. > > The code looks quite different from the patch you supplied, but I think it > was pulled from a more recent git repository. With 1.0.9-r2 installed, > blender starts successfully (no segfault), renders and image and allows me > to fiddle with all the settings under Color Management, so I think it > appears to have fixed the issue. That one looks like it is strictly YAML fixes, so it will be different than the one I did. It's also based on a previous release of the tarball, as upstream silently updated it a month later. The official supported version of OpenEXR is 2.2, so added that to the new ebuild. That does mean you need this in your unmask folder: # cat /etc/portage/package.unmask/media ~media-libs/ilmbase-2.2.0 ~media-libs/openexr-2.2.0 Then recompile everything that depends on them. I think the imagemagick ebuild was silently updated as it use to have a hard depend on OpenEXR 2.1, but now it doesn't, so all I had to do was recompile it. Most systems will probably have that installed which is why I mention it explicitly. If you have trouble installing OpenEXR/ilmbase, then uninstall those two first. That is the general fix for it.
I will download compile your new ebuild overnight, along with openexr 2.2 and imagemagick. But it is marked as obsolete already - are you planning to send a newer version? I have started working towards an ebuild for opensubdiv and ptex which I have placed on github at https://github.com/redchillipadi/ebuild-overlay Opensubdiv depends upon ptex, and I have created an ebuild for ptex-2.1.10. I still need to fix the installation of the documentation so that multiple versions could be coinstalled if required. I also have created an ebuild for opensubdiv-3.0.5, but it appears that it needs to be based upon the dev rather than master branch from imageworks/opensubdiv to fix problems with correctly identifying the version of ptex since 2.0.62. Currently it compiles with cuda but I need to work out why the regression tests are failing. Once I have done this I will look into basing it on master and incorporating the relevant patches from the dev branch instead. I also haven't tried to compile with opencl or tbb yet. I have since found that there are ebuilds for ptex-2.0.62 and opensubdiv-3.0.3 (as well as openvdb) in the cg overlay, but they did not compile on my system
(In reply to Adrian from comment #75) > I will download compile your new ebuild overnight, along with openexr 2.2 > and imagemagick. But it is marked as obsolete already - are you planning to > send a newer version? > > I have started working towards an ebuild for opensubdiv and ptex which I > have placed on github at https://github.com/redchillipadi/ebuild-overlay > > Opensubdiv depends upon ptex, and I have created an ebuild for ptex-2.1.10. > I still need to fix the installation of the documentation so that multiple > versions could be coinstalled if required. > > I also have created an ebuild for opensubdiv-3.0.5, but it appears that it > needs to be based upon the dev rather than master branch from > imageworks/opensubdiv to fix problems with correctly identifying the version > of ptex since 2.0.62. Currently it compiles with cuda but I need to work out > why the regression tests are failing. Once I have done this I will look into > basing it on master and incorporating the relevant patches from the dev > branch instead. I also haven't tried to compile with opencl or tbb yet. > > I have since found that there are ebuilds for ptex-2.0.62 and > opensubdiv-3.0.3 (as well as openvdb) in the cg overlay, but they did not > compile on my system Hi, The latest one shouldn't be marked as obsolete, unless I checked the wrong box. Anways, it's up on my github. I found a lot of the ebuilds on CG didn't work for me, so I am writing from scratch on some. You may or may not need to reinstall imagemagick, depending on when you installed it, if you have it installed. It was a blocker on my system for OpenEXR 2.2, until I figured out what was happening. :) I'm working on OpenCollada right now. It has some fun issues. The list of Dependencies is growing exponentially.
Created attachment 435960 [details] blender-2.77a.ebuild Added OpenCollada support and it actually compiles. It was removed a while ago because it failed to work. If you use OpenCollada, please test this. NOTE: you need the new version from here: https://bugs.gentoo.org/show_bug.cgi?id=584670 Or, you can just grab these from my github: https://github.com/dracwyrm/gentoo-ebuilds No longer uploading Manifests here since I have them on GitHub. Cheers.
I don't use opencollada but was hoping that it might just work again. Glad to hear that you were able to add it back in. I have run into a bug compiling openexr-2.2, something about inconsistent operand constraints in an 'asm' for cpuid. I thought it might be related to this issue https://github.com/openexr/openexr/issues/128 but the fix there doesn't work for me. Will try again tomorrow.
(In reply to Adrian from comment #78) > I don't use opencollada but was hoping that it might just work again. Glad > to hear that you were able to add it back in. > > I have run into a bug compiling openexr-2.2, something about inconsistent > operand constraints in an 'asm' for cpuid. I thought it might be related to > this issue https://github.com/openexr/openexr/issues/128 but the fix there > doesn't work for me. > > Will try again tomorrow. Did you uninstall ilmbase and openexr first? I didn't need any patches.
can u put this ebuild in portage in offical unstable tree for testing it?
(In reply to tman from comment #80) > can u put this ebuild in portage in offical unstable tree for testing it? There are still several blockers and new features are being added. Still a bit of work to do. You can download it here and put it in an overlay.
(In reply to Jon from comment #81) > (In reply to tman from comment #80) > > can u put this ebuild in portage in offical unstable tree for testing it? > > There are still several blockers and new features are being added. Still a > bit of work to do. You can download it here and put it in an overlay. well if it has blockers i dont use i have enough blockers at the moment :))
(In reply to Jon from comment #79) I did have openexr and ilmbase uninstalled at the time. I think the issue is my make.conf has ABI_X86="32 64". Openexr-2.2.0 compiles under x86_64 but not x86_32. The workaround was to add -x86_32 in the use flags. I have finally been able to build the ebuild from Comment #77 (with collada enabled) and am able to import/export dae files with Blender.
@Jon I have got blender working with opensubdiv, using the latest ebuild for ptex and opensubdiv on my github. Opensubdiv passes all regression tests running manually as root on my system, but I had to disable the osd ones in the ebuild as it wants to create a window. I have now rebased in on the master branch and added a patch to update the changes from the dev branch for finding the ptex version. There are other changes in the dev branch which may allow the tutorials or examples to be built, but for now I have disabled this functionality. Ptex works well, the only thing I want to work out is how to change the documentation folder to include the ptex version name. I am trying to work out how to send you a pull request for the blender ebuild with the opensubdiv changes, but its not working. You can find my latest changes on github also,
(In reply to Adrian from comment #84) > @Jon I have got blender working with opensubdiv, using the latest ebuild for > ptex and opensubdiv on my github. > > Opensubdiv passes all regression tests running manually as root on my > system, but I had to disable the osd ones in the ebuild as it wants to > create a window. I have now rebased in on the master branch and added a > patch to update the changes from the dev branch for finding the ptex > version. There are other changes in the dev branch which may allow the > tutorials or examples to be built, but for now I have disabled this > functionality. > > Ptex works well, the only thing I want to work out is how to change the > documentation folder to include the ptex version name. > > I am trying to work out how to send you a pull request for the blender > ebuild with the opensubdiv changes, but its not working. You can find my > latest changes on github also, You should check my repo. ;) I uploaded ebuilds based on yours. In order for OpenSubdiv to compile for me, I had to copy over the PTex headers to /usr/include. I also updated blender and it compiles with OpenSubdiv 3.0.5. Also, I have you set as a collaborater so you can upload directly to the repo. :)
(In reply to Adrian from comment #84) > @Jon I have got blender working with opensubdiv, using the latest ebuild for > ptex and opensubdiv on my github. > > Opensubdiv passes all regression tests running manually as root on my > system, but I had to disable the osd ones in the ebuild as it wants to > create a window. I have now rebased in on the master branch and added a > patch to update the changes from the dev branch for finding the ptex > version. There are other changes in the dev branch which may allow the > tutorials or examples to be built, but for now I have disabled this > functionality. > > Ptex works well, the only thing I want to work out is how to change the > documentation folder to include the ptex version name. > > I am trying to work out how to send you a pull request for the blender > ebuild with the opensubdiv changes, but its not working. You can find my > latest changes on github also, Also, looking at your patch, you removed the checks for the header files. I installed those files with the updated ptex ebuild. I'll look at your OSD patch, and since I based my ebuild on yours, I need to change the tbb depend. :P
Added a patch to install PtexVersion.h. I must have copied it over manually when finding the cause of the build failure initially and then not realised that it was not being installed subsequently. Hopefully you can get opensubdiv working. I followed the tutorial at http://www.blenderhd.com/tutorial/opensubdiv-blender-2-76/ and sped up the frame rate significantly.
(In reply to Adrian from comment #87) > Added a patch to install PtexVersion.h. I must have copied it over manually > when finding the cause of the build failure initially and then not realised > that it was not being installed subsequently. > > Hopefully you can get opensubdiv working. I followed the tutorial at > http://www.blenderhd.com/tutorial/opensubdiv-blender-2-76/ and sped up the > frame rate significantly. OpenSubdiv fully installs and I have: /usr/lib/libosdCPU.a /usr/lib/libosdCPU.so -> libosdCPU.so.3.0.5 /usr/lib/libosdCPU.so.3.0.5 /usr/lib/libosdGPU.a /usr/lib/libosdGPU.so -> libosdGPU.so.3.0.5 /usr/lib/libosdGPU.so.3.0.5 But, Blender isn't picking it up. I'll look at it tomorrow when I have time.
To keep you guys updated: I was working on the OpenVDB ebuild today. It was a pain in the rear end. It compiles, but the python module installs to the wrong place, so that needs to be looked at. I hadn't enabled the support in Blender because of the python issue. The ebuild is also getting Python 2.7 support. I had to rewrite a ton of it to be more compliant with new standards. As they say: Get one thing working before moving on to the next thing. Also, OpenSubdiv installs, but Blender can't find it, so you can't enable it. If anyone wants to help, I have two bug reports open on my Github and all the ebuilds are there as well. If you can spot the errors, I would really appreciate it. https://github.com/dracwyrm/gentoo-ebuilds Peace.
We are getting close to submitting the ebuilds to Gentoo, so we need lots of compile tests done. So, here they are: https://github.com/dracwyrm/gentoo-ebuilds Please report back if they work and what use flags you tried, so we know if they are good for peer review. Thanks.
Preliminary documentation for blender 2.77a is now on the gentoo wiki. Please see the page linked to in the note at the top of https://wiki.gentoo.org/wiki/Blender to read about the new features available. Additional testing and submitting bug reports prior to submission for peer review would be greatly appreciated. Thank you for your help.
I tried the ebuild using increasingly more USE flags as follow: +player +ffmpeg fftw jack jpeg2k man openal sdl sndfile +c++11 valgrind +colorio openimageio +cycles +cuda +opensubdiv +openvbd openvdb-compression It all compiled fine and blender runs with any of the above without an immediate crash. I don't work much using the binary so far, so I can't say anything more meaningful about it's stability. I tried adding the osl USE flag, but it would have pulled in llvm-3.5.0 and my system already has llvm.3.7.1-r2 installed, which I wouldn't downgrade. openvdb pulls in dev-libs/log4cplus-1.1.2 as a DEPEND, but it really needs in RDEPEND. I'm usually using --with-deps=n, so a depclean after update wants to unmerge log4cplus, which leaves broken openvdb binaries: !!! existing preserved libs: >>> package: dev-libs/log4cplus-1.1.2 * - /usr/lib64/liblog4cplus-1.1.so.9 * - /usr/lib64/liblog4cplus-1.1.so.9.0.0 * used by /usr/bin/vdb_print (media-gfx/openvdb-3.1.0) * used by /usr/bin/vdb_render (media-gfx/openvdb-3.1.0) * used by /usr/bin/vdb_view (media-gfx/openvdb-3.1.0) * used by 4 other files Hope this helps continuing your good work :)
Umm... missed the collada USE flag. It was added in a compile between the c++11/valgrind and the colorio/openimageio USE flags. And together with openvdb I also added the jemalloc USE flag, because it get's pulled in by openvdb anyway.
For me it doesn't find the system Eigen headers, i.e. #include <Eigen/Core> fails Probably there should be an -I /usr/include/eigen3 somewhere.
(In reply to Helmut Jarausch from comment #94) > For me it doesn't find the system Eigen headers, i.e. > #include <Eigen/Core> fails > > Probably there should be an -I /usr/include/eigen3 somewhere. Strange. Works for me: -- Found Eigen3: /usr/include/eigen3
are u done with the work and can put it now in portage?
(In reply to tman from comment #96) > are u done with the work and can put it now in portage? It's getting peer reviewed. :) There were a lot of changes and additions.
blender 2.77a needs: media-libs/openexr-2.2 but this fails at installing : lmImfUtil/ImfImageIO.cpp libtool: compile: x86_64-pc-linux-gnu-g++ -m32 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil -I../config -pthread -I/usr/include/OpenEXR -I.. -I/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImf -I/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/config -pipe -march=core-avx-i -O2 -pipe -c /var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil/ImfDeepImage.cpp -fPIC -DPIC -o .libs/ImfDeepImage.o make[1]: *** [Makefile:381: ImfImage.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... libtool: compile: x86_64-pc-linux-gnu-g++ -m32 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil -I../config -pthread -I/usr/include/OpenEXR -I.. -I/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImf -I/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/config -pipe -march=core-avx-i -O2 -pipe -c /var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil/ImfImageIO.cpp -fPIC -DPIC -o .libs/ImfImageIO.o /var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil/ImfImageIO.cpp: In function ‘Imf_2_1::Image* Imf_2_1::loadImage(const string&, Imf_2_1::Header&)’: /var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil/ImfImageIO.cpp:96:65: error: no matching function for call to ‘isOpenExrFile(const char*, bool&, bool&, bool&)’ if (!isOpenExrFile (fileName.c_str(), tiled, deep, multiPart)) ^ In file included from /var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0/IlmImfUtil/ImfImageIO.cpp:46:0: /usr/include/OpenEXR/ImfTestFile.h:54:17: note: candidate: bool Imf_2_1::isOpenExrFile(const char*, bool&) IMF_EXPORT bool isOpenExrFile (const char fileName[], bool &isTiled); ^ /usr/include/OpenEXR/ImfTestFile.h:54:17: note: candidate expects 2 arguments, 4 provided /usr/include/OpenEXR/ImfTestFile.h:55:17: note: candidate: bool Imf_2_1::isOpenExrFile(const char*) IMF_EXPORT bool isOpenExrFile (const char fileName[]); ^ /usr/include/OpenEXR/ImfTestFile.h:55:17: note: candidate expects 1 argument, 4 provided /usr/include/OpenEXR/ImfTestFile.h:57:17: note: candidate: bool Imf_2_1::isOpenExrFile(Imf_2_1::IStream&, bool&) IMF_EXPORT bool isOpenExrFile (IStream &is, bool &isTiled); ^ /usr/include/OpenEXR/ImfTestFile.h:57:17: note: candidate expects 2 arguments, 4 provided /usr/include/OpenEXR/ImfTestFile.h:58:17: note: candidate: bool Imf_2_1::isOpenExrFile(Imf_2_1::IStream&) IMF_EXPORT bool isOpenExrFile (IStream &is); ^ /usr/include/OpenEXR/ImfTestFile.h:58:17: note: candidate expects 1 argument, 4 provided make[1]: *** [Makefile:381: ImfImageIO.lo] Error 1 make[1]: Leaving directory '/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0-abi_x86_32.x86/IlmImfUtil' make: *** [Makefile:382: all-recursive] Error 1 * ERROR: media-libs/openexr-2.2.0::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=media-libs/openexr-2.2.0::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-libs/openexr-2.2.0::gentoo'`. * The complete build log is located at '/mnt/portage/logs/media-libs:openexr-2.2.0:20160828-195852.log'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/openexr-2.2.0/temp/environment'. * Working directory: '/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0-abi_x86_32.x86' * S: '/var/tmp/portage/media-libs/openexr-2.2.0/work/openexr-2.2.0'
@tman - I had trouble with the openexr package on a multilib system previously where it would compile with the x86_64 ABI but not x86_32. Could you please recompile after adding media-libs/openexr -abi_x86_32 to /etc/portage/package.use or after adding my patch from https://bugs.gentoo.org/show_bug.cgi?id=585846 to /etc/portage/patches/media-libs/openexr This is partly dependent on changes to gcc after 4.3. Which version do you have installed? Please let me know if this allows you to successfully compile openexr. If not then could you please open a new bug for media-libs/openexr and include the full build log and emerge --info and I will compare it to mine.
@tman - I found my old build log and my old error looks different to yours. So please file a new bug report and I will help to look into it.
These are my USE flags that work: [ebuild R #] media-libs/openexr-2.2.0:0/22::gentoo USE="-examples -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB [ebuild R ] media-gfx/blender-2.77a::misc USE="boost bullet collada colorio cycles dds elbeem ffmpeg fftw game-engine nls openexr openimageio openmp openvdb openvdb-compression player sdl tiff -cuda -debug -doc -headless -jack -jemalloc -jpeg2k -libav -llvm -man -ndof -openal -opencl -opensubdiv -osl -sndfile {-test} -valgrind" CPU_FLAGS_X86="sse sse2" PYTHON_TARGETS="python3_5" 0 KiB I cannot reproduce that error and I'm not using any extra patched packages, just default ones in portage, well, except for Blender of course. :D @Adrian, I uploaded another patch to your OpenEXR bug report. Would you be able to look at it? It was added to upstream master post release to fix 32 bit compiling. https://585846.bugs.gentoo.org/attachment.cgi?id=444376
@tman - I was able to reproduce your problem when trying to upgrade to openexr-2.2.0 when openexr-2.1.0 and ilmbase-2.1.0 were installed. I followed Jon's suggestion in commment 74 and was able to fix this by unmerging openexr and ilmbase first and then emerging them again. Hopefully this will help you.
(In reply to Adrian from comment #102) > @tman - I was able to reproduce your problem when trying to upgrade to > openexr-2.2.0 when openexr-2.1.0 and ilmbase-2.1.0 were installed. I > followed Jon's suggestion in commment 74 and was able to fix this by > unmerging openexr and ilmbase first and then emerging them again. Hopefully > this will help you. Oh yeah. Forgot about that solution. The issue is that OpenEXR 2.2 is linking against the already installed old versions somehow. That really needs to be fixed.
well i have tested it. compilation through >>> /usr/share/blender/2.77/scripts/templates_py/gamelogic_simple.py >>> /usr/share/blender/2.77/scripts/templates_py/operator_modal.py >>> /usr/share/blender/2.77/scripts/templates_py/operator_modal_timer.py >>> /usr/share/blender/2.77/scripts/templates_py/ui_list.py >>> /usr/share/blender/2.77/scripts/templates_py/ui_panel.py >>> /usr/share/blender/2.77/scripts/templates_py/ui_previews_custom_icon.py >>> /usr/share/blender/2.77/scripts/templates_py/ui_pie_menu.py >>> /usr/share/blender/2.77/scripts/templates_py/operator_file_import.py >>> /usr/share/blender/2.77/scripts/templates_py/batch_export.py --- /usr/bin/ >>> /usr/bin/blender-thumbnailer.py >>> /usr/bin/blenderplayer >>> /usr/bin/blender * * Blender uses python integration. As such, may have some * inherit risks with running unknown python scripts. * * It is recommended to change your blender temp directory * from /tmp to /home/user/tmp or another tmp file under your * home directory. This can be done by starting blender, then * dragging the main menu down do display all paths. * * * This ebuild does not unbundle the massive amount of 3rd party * libraries which are shipped with blender. Note that * these have caused security issues in the past. * If you are concerned about security, file a bug upstream: * https://developer.blender.org/ * * Updating icons cache ... [ ok ] * Updating desktop mime database ... >>> media-gfx/blender-2.77a merged. >>> Regenerating /etc/ld.so.cache... >>> Recording media-gfx/blender in "world" favorites file... >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news read to view new items.
Blender 2.78 is out! https://www.blender.org/features/2-78/
(In reply to Jura from comment #105) > Blender 2.78 is out! > https://www.blender.org/features/2-78/ Yeah. Took ages for them to release it as it's been in Beta for a long time. I'm going through the CMake files to make sure everything is correct. They changed some things. :)
New ebuilds for Blender 2.78! I tried fixing several bugs listed here in b.g.o. There's no long manual SIMD selection as Blender's build system has it so spread out that it's nearly impossible to patch. It actually has support for more than just sse and sse2. This will all be detected for you and optimized to the full ability. Removed some patches and made sed/compile switches out of them. Blender and co now use C++11 against the new Boost 1.62 package. NOTE: You need a package.accept_keywords file with this in it: ~dev-libs/boost-1.62.0 ** ~dev-util/boost-build-1.62.0 ** And prepare for mass rebuild. Boost 1.62 will fix tons of packages failing due to ABI incompatibility, so it's the future of Gentoo. Had to drop OSL support until I can get it properly tested with Boost. I need to use my Dev VM as I can't use my main system do to new versions of LLVM being needed for radeon drivers. There's some other tweaks as well. Happy compiling. :)
Where new ebuild for blender? ;)
(In reply to Jura from comment #108) > Where new ebuild for blender? ;) I keep all the ebuils on my Github as they are being peer-reviewed for inclusion into Portage: https://github.com/dracwyrm/gentoo-ebuilds I uploaded new OSL ebuilds and re-enabled OSL support in Blender. Please test this. I tried and it seems to not do much for me. Though, it doesn't crash Blender which is good. The OSL 1.8.2 Pre has patches to make it work for LLVM 3.8 and maybe 3.9. The more stable 1.7.4 only works with LLVM less than 3.6. Also, both OSL versions depend on Boost 1.62 as they need to be compiled with C++11 support (required by upstream), so they would fail to build against the old Boost versions since they were ABI 98. There is a new OpenImageIO version included as well that I will submit to the graphics project after a bit more testing. Happy rendering.
I plan on putting through the PR for these ebuilds. Does anyone have any issues with Blender 4.8, OpenVDB 3.2, OpenSubDiv 3.0.5, or Ptex 2.1.28? Thanks.
Excellent job, works flawlessly - even with collada, colorio, openimageio USE flags. Thank you!
This is now in portage with commit cb021f3026afbe8c0acf42de427b209b72e69dc3 Thanks to all those that have tested and reported back on the new ebuild.
