Bug 173683 - Review Request: bidiv (BiDi Viewer) - display logical-Hebrew text
Review Request: bidiv (BiDi Viewer) - display logical-Hebrew text
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Mahowald
David Lawrence
http://ivrix.org.il/redhat/bidiv-1.4-...
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-11-18 16:46 EST by Dan Kenigsberg
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-30 03:51:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Kenigsberg 2005-11-18 16:46:17 EST
Spec Name or Url: http://ivrix.org.il/redhat/bidiv.spec
SRPM Name or Url: http://ivrix.org.il/redhat/bidiv-1.4-2.src.rpm

Description: 
bidiv is a tiny but useful unitility for viewing logical-Hebrew text from within an 8-bit terminal. It is an easy-to-use front-end of fribidi library.

An excerpt of its man page reads:
       bidiv  is  a filter, or viewer, for birectional text stored in logical-
       order, into visual-order 8-bit text which can be  viewed  on  terminals
       that  do  not  handle bidirectionality. The output visual-order text is
       formatted assuming a fixed number of characters per line (automatically
       determined or given with the -w parameter).

       The  current  version  is  oriented towards Hebrew, and therefore reads
       ISO-8859-8-i (logical) encoded text  and  outputs  ISO-8859-8  (visual)
       encoded  text.  However, bidiv can be easily adapted to other encodings
       and right-to-left languages.

I am trying to make Fedora more useful for Hebrew speakers. Adding bidiv to Fedora Extras is one more step in that direction.
Comment 1 John Mahowald 2005-12-25 23:50:14 EST
Needs work:
* Missing SMP flags. If it doesn't build with it, please add a comment
  (wiki: PackagingGuidelines#parallelmake)
* rpmlint of bidiv: The group is actually Applications/Text. And you can drop
the Provides.
* The package should contain the text of the license
  (wiki: PackageReviewGuidelines)
* You can drop %doc from the man page, rpm knows about man


Good:
* Source bidiv-1.4.tgz is the same as upstream
* Builds fine in mock
Comment 2 Dan Kenigsberg 2005-12-26 03:53:23 EST
I added smp_flags, corrected the group (even before your review...), dropped the
Provides and %doc for the man page, and added the text of the GPL.
However, there must be a smarter way to add that COPYING file, when it is
missing from the upstream package - I added a new source with a tar.gz of the
GPL. I lack the rpm expertease to do it properly, and I would appreciate a hint.

Please see http://ivrix.org.il/redhat/bidiv-1.4-3.src.rpm and the updated spec.
Comment 3 Roozbeh Pournader 2005-12-26 06:49:52 EST
(In reply to comment #0)
> bidiv is a tiny but useful unitility for viewing logical-Hebrew text from
within an 8-bit terminal.

8-bit terminals? Do we still have those in Fedora?

(In reply to comment #2)
> However, there must be a smarter way to add that COPYING file, when it is
> missing from the upstream package

I believe you should contact the upstream author and ask him to mention the
version of GPL he is releasing the package in. Nowhere in the package (including
the C source) the version of the GPL is mentioned. The "no warranty" clause is
not there either. This makes the package's license ambiguous. Please direct the
author to the final section in the GPL, How to Apply These Terms to Your New
Programs: http://www.gnu.org/licenses/gpl.html#SEC4

Also, I would recommend:
* Formatting the SPEC file according to the default Fedora format (as created by
fedora-rpmnewspec);
* Discarding the %{?dist} tag, as it is not used in the SPEC file for anything.
I think the dist tag is only for cases when there are different Requires or
BuildRequires for different disto releases (See
http://fedoraproject.org/wiki/DistTag).
Comment 4 Paul Howarth 2005-12-27 06:53:22 EST
(In reply to comment #3)
> (In reply to comment #2)
> > However, there must be a smarter way to add that COPYING file, when it is
> > missing from the upstream package
> 
> I believe you should contact the upstream author and ask him to mention the
> version of GPL he is releasing the package in. Nowhere in the package (including
> the C source) the version of the GPL is mentioned. The "no warranty" clause is
> not there either. This makes the package's license ambiguous. Please direct the
> author to the final section in the GPL, How to Apply These Terms to Your New
> Programs: http://www.gnu.org/licenses/gpl.html#SEC4

If upstream does not include the license text, you should ask upstream to do so
for future releases but there is no need to add the license text obtained from
elsewhere to your RPM package. The requirement to include the license text
applies only if upstream provide it.

> Also, I would recommend:
> * Formatting the SPEC file according to the default Fedora format (as created by
> fedora-rpmnewspec);
> * Discarding the %{?dist} tag, as it is not used in the SPEC file for anything.
> I think the dist tag is only for cases when there are different Requires or
> BuildRequires for different disto releases (See
> http://fedoraproject.org/wiki/DistTag).

Different "Requires" would include those auto-generated by RPM. Since this is a
binary package and will be linking against system libraries, it's likely that
different distro releases will have different dependencies, so I'd keep the dist
tag.
Comment 5 Roozbeh Pournader 2005-12-27 07:38:54 EST
(In reply to comment #4)
> If upstream does not include the license text, you should ask upstream to do so
> for future releases but there is no need to add the license text obtained from
> elsewhere to your RPM package. The requirement to include the license text
> applies only if upstream provide it.

That's right, but my point is that the upstream license is unclear (version is
not known), and we better know the license of what we redistribute. So we better
contact the upstream author about that.
Comment 6 Nadav Har'El 2006-01-07 14:33:41 EST
Thanks. I just released a new version of bidiv, which fixes a bug and the
documentation, and clarifies the license (which is, and always was, the GPL -
but now I also added the COPYING file and mentioned "version 2").

You can take the new version from:
http://ftp.ivrix.org.il/pub/ivrix/src/cmdline/bidiv-1.5.tgz
Comment 7 Dan Kenigsberg 2006-01-07 15:39:03 EST
And an updated http://ivrix.org.il/redhat/bidiv-1.5-1.src.rpm is also available.
Comment 8 John Mahowald 2006-01-28 20:53:00 EST
Good:

- rpmlint clean
- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on FC4 i386
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file

Minor: don't need to specify Bidiv - in the Summary. Users already know what
package they are querying.

APPROVED

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