Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 951812 - Review Request: canto-curses - Client portion of canto RSS reader.
Summary: Review Request: canto-curses - Client portion of canto RSS reader.
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On: 951811
TreeView+ depends on / blocked
Reported: 2013-04-13 10:44 UTC by James Walsh
Modified: 2016-02-08 14:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-02-08 14:05:24 UTC

Attachments (Terms of Use)

Description James Walsh 2013-04-13 10:44:40 UTC
Spec URL:
Description: canto-curses client. Interfaces with canto-daemon to provide quite a lovely and lightweight rss reader.
Fedora Account System Username:walshy007

Comment 1 Michael Schwendt 2013-06-19 09:14:09 UTC
* Since package "canto" has been included in the distribution and has been retired just recently, the following process applies:

* The split into canto-daemon and canto-curses requires the Package Renaming Process to be followed:

* Try to do a self-review of your package(s) with the help of the following page:

  [ ]
  [ ]

* Any idea whether the existing bug reports still apply or what to do with them?

* Now on to the spec file, which could be simplified and polished a bit:

> Summary: Canto RSS curses client

Repeating the name of the software is a waste of space in most cases, because it duplicates information included in the package name and/or description. And new users would not know what "Canto" is or why it would be relevant. The file contains an alternative summary, which is clear and concise, IMO. One could drop the "Next-gen" marketing speak to make it even more short and to the point:

  Summary: Next-gen console RSS/Atom reader
  Summary: Console RSS/Atom reader

> Version: 0.8.4
> Source:

You are free to use %{version} in the Source tag and in other places of the spec file. That can be convenient when updating the spec file for a new version.

> #version numbers required
> %global canto_ver 0.8.4 
> %global py3_ver %(echo `%{__python3} -c "import sys;
> sys.stdout.write(sys.version[:3])"`)

Really? %version would be 0.8.4 already, too, and there's only one place in the spec file where you use  %py3_ver:


It wouldn't be a bad idea to simply use the '*' wildcard character here to include any .egg-info file in that directory:


> Requires: python3,canto-daemon,ncurses

"python3" and "ncurses" should be dropped here.

The dependency on "ncurses" is automatic already (due to libncursesw being linked) and arch-specific, too.

There is an automatic dependency on 'python(abi) = 3.3' and libpython, too.

* In the build.log:

> -I/usr/local/include -I/opt/local/include 

Not an immediate problem for clean buildroots, such as with Mock or Fedora koji, but unnecessarily altering the search path for headers is a regular problem for users, who want to (re)build distribution packages and forget that they have installed own stuff in those paths, too.

No need to change/fix it, I just mention it here.

> %files
> %defattr(644,root,root,-)

%defattr is not needed anymore since RPM 4.4, so it can be dropped for any of the currently active distribution releases:

> %attr(755,root,root) %{_bindir}/canto-curses

If you only want to mark it executable, prefer chmod +x during %install, and figure out whether upstream's installation script could mark them +x already. Executables are such a common case, so that using %attr is too much, because preferably it is used only for non-standard user/group ownership and special permissions.

> %{_mandir}/man1/canto-curses.1.gz

%{_mandir}/man1/canto-curses.1*  would be cleaner, since it allows for a changed/customised/dropped compression technique.

> %changelog
> *Fri Apr 12 2013 - - 0.8.4-1

Comment 2 James Walsh 2013-06-21 08:00:59 UTC
Thanks for the feedback, I will adjust the spec file, retest and post back later this evening after reading the items you've linked.

Comment 3 Miroslav Suchý 2015-07-21 13:52:55 UTC
Any progress here? Are you still interrested in this package?

Comment 4 Miroslav Suchý 2016-02-08 14:05:24 UTC
No response. Closing as dead review. If you ever want to continue, please resubmit.

Note You need to log in before you can comment on or make changes to this bug.