This package built on koji:  https://koji.fedoraproject.org/koji/taskinfo?taskID=57378822

NOTE: Obsoletes will be updated to meet packaging guidelines prior to building based on current NEVR of OpenEXR and ilmbase.

> Description:
> OpenEXR is a project of the [Academy Software
> Foundation](https://www.aswf.io).
> The format and library were originally developed by Industrial Light & Magic
> and first released in 2003.  Weta Digital, Walt Disney Animation Studios,
> Sony
> Pictures Imageworks, Pixar Animation Studios, DreamWorks, and other studios,
> companies, and individuals have made contributions to the code base.

Description + Summary don't actually say what this package and the format are *for*
(images, video, something else?). Not everybody knows what "EXR" means. Also,
I think the blurb about authors is not interesting for users.

> BuildRequires:  cmake gcc gcc-c++
One-per-line is preferred nowadays.

> %{_bindir}/*
Maybe '%{_bindir}/exr*' ? This will make it less likely to something unintended to slip in on upgrades.

rpmlint:
openexr.src: W: spelling-error %description -l en_US containes -> contained, contains, containers

> # Is it OK to dump the libraries in site-packages?
It means that the modules 'iex' and 'imath' will be importable in the global namespace.
It's certainly allowed in general. I think the name is a bit generic in this case, but
it's not something we have influence over.

+ license is acceptable for Fedora (BSD 3 clause)
+ license is specified correctly
+ builds and installs OK
+ BR and Requires look correct
+ Provides and Obsoletes look correct took

Package is APPROVED.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> > Description:
> > OpenEXR is a project of the [Academy Software
> > Foundation](https://www.aswf.io).
> > The format and library were originally developed by Industrial Light & Magic
> > and first released in 2003.  Weta Digital, Walt Disney Animation Studios,
> > Sony
> > Pictures Imageworks, Pixar Animation Studios, DreamWorks, and other studios,
> > companies, and individuals have made contributions to the code base.
> 
> Description + Summary don't actually say what this package and the format
> are *for*
> (images, video, something else?). Not everybody knows what "EXR" means. Also,
> I think the blurb about authors is not interesting for users.

Yeah, I copied that and a lot more from the README. I may borrow from the current OpenEXR package.


> > %{_bindir}/*
> Maybe '%{_bindir}/exr*' ? This will make it less likely to something
> unintended to slip in on upgrades.
> 
> rpmlint:
> openexr.src: W: spelling-error %description -l en_US containes -> contained,
> contains, containers

Since I copied it straight from their readme I guess I should let them know :)


> > # Is it OK to dump the libraries in site-packages?
> It means that the modules 'iex' and 'imath' will be importable in the global
> namespace.
> It's certainly allowed in general. I think the name is a bit generic in this
> case, but
> it's not something we have influence over.

Most dedicated python packages that I maintain put them in a named subdirectory but yeah, I looked in my system and there's lots of packages that dump them right in site-packages.


> + license is acceptable for Fedora (BSD 3 clause)
> + license is specified correctly
> + builds and installs OK
> + BR and Requires look correct
> + Provides and Obsoletes look correct took
> 
> Package is APPROVED.

Thanks!

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/openexr

FEDORA-2021-6229d3d205 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Is there any difference between your package and https://src.fedoraproject.org/rpms/OpenEXR, which is in Fedora for 3+ years? (and not counting, this version has newer NVR)

Please, ignore my previous comment, I've just hit the origin message on fedora devel list. All good now.

I'm not sure why Josef retracted his comment because it this does indeed appear to be a duplicate of the existing OpenEXR package and even if it wasn't the same software packages whose names differ only in case are not allowed:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_conflicting_package_names

If the intention was to retire OpenEXR in favour of this then that does not appear to have happened as both are still live currently:

https://src.fedoraproject.org/rpms/OpenEXR
https://src.fedoraproject.org/rpms/openexr

Yes, OpenEXR should be retired.

Well, it's true, that OpenEXR package for Fedora Rawhide (maybe even Fedora 34) should follow this guideline https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life so it's clear, such package is removed from distribution. But otherwise, the update from OpenEXR to openexr is clear and all provides/obsolete and other references are correctly set.