* fedora: dep on OpenImageIO, and use it
* fedora: dep on libqrcodegen-devel
* fedora: BuildRequires OpenEXR-devel
* tight check on USE_MULTIMEDIA
* CMake: enable notcurses-view for ffmpeg OR oiio
* notcurses-view: don't reach into libav
* oiio: ncvisual_render() #453
* oiio: need our own properly-offset ncvisual_plane()
* `visual` poc: accept optional command line argument
* oiio: work for 3-channel images #453
* oiio: destroy ncvisual's plane if we own it #453
* notcurses_visual.3: s/FFmpeg/multimedia/g
Split out the python demo and wrappers into their own package,
python3-notcurses. Make an archful dependency for the devel
package to the main library. Comment up test disabling.
More or less. Here's a list of things I changed:
* Single line BuildRequires which is more of a convention than a
requirement.
* Drop make from BuildRequires. That's one we do actually provide.
* Use pkgconfig(ncurses) to get the ncurses-devel BuildRequires.
* Add a 'devel' subject and move development files there.
* Add a 'static' package for the .a libraries which is common
for other packages that provide static libraries.
* Add doc files using %doc
* -DUSE_TEST=off -> -DUSE_TESTS=off
* Use %autosetup in %setup which covers adding patches in the future
for downstream packaging.
* Use path macros in %files
* Correct the date format in the %changelog entry
* Use the 1.2.6 release as an example
Things that could use more consideration:
* The release artifacts don't match what GitHub provides. Their
automated download link gives you notcurses-1.2.6.tar.gz but the URL
calls it v1.2.6.tar.gz.
* There is no signature file uploaded.
* notcurses-tester and notcurses-viewer do not build.
* Should the demo programs go in the main package or devel. I felt
devel was more appropriate.
* Should the packaging be further refined to split out the C++ runtime
and static libraries to separate subpackages?
I did some local test runs using mock. I ran the SRPM through rpmlint
which would happen when the package is submitted for inclusion.
For the download archive and signature, I create new release posts on
my github projects and create a separate tarball and sign that and
upload them there. It is separate from the GitHub automated
make-me-a-tarball download link. That might be what you're planning
on doing.
