| Summary: | media-gfx/blender-2.83.1: version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bernardo Meurer <bernardo> |
| Component: | Current packages | Assignee: | Adrian <agrigo2001> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 0x0065, agrigo2001, anton.wd, chain, citizen, dracwyrm, dronx.wow+gentoo, dschridde+gentoobugs, fasteddie05, fordfrog, gentoo, gentoo, graphics+disabled, holgersson, hyedad, james05+gentoo, jeremias, jiayewuw, jj, jstein, kaikaikai, kripton, lethbridgejason, Martin.Jansa, me, mkyral, O01eg, PF4Public, pi314, proxy-maint, remexre, richard.kenney, sam, tougasadrien, triffid.hunter, waebbl-gentoo, wdiazux |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 696582, 696592, 717564, 721682 | ||
| Bug Blocks: | 733500 | ||
|
Description
Bernardo Meurer
2019-07-12 17:15:42 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. https://wiki.gentoo.org/wiki/Zero-day_bump_requests Hi Jonas, I wasn't aware of the 48h rule, won't happen again :) Cheers. Blender 2.80 has been released on 30 Jul, ~5 days ago. Requesting version bump please. Seconding version bump request. Please see the initial ebuild for blender 2.80 at https://github.com/dracwyrm/gentoo-ebuilds for testing. It requires python 3.7 to be unmasked on the system (see https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS). 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) 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. 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/openjp2.so (openjpeg:2) on my test. * What I have seen so far, python support for openvdb isn't needed. The binary links against libopenvdb.so.5.2 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/install_deps.sh --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" 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 install_deps.sh. 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 http://github.com/redchillipadi/ebuild-overlay.git 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 https://www.openvdb.org/documentation/doxygen/dependencies.html#depDependencyTable 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 install-deps.sh 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. 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. Blender 2.81 is out! https://www.blender.org/download/releases/2-81/ 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 Looks like 2.82 is out as well https://www.blender.org/download/releases/2-82/ 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 https://www.youtube.com/watch?v=PXkPrQpaAb0 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. What are the chances of having recent blender in main tree? Hope soon as this ebuild requires obsolete Python 3.6. 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. 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. 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. Thanks for keeping us informed! Hello, 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. Thanks! 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 *** Bug 733642 has been marked as a duplicate of this bug. *** Version 2.83.3 is the latest bugfix release, but there seems to be no separate announcement for it: * https://www.blender.org/press/blender-2-83-release/ * https://www.blender.org/press/blender-2-83-1-lts/ Found another overlay with blender 2.83.4: https://github.com/iDarkTemplar/dt-overlay-patches/tree/master/media-gfx/blender The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cca9b716491a91b496106a19df4e5f554b6a1717 commit cca9b716491a91b496106a19df4e5f554b6a1717 Author: Adrian Grigo <agrigo2001@yahoo.com.au> AuthorDate: 2020-08-22 01:08:55 +0000 Commit: Sam James <sam@gentoo.org> 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 <agrigo2001@yahoo.com.au> Bug: https://bugs.gentoo.org/667352 Bug: https://bugs.gentoo.org/735590 Bug: https://bugs.gentoo.org/718772 Closes: https://bugs.gentoo.org/737388 Closes: https://bugs.gentoo.org/689740 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Sam James <sam@gentoo.org> 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(-) |
