* 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.
* packaging: s/libtinfo/Terminfo/g
* rust: add stddim_yx()
* rust: check for valid init in unit tests
* rust: serialize up tests
* constify notcurses_term_dim_yx()
* rust: add dim wrappers
* remove notcurses_resize() from public API #367
* call notcurses_resize() from notcurses_refresh() #367
* jungle demo should be available outside of DFSG builds
* libav: blitters don't need FFMpeg
* CMake: threads independent of ffmpeg
* CMake: add USE_TESTS option to disable tests #450
* tetris: work without ffmpeg
* fedora: flesh out specfile #328
* menu poc: don't use ffmpeg at all
* compile PoCs with binary/include
* multiselect PoC: work without ffmpeg
* CMake: add USE_PANDOC, USE_DOXYGEN options #101
* README: mention rust
* start integrating rust into build #101
* CMake: add USE_NETWORK option for cargo
* Debian: build-dep on doxygen
* rust: colloquy checks in Cargo.lock
* extract NCKEY defines into their own include
* colloquy: use clap to parse CLI args
* CMake: unify option namespace
* Python: update include path
* Rust: fix up --frozen workings for -DUSE_NETWORK=off
* CMake: abstract out colloquy a little
* Sync direct.hh to the New Way
