Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 689740 - media-gfx/blender-2.83.1: version bump
Summary: media-gfx/blender-2.83.1: version bump
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 8 votes (vote)
Assignee: Adrian
: 733642 (view as bug list)
Depends on: 696582 696592 717564 721682
Blocks: 733500
  Show dependency tree
Reported: 2019-07-12 17:15 UTC by Bernardo Meurer
Modified: 2020-08-24 13:42 UTC (History)
37 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Bernardo Meurer 2019-07-12 17:15:42 UTC
The new, massive, 2.80 RC[1] is out, it'd be  nice to have it packaged for testing.

Comment 1 Jonas Stein gentoo-dev 2019-07-12 17:33:36 UTC
"Blender 2.80 is almost ready! The stable release will be available in the coming days.
A Release Candidate is the final step before the release."

Thank you for the bump request, but please wait at least 48h (past release!) next time.
Comment 2 Bernardo Meurer 2019-07-15 18:23:44 UTC
Hi Jonas,

I wasn't aware of the 48h rule, won't happen again :)

Comment 3 James Chew 2019-08-04 05:08:02 UTC
Blender 2.80 has been released on 30 Jul, ~5 days ago.

Requesting version bump please.
Comment 4 Adrien Tougas 2019-08-08 03:28:28 UTC
Seconding version bump request.
Comment 5 Adrian 2019-08-11 19:53:56 UTC
Please see the initial ebuild for blender 2.80 at for testing.

It requires python 3.7 to be unmasked on the system (see
If used, media-gfx/openvdb also needs to support python 3.7, see the modified version at the same github site.

The gameengine and player USE flags have been removed as blender2.80 no longer supports them.
Alembic support has been added (with the new alembic USE flag, as per bug 667352)
Comment 6 Adrien Tougas 2019-08-12 19:17:44 UTC
I was working on my own version of an ebuild and noticed that dev-python/numpy also needed to be rebuilt for python3_7 as well.
Comment 7 Bernd 2019-08-13 18:06:20 UTC
Thanks for your work Adrian. I too war working on an ebuild for blender-2.80 and have some feedback on yours in addition to comment #6:

* Blender can use openjpeg:2, while the ebuild depends on openjpeg:0. If both slots are installed, it linked against /usr/lib64/ (openjpeg:2) on my test.
* What I have seen so far, python support for openvdb isn't needed. The binary links against but I haven't found a trace, that it's using the python bindings of openvdb. Are you sure about the need for python 3.7 with openvdb?
* According to the output of build_files/build_environment/ --show-deps, blender needs updated opensubdiv (3.4.0) and opencollada (1.6.68) libraries, which are currently not in the tree. I have ebuilds for both in my overlay, if you're interested in integrating those. I tested my build with those updated versions installed, but not with the current in-tree version, so I don't know whether those build and/or run.
* The USE flag colorio should be renamed to color-management, to reflect a recent global change in this USE flag.
* Do you have plans in adding support for currently unsupported features, like draco, embree or a cycles standalone build? For draco and embree, I have ebuilds in my overlay, but both features come with some issues. Draco needs -DWITH_PYTHON_INSTALL=ON defined and embree currently needs a specific setting and be compiled as a static library which my ebuild in its current state isn't able to do. I'm looking into updating the ebuild, and add USE flags to be able to get the desired configuration, but it eventually can interfere with other packages depending on embree in the future. I you want to work on integrating those feature, feel free to ping me anytime if you wish.
* Blender can currently not be installed on a stable tree, due to dev-python/requests having python_targets_python3_7 still masked:

emerge: there are no ebuilds to satisfy "dev-python/requests[python_targets_python3_7(-)?,-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-),python_single_target_python3_7(+)]".
(dependency required by "media-gfx/blender-2.80::dracwyrm" [ebuild])
(dependency required by "=blender-2.80::dracwyrm" [argument])

I have tried to build blender in a ~amd64 chroot environment and it did build without problems with the following USE flags:

(chroot64) artus /var/db/repos/dracwyrm/media-gfx/blender # emerge -pqv =blender-2.80::dracwyrm
[ebuild   R   ] media-gfx/blender-2.80  USE="alembic bullet collada colorio cuda cycles dds elbeem ffmpeg fftw jack jemalloc jpeg2k llvm ndof nls openal openexr openimageio openmp opensubdiv openvdb osl sndfile tiff -debug -doc -headless -libav -man -opencl -sdl -test -valgrind" PYTHON_TARGETS="python3_7"
Comment 8 Adrian 2019-08-16 00:26:01 UTC
Thank you Adrien and Bernd for your feedback.

On my systems, when I unmasked python 3.7 and emerged blender, I found that numpy was rebuilt automatically. The stable version of numpy already includes python 3.7 compatibility in the ebuild. Did you have any issues getting numpy to rebuild?

I found that openvdb still worked without the python bindings, this is probably also true for blender 2.79. I was unable to crash the smoke simulation and dae file import/export using the in tree versions of openvdb and opencollada. However I have upgraded to the versions in your repository, Bernd, to match the minimum requirements reported by As well as those that you mentioned, I think that c-blosc also needs to be updated for openvdb.

I am interested on adding support for draco, embree and cycles standalone. With those features integrated, almost all of the flags from cmake will be exposed to the USE flag system to allow the user to completely customise their installation.

So far I have just added USE flags and checked it compiles, but it will take more time to get them to work. I am trying to find documentation of the xml format for cycles standalone to build a test case.

Blender has always been on the forefront with regards to python versions. I think stabilisation of blender 2.80 will be blocked for some time waiting on python 3.7.

Rather than pollute Jonathan's repository further with a large influx of new packages, I will continue development efforts in my own repository at
Comment 9 Bernd 2019-08-18 12:25:37 UTC
Adrian, regarding my comment on requests, I didn't mean to stabilize blender. I'm well aware, this will probably take some time. In fact this comment wasn't even meant to be targeted to you, it refers to stabilize dev-python/requests for use with python-3.7, which IMO isn't trivial, because of dependencies on sphinx and some other base python packages. But it would enable the installation of blender on mostly stable system, by unmasking it, which isn't currently possible. But this is not due to your blender ebuild.

I've updated my draco ebuild a little bit. I'm trying to improve it further and adding support for missing features. I've also updated my embree ebuild, but then noticed you had it updated in your repo too.

As for c-blosc dependency of openvdb. We don't need it to be updated. In fact, according to we should it downgrad to c-blosc-1.5*, which isn't available anymore in Gentoo. But as openvdb compiles with 1.11.2 I think we can use this version.

A note on abi4-compat USE flag. IMHO this flag is also not needed for blender-2.80. They disable abi3-compat explicitly with cmake, but according to script, depend on openvdb-5.1.0. If you take a look in build_files/build)environment/cmake/openvdb.cmake, you notice they don't explicitly ask for OpenVDB ABI 4 (by using -DOPENVDB_ABI_VERSION_NUMBER=4), thus the openvdb build system is using ABI 5 instead.

I think, the dependecy string on embree should also list -ispc and -tutorial. The cmake snippet in build_files/build_environment/cmake/embree.cmake explicitly disables those features. Note, that they also restrict the EMBREE_MAX_ISA option to be equal to AVX2, while embree automatically determines the highest available ISA according to the processor it is built on. I don't think it will hurt, if higher ISAs are built, they IMO only produce additional static libraries, but I'm thinking of re-adding the CPU_FEATURES, so it'd be possible to pass this flag too.
Comment 10 Adrian 2019-09-13 06:25:46 UTC
Adding USE flags for openvdb api version 5 (and presumably 6 down the track) forced me to rethink the naming convention. With more versions, the current method of assuming that ABI 5 will be used when ABI 3 and 4 are turned off will no longer work. Blender and openvdb both need the same flag set which explicitly selects the openvdb ABI to compile. I think the abiX-compat USE flags would be clearer if changed to openvdb_abi_X instead. This shows that they refer to openvdb instead of blender. It also avoid the use of compat in the flag for the current version. I feel that compat should only apply to legacy versions. Openvdb currently fails the raymask tests on my machine.

I have looked at backporting as much as possible to blender 2.79, as I feel that with the massive changes to the UI and breaking compatibility with old addons some users may not want to upgrade for some time. While earlier versions of blender may have had experimental support for ABI 3, both blender 2.79 and 2.80 require at least ABI 4 as they require copyGridWithNewTree. While blender 2.80 can use opencollada 1.6.68, blender 2.79 does not implement the new virtual function in its subclass of the opencollada writer and is forced to use 1.6.63.

I want to minimise the demands blender makes on embree to prevent interference with future packages. Otherwise blender with openvdb will prevent any packages using embree with ispc from being installed at the same time. It appears that allowing the user to choose to enable tutorial and ispc does not prevent blender from using the embree library. The tutorials are stored in /usr/build/embree3, and ispc provides an additional api rather than removing the old one. Perhaps they are only disabled upstream to reduce the build size.

The current version of ispc in the tree does not build with clang 6 or 7, so if ispc is permitted, then embree will require a later version of ispc in the tree, such as 1.11 from your repository. Embree does appear to work with blender with ipsc and tutorials enabled, although the tutorials themselves do not run as they are unable to open a display on my machine.

I have confirmed that bug #680624 (the polyfill2d.IssueT40777_colinear test failure) also applies to my 2.80 ebuild so this is something else that needs to be fixed before these changes will be ready to merge.
Comment 11 Oleg 2019-11-26 21:01:22 UTC
Blender 2.81 is out!
Comment 12 Adrian 2020-01-08 15:47:42 UTC
Update to 2.81a is in my repository. There is still some work to do getting draco and embree packaged before it will be ready for the tree
Comment 13 Oleg 2020-02-20 05:28:27 UTC
Looks like 2.82 is out as well
Comment 14 Adrian 2020-02-20 07:50:20 UTC
I have an ebuild for 2.82 in my repository. It compiles, but I am still testing the new Mantaflow and USD features.

For example when I followed and tried to use FLIP the physics settings were greyed out.

I am still trying to confirm whether these are bundled libraries or whether I will need to add create packages for them.
Comment 15 PF4Public 2020-05-06 21:28:29 UTC
What are the chances of having recent blender in main tree?
Comment 16 Marian Kyral 2020-05-08 05:55:34 UTC
Hope soon as this ebuild requires obsolete Python 3.6.
Comment 17 Adrian 2020-05-08 06:49:00 UTC
Here is an update on where things are at currently:

To meet the requirements for blender 2.82a, it is necessary at minimum to update to opencollada-1.6.68, opensubdiv-3.4.0, alembic-1.7.12 and openvdb-7.0.0 first.

But to take advantage of all of the new features in blender, I would also like to push new packages for draco, embree, usd and oidn which will require an update to ispc.

To ensure a single ABI is compiled for openvdb across multiple packages, I am preparing an eclass to control the version used by blender and openvdb. This will be required when updating to openimageio-2 and introducing usd.

I also plan to update other dependencies to the latest versions including opencolorio, osl, c-blosc, field3d, partio, ptex, and openimageio which will require a new package robin-map. These do not block the ebuild in my repository and are a lesser priority.
Comment 18 Nils Freydank 2020-05-08 11:29:12 UTC
Thanks to all involed for your effort bumping this monster! Please file bugs against all other packages and add them as blockers (either here as "depends on" or in the other bug reports as "blocks".

That way it will be more visible which tasks are urgent.
Comment 19 Adrian 2020-06-04 00:07:47 UTC
Blender 2.83.0 LTS is out today, and I will focus all effort into getting this into the tree.

The main blocker at the moment is getting feedback on my openvdb eclass proposal, as the decision will affect the ebuilds for openvdb, blender and openimageio packages.

Once the openvdb eclass proposal is decided I have a PR ready to submit for openvdb, and PR for opencollada, opensubdiv and alembic are currently under review. These are the minimum set of packages which need updating before I can submit a PR for blender.

The new packages required to take advantage of all the features are embree 3.8, draco, oidn and usd, and now openxr-sdk which is new to this version of blender. Ispc will also need updating

As far as python support goes, blender follows the vfx reference platform (CY2020) and so will only officially support python 3.7 until the end of this year. This is to ensure that all user developed plugins are not affected by python upgrades. I expect they will upgrade to python 3.8+ in 2021 which is in keeping with the revised draft timeline for python deprecation in Gentoo. 

I have an ebuild for 2.83.0 in my repository which compiles and renders on my system.
Comment 20 PF4Public 2020-06-04 12:15:31 UTC
Thanks for keeping us informed!
Comment 21 Guillaume BRUN 2020-06-27 18:21:25 UTC

I know it'll be ready when it's ready, but we (the Gentoo graphics community) have been crippled by the lack of Portage-available 2.8x Blender releases for way too long.

As a reminder, this bug starts with "Blender 2.80 is almost ready! The stable release will be available in the coming days." in July 2019 (almost a year ago now).

I would like to point out (as Sam James suggested) that we don't really need to get everything perfectly right yet. It's way more important (and urgent!) to get any 2.8x release out and let users help us iron out the kinks, than trying to get it right the first time. For example, if we need to require aggressive dependencies for 2.8x, so be it ; forcing people to opt-out of older versions of dependencies sounds like a perfectly acceptable compromise.

In the same vein, I feel like the slotted openvdb idea could get going much faster than the eclass. If the issue is "static + dynamic core libraries + python libraries + vdb_print for Cmake", maybe a combination of slots/USE or even splitting the package could be a working (temporary or not) solution. I'm absolutely talking out of my arse on that specific issue, and I realize the reason you came to this conclusion is because the situation is complicated, Adrian.

I would merely like to voice the accumulating frustration of yours truly (and likely other members of the Gentoo gfx community) about the lack of a good Blender 2.8x option on Gentoo.

FYI, openusd/oidn/ispc are all broken in ::cg overlay right now, vastly limiting our options. I have spent the afternoon (and I'm not done...) trying to get them to work, but right now, no Blender2.8 for me :-(.

Sorry for the rant, and thanks for your hard work. If there's anything I can do to help, please do keep me in touch.

Comment 22 Jason Lethbridge 2020-06-28 08:51:53 UTC
2.83.1 has been released. It is a bug-fix release so I'm guessing there's no change to dependencies or building process from 2.83.0
Comment 23 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-07-23 13:29:35 UTC
*** Bug 733642 has been marked as a duplicate of this bug. ***
Comment 24 Dennis Schridde 2020-07-23 15:49:22 UTC
Version 2.83.3 is the latest bugfix release, but there seems to be no separate announcement for it:

Comment 25 gerion 2020-08-10 23:44:48 UTC
Found another overlay with blender 2.83.4:
Comment 26 Larry the Git Cow gentoo-dev 2020-08-24 13:42:28 UTC
The bug has been closed via the following commit(s):

commit cca9b716491a91b496106a19df4e5f554b6a1717
Author:     Adrian Grigo <>
AuthorDate: 2020-08-22 01:08:55 +0000
Commit:     Sam James <>
CommitDate: 2020-08-24 13:41:55 +0000

    media-gfx/blender: Version bump to 2.83.4
    Blender 2.83.4 works with python 3.7. It may compile with 3.8, but
    blender only supports 3.7 officially as it follows the VFX Reference
    Platform to ensure that user add ons are not broken in the process.
    They plan to introduce 3.8 support in 2021.
    New features include a new interface, the realtime eevee renderer,
    and importing openvdb files created by other packages among others.
    Game engine and Blender Player were removed in 2.80.
    Bug fixes in this version are alembic support, upstream fixes for
    opencollada, requiring openjpeg:2 to avoid security issues, and
    mimeinfo cache is correctly updated. Where these issues remain in
    blender 2.79b, the bug is linked but should be closed only when
    blender 2.79b is removed.
    On my system the docs do not currently compile,
    and the polyfill2d test still fails like 2.79b.
    Blender 2.83 support for draco, embree, oidn, usd and openxr is not yet
    implemented pending development of ebuilds for these packages.
    Signed-off-by: Adrian Grigo <>
    Package-Manager: Portage-2.3.103, Repoman-2.3.23
    Signed-off-by: Sam James <>

 media-gfx/blender/Manifest                         |   1 +
 media-gfx/blender/blender-2.83.4.ebuild            | 316 +++++++++++++++++++++
 .../blender/files/blender-fix-install-rules.patch  |  16 --
 media-gfx/blender/metadata.xml                     |  22 ++
 4 files changed, 339 insertions(+), 16 deletions(-)