At various places in rendering and rasterizing, we advance two
columns upon encountering a wide glyph. When dealing with a
single plane, this is always correct, because we're always
hitting the first column of the multicolumn glyph. Once multiple
planes are brought into play, though, we can very much hit the
second column of said glyph, in which case we mustn't advance
two columns, but only one. Resolves#474 by way of #475. w00t!
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.
