https://bugzilla.redhat.com/show_bug.cgi?id=1907238
--- Comment #5 from Richard Shaw <hobbes1069(a)gmail.com> ---
(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!
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component