Bug 2218678
| Summary: | luxcorerender not shipping built libraries and generated headers | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominik 'Rathann' Mierzejewski <dominik> | ||||
| Component: | luxcorerender | Assignee: | Luya Tshimbalanga <luya_tfz> | ||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 39 | CC: | besser82, kwizart, luya_tfz, negativo17 | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | --- | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dominik 'Rathann' Mierzejewski
2023-06-29 19:43:13 UTC
https://github.com/LuxCoreRender/LuxMark/blob/master/cmake/Dependencies.cmake#L163 is where library detection fails. It also needs the generated cfg.h, otherwise this check fails as well: https://github.com/LuxCoreRender/LuxMark/blob/master/cmake/Dependencies.cmake#L162 The following checks are going to fail as well (no libraries and no cfg.h file for LuxCore). Created attachment 1973778 [details]
LuxMark spec file for testing
This is the work-in-progress SPEC file for LuxMark that I was working on when I found the issue.
Can you install python3-luxcorerender to see if that solves the issue? I did and it doesn't. The python3-luxcorerender package ships only pyluxcore.so CPython library. The cmake detection code[1] in LuxMark is looking for luxrays C library (libluxrays.so or libluxrays.a) and that is not shipped in any luxcorerender* packages. [1] https://github.com/LuxCoreRender/LuxMark/blob/master/cmake/Dependencies.cmake#L163 My understanding is that you will need to bundle libluxrays.so/a into your project since this project doesn't have stable ABI assumption, we can't expect to update both LuxRender and LuxMark in tandem. Shipping a static library would solve this, if @luya_tfz doesn't want to do downstream SO versioning. Seems strange though, as both projects are maintained by the same people. Feel free to provide a patch or a pull request. Well, I'm reluctant to accept a patch. As I said, it would imply to update Luxcorerender and LuxBench at the same pace so it can use the same shared library. What we can expect from been maintained by the same upstream is that the shared libraries remains unpatched, but it won't solve other problem such as: - Wait for LuxBench to be ready for update LuxRender, or - Wait for LuxRender to be ready to updte LuxBench - Get a LuxRender version ahead of stable releases that is compatible with blender in fedora. - Get an older version that is compatible with blender in el9 (if ever blender exists there). - and we will need to bypass the stable ABI policy for library anyway as we do major upgrade (again: to be compatible with blender). I'm not against having a separate packaging experimented in any copr, but for the time been, please go with with bundling. I may do a PR if time permits, but the way I see it, this is a bug in the package as the libraries do get built, but they get removed in https://src.fedoraproject.org/rpms/luxcorerender/blob/rawhide/f/luxcorerender.spec#_225 It's likely that the -devel subpackage of luxcorerender was unusable since the beginning as there are no consumers of this package in Fedora or RPM Fusion. Note: I don't insist on shared libraries (I'd be happy with static ones in this case), but the Packaging Guidelines do: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_shared_libraries By "this package" I meant luxcorerender-devel. (In reply to Nicolas Chauvet (kwizart) from comment #8) > - Get an older version that is compatible with blender in el9 (if ever > blender exists there). Blender exists in el9 in lite format based on 3.3 LTS: https://src.fedoraproject.org/rpms/blender/tree/epel9 (In reply to Dominik 'Rathann' Mierzejewski from comment #9) > I may do a PR if time permits, but the way I see it, this is a bug in the > package > as the libraries do get built, but they get removed in > https://src.fedoraproject.org/rpms/luxcorerender/blob/rawhide/f/ > luxcorerender.spec#_225 That line is no longer valid with the incoming 2.7beta1 which supports Blender 3.6 (currently on Rawhide). (In reply to Luya Tshimbalanga from comment #11) > (In reply to Dominik 'Rathann' Mierzejewski from comment #9) > > I may do a PR if time permits, but the way I see it, this is a bug in the > > package > > as the libraries do get built, but they get removed in > > https://src.fedoraproject.org/rpms/luxcorerender/blob/rawhide/f/ > > luxcorerender.spec#_225 > > That line is no longer valid with the incoming 2.7beta1 which supports > Blender 3.6 (currently on Rawhide). I'm not sure what you mean above. The linked line is still valid and does remove the built static libraries in current rawhide (abc50bc). Perhaps using specific commit ID will be better? https://src.fedoraproject.org/rpms/luxcorerender/blob/abc50bc67a04c14f2ace1afed604bbcb6cddcff5/f/luxcorerender.spec#_225 Here is a preview built on COPR: https://copr.fedorainfracloud.org/coprs/luya/blender-egl/build/6150713/ Rawhide is currently broken due to global python dependency. You can test F38 version to see if the static subpackage solved the issue for your package. This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39. |