Spec URL: http://ajax.fedorapeople.org/mesa-libGLU/mesa-libGLU.spec SRPM URL: http://ajax.fedorapeople.org/mesa-libGLU/mesa-libGLU-9.0-0.1.f16.src.rpm Description: Mesa upstream has split the libGLU utility library - which doesn't see much by way of updates - into its own repository. This library has not yet had an official release, but one is expected before Mesa 9.0 (and the GLU code has already been removed from the main Mesa repo, which means this is blocking newer Mesa snapshots). Fedora Account System Username: ajax
Updated spec and srpm at the same urls as above: - BuildRequires: mesa-libGL-devel - -devel Requires: gl-manpages instead of bundling, recently added in bug #854660
- This is repackaging of something already shipped so I am not going to get too much into it, but I think it would be good to sort out the licence header of glu_mangle.h which currently says LGPLv2+. or the License tag... - packagaing guildelines say %global instead of %define - you can lose the rm -rf $RPM_BUILD_ROOT%{_datadir}/man/man3/gl[A-Z]* and rm -rf $RPM_BUILD_ROOT (as per latest rpm developemts) Otherwise: - it buils in mock - mesa-libGLU.x86_64: W: shared-lib-calls-exit /usr/lib64/libGLU.so.1.3.1 exit.5 is apparently expected - ts part of a bigger mesa update so the fact that it cant be currently installed due to gl-manpages conflicting with other things is expected APPROVED
New Package SCM Request ======================= Package Name: mesa-libGLU Short Description: Mesa libGLU utility library Owners: ajax Branches: f18 InitialCC:
Git done (by process-git-requests).
Imported and building, thanks.
Shouldn't this mesa-libGLU package have provides for libGLU and libGLU-devel (in the devel package of course)?
(In reply to comment #6) > Shouldn't this mesa-libGLU package have provides for libGLU and libGLU-devel > (in the devel package of course)? Same question twice. This broke lot of dependencies without it. Of course all of them could use BR: pkgconfig(glu) but then this will requires to modify all packages instead of only this one. (this would cost more). That modification would be a task for a proven packager. I will dislike to bug every sigle maintainer for such trivial administrative change. (but then this would need to be properly coodinated in the devel mailing list).