You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
notcurses/tools/notcurses.spec

113 lines
3.2 KiB
Plaintext

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.
4 years ago
Name: notcurses
4 years ago
Version: 1.3.2
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.
4 years ago
Summary: Character graphics and TUI library
License: ASL 2.0
URL: https://nick-black.com/dankwiki/index.php/Notcurses
Source0: https://github.com/dankamongmen/notcurses/releases/download/v%{version}/notcurses_%{version}+dfsg.1.orig.tar.xz
Source1: https://github.com/dankamongmen/%{name}/releases/download/v%{version}/v%{version}.tar.gz.asc
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.
4 years ago
Source2: https://dank.qemfd.net/dankamongmen.gpg
BuildRequires: gnupg2
BuildRequires: cmake
BuildRequires: gcc-c++
BuildRequires: pandoc
BuildRequires: python3-devel
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.
4 years ago
BuildRequires: pkgconfig(ncurses)
%description
notcurses facilitates the creation of modern TUI programs,
making full use of Unicode and 24-bit TrueColor. It presents
an API similar to that of Curses, and rides atop Terminfo.
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.
4 years ago
%package devel
Summary: Development files for the notcurses library
License: ASL 2.0
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.
4 years ago
%description devel
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.
4 years ago
%package static
Summary: Static library for the notcurses library
License: ASL 2.0
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.
4 years ago
%description static
A statically-linked version of the notcurses library.
%package -n python3-%{name}
Summary: Python wrappers for notcurses
License: ASL 2.0
Requires: %{name}%{?_isa} = %{version}-%{release}
%description -n python3-%{name}
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.
4 years ago
%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.
4 years ago
%autosetup
# Tests have been disabled due to absence of doctest in Fedora (as of F32)
%build
mkdir build
cd build
%cmake -DUSE_FFMPEG=off -DUSE_TESTS=off ..
%make_build
cd python
%py3_build
%install
cd build
%make_install
cd python
%py3_install
%files
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.
4 years ago
%doc CHANGELOG.md README.md
%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
# 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.
%{_mandir}/man1/notcurses-demo.1*
%{_mandir}/man1/notcurses-input.1*
%{_mandir}/man1/notcurses-ncreel.1*
%{_mandir}/man1/notcurses-tester.1*
%{_mandir}/man1/notcurses-tetris.1*
%{_mandir}/man1/notcurses-view.1*
%files devel
%{_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.
4 years ago
%{_libdir}/libnotcurses.so
%{_libdir}/libnotcurses++.so
%{_libdir}/cmake/notcurses
%{_libdir}/pkgconfig/notcurses.pc
%{_libdir}/pkgconfig/notcurses++.pc
%{_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.
4 years ago
%files static
%{_libdir}/libnotcurses.a
%{_libdir}/libnotcurses++.a
%files -n python3-%{name}
%{_bindir}/notcurses-pydemo
%{_mandir}/man1/notcurses-pydemo.1*
%{python3_sitearch}/*egg-info/
%{python3_sitearch}/notcurses/
%{python3_sitearch}/*.so
%changelog
4 years ago
* Tue Apr 07 2020 Nick Black <dankamongmen@gmail.com> - 1.3.2-1
- Initial Fedora packaging