Bug 251521

FIXME: better summary. :)

This is a new build requirement for openexr >= 1.6.0  (these were included in
openexr < 1.6.0)

I take the review...

OK - rpmlint on rpm packages is quiet 
Should fix - rpmlint on installed files show: (on fc6 x86_64 at least )
W: ilmbase incoherent-version-in-changelog 1.0.0-1 1.0.0-1.kwizart.fc6
W: ilmbase unused-direct-shlib-dependency /usr/lib64/libHalf.so.6.0.0
/lib64/libpthread.so.0
W: ilmbase unused-direct-shlib-dependency /usr/lib64/libHalf.so.6.0.0
/lib64/libm.so.6
W: ilmbase unused-direct-shlib-dependency /usr/lib64/libHalf.so.6.0.0
/lib64/libgcc_s.so.1
W: ilmbase unused-direct-shlib-dependency /usr/lib64/libIex.so.6.0.0
/lib64/libm.so.6
W: ilmbase unused-direct-shlib-dependency /usr/lib64/libImath.so.6.0.0
/lib64/libpthread.so.0
W: ilmbase unused-direct-shlib-dependency /usr/lib64/libIlmThread.so.6.0.0
/lib64/libm.so.6
You may advice upstream or maybe uses this between configure and make (or the
right ld options...). (Note that this is usually a "should fix" field).
# clean unused-direct-shlib-dependencies
sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool

Should fix - You may add make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install
-p -c" to prevent timestamp changes when installing headers (minor issue, but
easy to fix)

Must - Well I expect you will change Summary to reflect the one from the review
(which is better indeed).

Must - ImathGLU.h:#include <GL/glu.h>, half.h:#include <iostream> / I wonder if
yu have to add Requires: mesa-libGLU-devel (and boost-devel as i expect?) for
ilmbase-devel, might be needed as BR also... (i don't remember if mesa is in the
minimal Buildsys, seems not...)

Note that since ilmbase owns /usr/include/OpenEXR, ownership have to be removed
from the new OpenEXR-devel package...

hum, forgot to talk about the licensing issue. how did you deduced the BSD
license (as the BSD license isn't included).
Instead there is // Copyright (c) 2002, Industrial Light & Magic, a division of
Lucas Digital Ltd. LLC

Re License: BSD
See
http://fedoraproject.org/wiki/Licensing/BSD#3ClauseBSD

Which matches:

// *       Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
// *       Redistributions in binary form must reproduce the above
// copyright notice, this list of conditions and the following disclaimer
// in the documentation and/or other materials provided with the
// distribution.
// *       Neither the name of Industrial Light & Magic nor the names of
// its contributors may be used to endorse or promote products derived
// from this software without specific prior written permission.

Re: iostream
a standard C++ header, not to be confused with /boost/iostreams/detail/iostream.hpp

I'll work to fixup the other MUST items.

Spec URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ilmbase/ilmbase.spec
SRPM URL:
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ilmbase/ilmbase-1.0.0-2.src.rpm

%changelog
* Mon Oct 08 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.0.0-2
- update %%summary
- -devel: +Requires: libGL-devel libGLU-devel
- make install ... INSTALL="install -p" to preserve timestamps

Rex, do you want to update for F-8 ?
Because I will be sort in time, so if you plan to update it, it should be fine
to request a scratch build from koji...(as i'm not able to rebuild it quickly)...
Install/Uninstall test (with -devel) will be required... (rpmlint on installed
file, but seems corrected).

From the spec, I just wonder why you Requires mesa-libGL{,U}-devel in
ilmbase-devel but not in BR ?
And does it is LibGLU-devel or mesa-libGLU-devel (seems that the package is
named mesa-libGLU-devel, maybe the compat-name will be dropped...)

> I just wonder why you Requires mesa-libGL{,U}-devel in
> ilmbase-devel but not in BR ?

I checked all the buildtime scripts/makefiles, and it's not used there.

> And does it is LibGLU-devel or mesa-libGLU-devel

libGLU-devel is preferred, mesa-libGLU-devel Provides it.

Freeze in 5 days... Do you mind we can update it for F-8 ?
Did you tested the new OpenEXR with SeLinux set to Strict on rawhide?
(I may be able to do this if you request a sratch build for rawhide on koji)

We will short in time to report problem? What do you mind ?
Do you have a list of packages that will need a rebuild ?
Did you warned maintainers about the potential update ?

F-8 can/should wait.  This can go into devel(F-9) branch initially.

------------

This package (ilmbase) is APPROVED by me

------------

New Package CVS Request
=======================
Package Name: ilmbase
Short Description: Abstraction/convenience libraries
Owners: rdieter1
Branches: EL-4 EL-5 F-7 F-8
Cvsextras Commits: yes

cvs done.

I've never unserstood, if that was important if the reviewer need to close to
NextRelease the review request himself (I think not but...)
In others terms I let you close this bug, Rex!
Hu!, we get it in!

Usually the maintainer does it, but for all practical purposes, it doesn't
matter who/how, as long as it gets done.  ):

Closing...