Hide Forgot
Spec URL: http://jskarvad.fedorapeople.org/Equalizer.spec SRPM URL: http://jskarvad.fedorapeople.org/Equalizer-1.1.4-1.fc17.src.rpm Description: Hi, I just packaged Equalizer and I would appreciate the review. Equalizer is the standard middleware to create and deploy parallel OpenGL-based applications. It enables applications to benefit from multiple graphics cards, processors and computers to scale the rendering performance, visual quality and display size. An Equalizer application runs unmodified on any visualization system, from a simple workstation to large scale graphics clusters, multi-GPU workstations and Virtual Reality installations.
This package requires vmmlib-devel to build. There is review request for vmmlib (bug 758470), thus if you are interested consider to review the vmmlib first.
Stefan, are you OK with the current split to Equalizer, Collage, Sequel and appropriate devel subpackages? Any comments or suggestions?
Yes, I'm ok with this. They already have the appropriate CMake components set. I guess the applications then are a package of their own, or do you want to have components for them as well? I want to also split the repositories accordingly, but this is a non-trivial amount of work.
I would appreciate if you do this work on github, so I can easily merge it back. For the 1.0 branch I would no invest too much time. We're trying to converge to 1.2 right now.
(In reply to comment #3) I think we have no problem with the current upstream state. Currently we create the following RPMs: Collage Collage-devel Sequel Sequel-devel Equalizer Equalizer-devel All are build from the Equalizer SRPM. Please check if the deps in the spec file are OK, e.g. Equalizer depends on Collage..., etc.
(In reply to comment #4) > I would appreciate if you do this work on github, so I can easily merge it > back. For the 1.0 branch I would no invest too much time. We're trying to > converge to 1.2 right now. Currently we have 4 patches, I will try to push them through github.
Stefan, for your convenience there is: https://github.com/yarda/Equalizer/tree/yardas You can merge upstream from there. Currently there are three patches that I think could be useful for you. The last one, that I didn't push there, disables -Werror, because there were some warnings and the build fails on Fedora. Correctly fixing these would probably require more effort, thus I didn't do it for now and I will go without -Werror in Fedora for now.
(In reply to comment #7) > Stefan, for your convenience there is: > https://github.com/yarda/Equalizer/tree/yardas Seen and merged. > The last one, that I didn't push there, disables > -Werror, because there were some warnings and the build fails on Fedora. When EQUALIZER_RELEASE is set (which it will be in released versions), -Werror is not used.
Stefan, rpmlint catches the following warnings; Equalizer.x86_64: W: shared-lib-calls-exit /usr/lib64/libEqualizerServer.so.1.1.4 exit@GLIBC_2.2.5 Equalizer.x86_64: W: shared-lib-calls-exit /usr/lib64/libEqualizer.so.1.1.4 exit@GLIBC_2.2.5 generally it is not good to use exit in lib. It shouldn't be blocker for this review, but would be possible to redesign this in the future?
(In reply to comment #9) > generally it is not good to use exit in lib. It shouldn't be blocker for this > review, but would be possible to redesign this in the future? Mhh, good question. Iirc ::exit is called in two places: 1) In Collage after a fork() in the child process, used to launch nodes 2) In Equalizer for render client exits 1) is imo legit. Do you agree? 2) Is a tricky one: An Equalizer application executable can also be used as a render client. To make this work, one of the initialization functions takes over and never returns. Therefore it has to call exit. Iirc the method doing that can be overwritten. Ideas?
I think the name "Equalizer" for a package is very bad because we are polluting a generic namespace. http://fedoraproject.org/wiki/Packaging:Conflicts#Potential_Conflicting_Files
(In reply to comment #11) Anybody any proposal? Bino (currently in rpmfusion integration process) requires libEqualizer. I don't know if there are currently other projects depending on this library or Equalizer package. We could probably patch all such projects if included in Fedora, but this is probably not optimal. The Equalizer name could be probably problem for other distros as well. Stefan is it possible to maybe add some unique prefix?
What exactly is your concern? To my knowledge there is no other software project named Equalizer. Putting OpenGL in the name would cause trademark problems. equalizergraphics seems a bit verbose to me. Would libEqualizer solve the naming issue? This would match nicely to libCollage, once this is broken out into a separate package.
My concern is that we are polluting a common namespace. Once this package has hit the repos it os not easy to rename in case some other software shows up later. We had this problem with "surf", the webbrowser. It was renamed even though no other surf exists in Fedora.
Some random thoughts, really unsorted: - The naming issue need to be resolved. Possible routes seems to include a 'lib' prefix and/or (perhaps) a 'gl' prefix/suffix. - Although provisions are made to use system libs, the bundled libs are not removed in %prep as required in http://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries. - Several packages have multiple licenses without a breakdown showing which license applies to what (http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios) - tclap's COPYING is not packaged as %doc. - Collage has no license, and does not require base package. - In my eyes, the documentation in devel might motivate a separate -doc package(?)
Sorry for the delay. I will try to resolve the issues raised in the comment 15.
(In reply to Alec Leamas from comment #15) > Some random thoughts, really unsorted: > > - The naming issue need to be resolved. Possible routes seems to include a > 'lib' prefix and/or (perhaps) a 'gl' prefix/suffix. +1 for libEqualizer Stefan, is it still possible to rename it upstream? For the other issues, some of them may be already resolved, I am trying to rebase to 1.4.1.
The 1.4.1 requires Lunchbox as dependency. I packaged it, bug 976793. I will also ask upstream whether it is possible to rename it to libLunchbox (I already used this name).