Project

General

Profile

Packaging Request #3268

Freedom Issue #3229: [blender] Various issues

[blender] Update package to 3.1.2

Zuss - 5 months ago - . Updated 3 months ago.

Status:
in progress
Priority:
bug
Assignee:
-
% Done:

100%


Description

I've updated the PKGBUILD and addressed some concerns in issue #3229

The most notable changes from the current packaged version (2.93) is that Blender dropped support for OpenCL in favour of AMD HIP. This only supports newer GPUs which a general list can be found here: https://community.amd.com/t5/knowledge-base/amd-rocm-hardware-and-software-support-document/ta-p/489937
Currently AMD HIP isn't available on GNU/Linux, with support being planned in future Blender versions, related bug report: https://developer.blender.org/T91571#1291811
HIP is under the MIT license: https://github.com/ROCm-Developer-Tools/HIP

As for the issue of CUDA/OptiX libraries still floating around, they seem to be never loaded as long as the build flags to disable them are set. Regardless, I've added a patch to remove CUDA/OptiX as well as Metal just for completeness. Blender seems to work fine on a few projects I've opened and no issues crop up in relation to them being removed. Any remaining references to CUDA/OptiX/Metal are just informational UI changes or functions that only work if the libraries have been loaded. It may not be necessary to add the patch, the option is there if you wish to include it.

Currently there is an issue with Draco and exporting glTF files with compression, to which I've added a patch from Arch's PKGBUILD.

32 Bit support has been dropped since v2.80 and I currently get issues when trying to build on i686 with libretools. Hence only x86_64 support is included.


Files

PKGBUILD (4.58 KB) PKGBUILD Blender-3-1-2 Zuss, 2022-05-05 06:13 AM
remove-cuda-optix-metal.patch (18.6 KB) remove-cuda-optix-metal.patch Zuss, 2022-05-05 06:13 AM
force-draco1.patch (536 Bytes) force-draco1.patch Zuss, 2022-05-05 06:13 AM
force-draco2.patch (836 Bytes) force-draco2.patch Zuss, 2022-05-05 06:14 AM

History

#1

Updated by bill-auger 5 months ago

As for the issue of CUDA/OptiX libraries still floating around,
they seem to be never loaded as long as the build flags to
disable them are set.

i do not believe that any non-free libraries are "floating
around" parabola - generally, those features are implemented as
linked libraries; and the code for those libraries is not in the
source code being compiled - the code for those libraries is in
a separate package; and a package like blender includes those
external packages in the depends=() array; so that they get
installed along with blender

setting the build flags like USE_CUDA=NO, only makes the build
ignore it's own code which would use the external library - that
code itself is usually totally libre - the fact that it can
link to a non-free library, does not make that code non-free -
at least that is how i understand the FSF's opinion

if compiled without that flag, and if that library is not
present on the machine running the main program, the main
program will usually fail to start - that is the reason why the
parabola PKGBUILD will set some flag like USE_CUDA=NO; because
the 'cuda' libraries are not available from parabola, so they
would not be present

the main point to consider, is that this is not done in order to
prevent people from using cuda - it is done so that the program
will run without cuda being present on the system

we do not need to prevent people from using non-free software;
and we do not need to remove mere references to non-free
software - we would only need to remove explicit
recommendations, suggestions, or assistance to install non-free
software

https://wiki.parabola.nu/Degrees_of_Non-Free_Software_Tolerance

i am generally against those are the sort of changes; because
they increase the workload of maintaining the package
those sort of patches are very likely to need re-working often -
additionally, new references are likely to be added often, which
would be missed, unless someone re-does all of the scrutiny
that you did, for every new release

that being said, if you would like to volunteer to be the
maintainer of the blender package, i would not argue about it at
all

32 Bit support has been dropped since v2.80
and I currently get issues when trying to build on i686

the truth is that some blender devs are trying to maintain 32bit
support - it was not so much "dropped", as it was
"de-prioritized" - so yes, that means it is more difficult to
build a 32bit blender, but it's not impossible - technically, the
code-base still supports it - that is evident by the fact that
parabola's i686 blender package is v2.93.5

the same is true for mozilla and anything written in rust - it
may not be worth the trouble to fuss with it excessively for
every release; but sometimes those things will compile

IMHO, the more compelling reason to stop building blender for
i686, is that probably no one wants to run blender on such a
slow computer

#2

Updated by bill-auger 5 months ago

  • Parent task set to #3229
#3

Updated by Zuss 5 months ago

the fact that it can
links to a non-free library, does not make that code non-free -

this is not done in order to
prevent people from using cuda - it is done so that the program
will run without cuda being present on the system

I figured it was something along the lines of that.
I wasn't sure if it was that much of an issue but I saw gap bring it up so thought I may address their concerns too.
If anything, I figured that I would end up knowing how to make a patch and it seemed like a good opportunity.
Like I said it's optional so taking it out is probably best to keep the work load to a minimum.

that being said, if you would like to volunteer to be the
maintainer of the blender package, i would not argue about it at
all

I'd be more than happy to do so

IMHO, the more compelling reason to stop building blender for
i686, is that probably no one wants to run blender on such a
slow computer

You do make a point there. Well for now I'll keep it at 64bit just to bring the package up to date. If there seem to be users that still want the 32bit package for some reason, then maybe it'll be worth experimenting with it.

#4

Updated by Zuss 5 months ago

Created a pull request on pagure just to keep everything organized: https://pagure.io/abslibre/pull-request/47
I've also removed the CUDA/OptiX/Metal patch from the PKGBUILD as it really isn't required.

#5

Updated by Zuss 5 months ago

  • % Done changed from 0 to 90
  • Status changed from open to in progress
#6

Updated by Zuss 5 months ago

  • Related to Bug #3089: WARNING: CANNOT RESOLVE "openexr" A DEPENDENCY OF "blender" added

Also available in: Atom PDF