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.5 Equalizer.x86_64: W: shared-lib-calls-exit /usr/lib64/libEqualizer.so.1.1.4 exit.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).
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time. We're sorry it is taking so long. If you're still interested in packaging this software into Fedora repositories, please respond to this comment clearing the NEEDINFO flag. You may want to update the specfile and the src.rpm to the latest version available and to propose a review swap on Fedora devel mailing list to increase chances to have your package reviewed. If this is your first package and you need a sponsor, you may want to post some informal reviews. Read more at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. Without any reply, this request will shortly be considered abandoned and will be closed. Thank you for your patience.
I am still going to handle this.
Because this package is presented on equalizergraphics.com domain, I would vote for equalizer-graphics, equalizergraphics or just equalizer-g package name. G may stand for Graphics, GPU, GL, whatever. It hints no relation to audio equalizer is present, which might be primary expectation of such name. I don't like libEqualizer if upstream never used that name. equalizergraphics is not very short, but should work for intermediate specialized library. And they present it under that name already. I am not sure it needs to be renamed, because no package of similar name already exists. Is there any open source product depending on this library?
(In reply to Petr Menšík from comment #22) > Because this package is presented on equalizergraphics.com domain, I would > vote for equalizer-graphics, equalizergraphics or just equalizer-g package > name. G may stand for Graphics, GPU, GL, whatever. It hints no relation to > audio equalizer is present, which might be primary expectation of such name. > I don't like libEqualizer if upstream never used that name. > equalizergraphics is not very short, but should work for intermediate > specialized library. And they present it under that name already. > The equalizer-graphics evokes (at least for me) it's graphics subpackage for the equalizer package which is not true. > I am not sure it needs to be renamed, because no package of similar name > already exists. Is there any open source product depending on this library? IIRC at the moment 'bino' from the rpmfusion which now builts without it.
I still want to get it in.