Description of problem: The 32bit blender doesn't start. The 32bit blender version comes with a wrapper script which automatically select between a sse (pentium4 and above) or non-sse (pentium) flavours. Unfortunately this script at some point lost the executable permission in the SPEC file, so it's not executable anymore. How reproducible: Just type blender from a command line. Cauldron release affected too.
Assigning blender registered maintainer (who maintain an obscene lot of packages...)
Version: 8 => CauldronCC: (none) => friAssignee: bugsquad => geiger.david68210Whiteboard: (none) => MGA8TOO
As OT, speaking of blender itself I wonder if it's not worthwhile to consider an upgrade to another lts version for mga8 (e.g. 2.93). Actually version 2.83 is supported upstream only up to june 2022 (and furthermore there is blender 2.83.20 while we have 2.83.10). See https://www.blender.org/download/lts/2-83/ Only problem is that IIRC latest lts 2.9x version requires at least python3.9 to be compiled, while mga8 has only python3.8. Alternative is to build blender with a bundled python3.9 version.
We are now at 3.3.16 in mga9. What is the status of 32 bit? If OK close this as old. If same problem in mga9, set it to mga9. BTW it would be good if we could update to 4.x, at least in backport. 4.2 is in cauldron, 4.4 released upstream, so cauldron could get updated too. Or at least latest 3.x in mga9 updates. https://forums.mageia.org/en/viewtopic.php?t=15166#p91567
(In reply to Morgan Leijström from comment #3) > We are now at 3.3.16 in mga9. > What is the status of 32 bit? > If OK close this as old. If same problem in mga9, set it to mga9. > > BTW it would be good if we could update to 4.x, at least in backport. > 4.2 is in cauldron, 4.4 released upstream, so cauldron could get updated too. > > Or at least latest 3.x in mga9 updates. > https://forums.mageia.org/en/viewtopic.php?t=15166#p91567 The bug is still there: $ urpmi blender --no-recommends ... bash: /usr/bin/blender: Permission denied As for upgrades, 3.3 gone EOL since some months, however we can, in the immediate, update 3.3.16 to 3.3.21 so to include all the security fixes up to 3.3.21. For updating to a newer version, 3.6 LTS is going EOL today, so maybe worthwhile to skip directly to 4.2 LTS, which is supported up to July 2026. AFAIK in cauldron we keep LTS (current 4.4 upstream is not LTS and is projected to go EOL in mid july 2025). Cauldron has 4.2 LTS, so might be worthwhile to sync with it, however it requires newer libraries (at least openshadinglanguage1.13) to be backported, and maybe others (e.g. embree, etc.).
Shifting bug Mageia release from 8 to 9 then. Does the problem in this bug still exist in Cauldron 32 bit too? Leaving to packagers to consider updating.
Whiteboard: MGA8TOO => MGA9TOO
Who uses this in 32bit system?
Created attachment 15030 [details] fix for blender SPEC file
> Who uses this in 32bit system? I remember short movies like "Elephant dreams" were made with blender (blender-2.46a/b at that time) when the top laptops were like 32-bit Pentium 4 with ATI Radeon 7500M as top graphics card and 512 MB of systen RAM. And that were enough for learning (and teaching) blender. :-) OK, that nowadays features like cycles would require a lot of more resources, and that blender 3.x or 4.x is a lot larger and more complex, however for basic learning of 3D modelling, probably it can still be used if someone is still running MGA on a 32-bit systems. Beyond this, I think the cauldron is also affected. Anyway the fix, once blender is installed is trivial, just chmod +x /usr/bin/blender, and blender would start even in 32-bit. As for fixing the package I think I found why it's not executable: in the blender bash wrapper, for some reason in the SPEC file it was missed the shbang, so some internal rpmbuild finalizers removes the executable bit. The fix should be also trivial, and it's like this in attach.
Also, maybe someone install a 32 bit system on a modern hardware in order to be able to use some special software. And may want to use Blender too. Anyway, if we have some software available on some arch but not another, we should maintain a table over that in our wiki.