Bug 1005785 (snowball)

I think the name is not correct. There is also a C version of this available on the site. Therefore we need to diambiguate the name in case someone wanted to package the C version of algorithms.

The summary also doesn't seem right. If those are bindings - then bindings to what? On the site it is summarized as "The Java version of the libstemmer library". That also raises a question whether it should be really called snowball. TBH I don't really understand what the package is supposed to do, but it seems to me that sentence "You can use the various ANSI C and Java stemmers in programs of your own, without bothering yourself with the Snowball system that generated them." implies that this is not snowball itself, but rather something generated by it. Therefore I think it shouldn't be called snowball, but libstemmer-java Java as indicated by the name of the tarball.

The descritption is insufficient, it doesn't say anything about the library itself.

Also, where did you get that POM?

Looking at their documentation and sources I made a different conclusion:
You should package http://snowball.tartarus.org/dist/snowball_code.tgz as snowball instead, because that is the compiler that generated it and also the source for the generated code. Thre is a GNUmakefile that can build the compiler and generate the C and Java libraries (it seems like it needs to be patched a little to get the Java version, though), which should become snowball's subpackages.

(In reply to Michael Simacek from comment #1)
> I think the name is not correct. There is also a C version of this available
> on the site. Therefore we need to diambiguate the name in case someone
> wanted to package the C version of algorithms.
> 
> The summary also doesn't seem right. If those are bindings - then bindings
> to what? On the site it is summarized as "The Java version of the libstemmer
> library". That also raises a question whether it should be really called
> snowball. TBH I don't really understand what the package is supposed to do,
> but it seems to me that sentence "You can use the various ANSI C and Java
> stemmers in programs of your own, without bothering yourself with the
> Snowball system that generated them." implies that this is not snowball
> itself, but rather something generated by it. Therefore I think it shouldn't
> be called snowball, but libstemmer-java Java as indicated by the name of the
> tarball.
> 

> The descritption is insufficient, it doesn't say anything about the library
> itself.
> 

better ?

Snowball is a small string processing language
designed for creating stemming algorithms
for use in Information Retrieval.

This package contains all you need to include the
snowball stemming algorithms into a Java
project of your own. If you use this,
you don't need to use the snowball compiler,
or worry about the internals of the
stemmers in any way.

> Also, where did you get that POM?

created by me

(In reply to Michael Simacek from comment #2)
> Looking at their documentation and sources I made a different conclusion:
> You should package http://snowball.tartarus.org/dist/snowball_code.tgz as
> snowball instead, because that is the compiler that generated it and also
> the source for the generated code. Thre is a GNUmakefile that can build the
> compiler and generate the C and Java libraries (it seems like it needs to be
> patched a little to get the Java version, though), which should become
> snowball's subpackages.

i dont need C libraries ... and for now i dont have intentions to package this libs

> i dont need C libraries ... and for now i dont have intentions to package
> this libs

Ok. It is distributed separately by upstream, so it shouldn't be a problem.

The description is now ok, but I still insist on changing the name. If someone decided to package the snowball compiler or the C version of the library, there would be problem. "snowball-java" or "libstemmer-java" sounds more reasonable.

Regarding that POM - why do you add dependency on junit? I don't see any unit test in there.

Spec URL: http://gil.fedorapeople.org/snowball-java.spec
SRPM URL: http://gil.fedorapeople.org/snowball-java-0-0.1.20130902.fc19.src.rpm

- rename pkg
- remove junit refs

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- It doesn't contain the actual license. The text in license.txt contains just
  information about the license, but not the license itself. It could be used
  as a notice, but you should attach the actual text of the license (there's a
  link to it in the file).
- The summary deosn't reflect what it really is. It's not bindings it's a
  standalone library. Something like "Java stemming algorithm library" should
  be enough.


===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Unknown or generated". 20 files have unknown license. Detailed output of
     licensecheck in /home/msimacek/1005785-snowball-java/licensecheck.txt
[?]: License file installed when any subpackage combination is installed.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Java:
[x]: Bundled jar/class files should be removed before build
[x]: Packages have proper BuildRequires/Requires on jpackage-utils
     Note: Maven packages do not need to (Build)Require jpackage-utils. It is
     pulled in by maven-local
[x]: Javadoc documentation files are generated and included in -javadoc
     subpackage
[x]: Javadoc subpackages should not have Requires: jpackage-utils
[x]: Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlink)

Maven:
[x]: If package contains pom.xml files install it (including depmaps) even
     when building with ant
[x]: POM files have correct Maven mapping
[x]: Maven packages should use new style packaging
[x]: Old add_to_maven_depmap macro is not being used
[x]: Packages DO NOT have Requires(post) and Requires(postun) on jpackage-
     utils for %update_maven_depmap macro
[x]: Package DOES NOT use %update_maven_depmap in %post/%postun
[x]: Packages use %{_mavenpomdir} instead of %{_datadir}/maven2/poms

===== SHOULD items =====

Generic:
[x]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in snowball-
     java-javadoc
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

Java:
[-]: Package uses upstream build method (ant/maven/etc.)
[x]: Packages are noarch unless they use JNI

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: snowball-java-0-0.1.20130902.fc21.noarch.rpm
          snowball-java-javadoc-0-0.1.20130902.fc21.noarch.rpm
          snowball-java-0-0.1.20130902.fc21.src.rpm
snowball-java.noarch: W: spelling-error Summary(en_US) Libstemmer -> Filibusterer
snowball-java.noarch: W: spelling-error %description -l en_US stemmers -> steamers, stammers, stammerers
snowball-java.src: W: spelling-error Summary(en_US) Libstemmer -> Filibusterer
snowball-java.src: W: spelling-error %description -l en_US stemmers -> steamers, stammers, stammerers
3 packages and 0 specfiles checked; 0 errors, 4 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint snowball-java-javadoc snowball-java
snowball-java.noarch: W: spelling-error Summary(en_US) Libstemmer -> Filibusterer
snowball-java.noarch: W: spelling-error %description -l en_US stemmers -> steamers, stammers, stammerers
2 packages and 0 specfiles checked; 0 errors, 2 warnings.
# echo 'rpmlint-done:'



Requires
--------
snowball-java-javadoc (rpmlib, GLIBC filtered):
    jpackage-utils

snowball-java (rpmlib, GLIBC filtered):
    java
    jpackage-utils



Provides
--------
snowball-java-javadoc:
    snowball-java-javadoc

snowball-java:
    mvn(org.tartarus:snowball)
    snowball-java



Source checksums
----------------
http://snowball.tartarus.org/dist/libstemmer_java.tgz :
  CHECKSUM(SHA256) this package     : 7d2a3998e0bddba82e9c272eda1af7175161ba8173f848b1fc688b314f67441f
  CHECKSUM(SHA256) upstream package : 7d2a3998e0bddba82e9c272eda1af7175161ba8173f848b1fc688b314f67441f


Generated by fedora-review 0.5.1 (bb9bf27) last change: 2013-12-13
Command line :/usr/bin/fedora-review -b 1005785
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, Java
Disabled plugins: C/C++, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG

Spec URL: http://gil.fedorapeople.org/snowball-java.spec
SRPM URL: http://gil.fedorapeople.org/snowball-java-0-0.1.20130902.fc19.src.rpm

- fix summary

The license text is still not there. BSD requires that a copy of the license is distributed with the software.
According to the guidelines you should query upstream to include it, but they explicitly stated on their website "they don't bother to do it". So I think just including a copy of BSD license as another source should be ok.

But you should also keep the licence.txt file that was there (it contains the copyright), just rename it to notice.txt, so it's clear it's not actual license text.

To summarize it, there should be two %doc files included: notice.txt (the contents of their license.php page) and license.txt (actual text of BSD license obtained from the link in their license.php page)

(In reply to Michael Simacek from comment #9)
> The license text is still not there. BSD requires that a copy of the license
> is distributed with the software.
> According to the guidelines you should query upstream to include it, but
> they explicitly stated on their website "they don't bother to do it". So I
> think just including a copy of BSD license as another source should be ok.
> 
> But you should also keep the licence.txt file that was there (it contains
> the copyright), just rename it to notice.txt, so it's clear it's not actual
> license text.
> 
> To summarize it, there should be two %doc files included: notice.txt (the
> contents of their license.php page) and license.txt (actual text of BSD
> license obtained from the link in their license.php page)
Done

Spec URL: http://gil.fedorapeople.org/snowball-java.spec
SRPM URL: http://gil.fedorapeople.org/snowball-java-0-0.1.20130902.fc19.src.rpm

Looks OK.

Thanks!

New Package SCM Request
=======================
Package Name: snowball-java
Short Description: Java stemming algorithm library
Owners: gil
Branches: f20
InitialCC: java-sig

Git done (by process-git-requests).

snowball-java-0-0.1.20130902.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/snowball-java-0-0.1.20130902.fc20

snowball-java-0-0.1.20130902.fc20 has been pushed to the Fedora 20 testing repository.

snowball-java-0-0.1.20130902.fc20 has been pushed to the Fedora 20 stable repository.