Archives/notcurses
2
0
Fork 0
mirror of https://github.com/dankamongmen/notcurses.git synced 2024-11-18 03:25:55 +00:00
Code Issues Packages Projects Releases Wiki Activity
2e449addad
notcurses/tools/notcurses.spec

119 lines
3.5 KiB
RPMSpec
Raw Normal View History

Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
Name: notcurses
Fedora: new upstream version
2020-04-25 21:46:13 +00:00
Version: 1.3.3
Take back fedora release version
2020-04-24 16:20:13 +00:00
Release: 1%{?dist}
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
Summary: Character graphics and TUI library
License: ASL 2.0
URL: https://nick-black.com/dankwiki/index.php/Notcurses
fedora: use DFSG source tarball
2020-04-21 09:36:13 +00:00
Source0: https://github.com/dankamongmen/notcurses/releases/download/v%{version}/notcurses_%{version}+dfsg.1.orig.tar.xz
fedora: correct signature path
2020-04-25 21:44:09 +00:00
Source1: https://github.com/dankamongmen/%{name}/releases/download/v%{version}/v%{version}.tar.xz.asc
use nick-black.com in specfile, save a 301
2020-04-25 20:55:15 +00:00
Source2: https://nick-black.com/dankamongmen.gpg
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
BuildRequires: gnupg2
BuildRequires: cmake
BuildRequires: gcc-c++
Support image decoding with OpenImageIO #453 (#534) * 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
2020-04-25 19:52:23 +00:00
BuildRequires: libqrcodegen-devel
BuildRequires: OpenEXR-devel
BuildRequires: OpenImageIO-devel
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
BuildRequires: pandoc
BuildRequires: python3-devel
fedora python build changes from @dcantrell
2020-04-20 10:26:58 +00:00
BuildRequires: python3-cffi
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
BuildRequires: pkgconfig(ncurses)
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%description
notcurses facilitates the creation of modern TUI programs,
s/direct color/TrueColor/g
2020-04-10 16:37:12 +00:00
making full use of Unicode and 24-bit TrueColor. It presents
Rust wrapper work (#454) * 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
2020-04-08 09:39:41 +00:00
an API similar to that of Curses, and rides atop Terminfo.
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%package devel
Summary: Development files for the notcurses library
License: ASL 2.0
rpmspec: strip quotation marks
2020-04-11 16:24:03 +00:00
Requires: %{name}%{?_isa} = %{version}-%{release}
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%description devel
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
Development files for the notcurses library.
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%package static
Summary: Static library for the notcurses library
License: ASL 2.0
fedora: update spec for review feedback
2020-04-21 09:12:11 +00:00
Requires: %{name}%{?_isa} = %{version}-%{release}
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%description static
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
A statically-linked version of the notcurses library.
rpmspec: s/srcname/name/g
2020-04-11 16:25:22 +00:00
%package -n python3-%{name}
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
Summary: Python wrappers for notcurses
License: ASL 2.0
rpmspec: strip quotation marks
2020-04-11 16:24:03 +00:00
Requires: %{name}%{?_isa} = %{version}-%{release}
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
rpmspec: s/srcname/name/g
2020-04-11 16:25:22 +00:00
%description -n python3-%{name}
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
Python wrappers and a demonstration script for the notcurses library.
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%prep
%{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}' --data='%{SOURCE0}'
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%autosetup
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
# Tests have been disabled due to absence of doctest in Fedora (as of F32)
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%build
fedora: really fix python #462
2020-04-11 06:02:04 +00:00
mkdir build
cd build
fedora: use DFSG_BUILD=on
2020-04-25 21:49:50 +00:00
%cmake -DUSE_MULTIMEDIA=oiio -DUSE_TESTS=off -DDFSG_BUILD=on ..
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%make_build
fedora python build changes from @dcantrell
2020-04-20 10:26:58 +00:00
cd python
%py3_build
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%install
fedora: really fix python #462
2020-04-11 06:02:04 +00:00
cd build
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%make_install
fedora: really fix python #462
2020-04-11 06:02:04 +00:00
cd python
fedora python build changes from @dcantrell
2020-04-20 10:26:58 +00:00
%py3_install
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%files
fedora: install USAGE.md and OTHERS.md
2020-04-25 21:35:21 +00:00
%doc CHANGELOG.md OTHERS.md README.md
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%license COPYRIGHT LICENSE
%{_libdir}/libnotcurses.so.%{version}
%{_libdir}/libnotcurses.so.1
%{_libdir}/libnotcurses++.so.1
%{_libdir}/libnotcurses++.so.%{version}
%{_bindir}/notcurses-demo
%{_bindir}/notcurses-input
%{_bindir}/notcurses-ncreel
%{_bindir}/notcurses-tetris
fedora: don't provoke 'installed but unpackaged' bah
2020-04-14 16:34:07 +00:00
# Don't use a wildcard, lest we pull in notcurses-pydemo.1. We install the man
# pages for notcurses-tester and notcurses-view, binaries we're not yet
# installing, because we intend to install the binaries Real Soon and it's
# IMHO not worth mucking with the CMake in the meantime FIXME.
Fedora specfile: list directories, use wildcards
2020-04-11 16:17:15 +00:00
%{_mandir}/man1/notcurses-demo.1*
%{_mandir}/man1/notcurses-input.1*
%{_mandir}/man1/notcurses-ncreel.1*
fedora: don't provoke 'installed but unpackaged' bah
2020-04-14 16:34:07 +00:00
%{_mandir}/man1/notcurses-tester.1*
Fedora specfile: list directories, use wildcards
2020-04-11 16:17:15 +00:00
%{_mandir}/man1/notcurses-tetris.1*
fedora: don't provoke 'installed but unpackaged' bah
2020-04-14 16:34:07 +00:00
%{_mandir}/man1/notcurses-view.1*
fedora: move binaries and S1 man pages to main rpm #467
2020-04-11 02:46:07 +00:00
%files devel
fedora: install USAGE.md and OTHERS.md
2020-04-25 21:35:21 +00:00
%doc USAGE.md
Fedora specfile: list directories, use wildcards
2020-04-11 16:17:15 +00:00
%{_includedir}/notcurses/
%{_includedir}/ncpp/
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%{_libdir}/libnotcurses.so
%{_libdir}/libnotcurses++.so
%{_libdir}/cmake/notcurses
%{_libdir}/pkgconfig/notcurses.pc
%{_libdir}/pkgconfig/notcurses++.pc
Fedora specfile: list directories, use wildcards
2020-04-11 16:17:15 +00:00
%{_mandir}/man3/*.3*
Change notcurses.spec to follow Fedora Packaging Policy 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.
2020-04-08 14:43:48 +00:00
%files static
%{_libdir}/libnotcurses.a
%{_libdir}/libnotcurses++.a
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
rpmspec: s/srcname/name/g
2020-04-11 16:25:22 +00:00
%files -n python3-%{name}
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
%{_bindir}/notcurses-pydemo
Fedora specfile: list directories, use wildcards
2020-04-11 16:17:15 +00:00
%{_mandir}/man1/notcurses-pydemo.1*
fedora: use python_sitearch, install all python #462
2020-04-11 06:05:44 +00:00
%{python3_sitearch}/*egg-info/
%{python3_sitearch}/notcurses/
%{python3_sitearch}/*.so
Fedora specfile: Incorporate A Iwicki's feedback 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.
2020-04-11 16:08:29 +00:00
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
%changelog
Fedora: new upstream version
2020-04-25 21:46:13 +00:00
* Sat Apr 25 2020 Nick Black <dankamongmen@gmail.com> - 1.3.3-1
- New upstream version, incorporate review feedback
v1.3.2
2020-04-19 06:24:03 +00:00
* Tue Apr 07 2020 Nick Black <dankamongmen@gmail.com> - 1.3.2-1
Prep for Fedora packaging (#452) * 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
2020-04-08 06:12:46 +00:00
- Initial Fedora packaging
Reference in New Issue Copy Permalink