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 191015

Summary: Review Request: javasvn
Product: [Fedora] Fedora Reporter: Robert Marcano <robert>
Component: Package ReviewAssignee: Jason Tibbitts <tibbs>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ben
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-03 02:33:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 191014    
Bug Blocks: 163779, 191016, 191017    

Description Robert Marcano 2006-05-08 03:39:46 UTC
Spec URL: http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/javasvn.spec
SRPM URL: http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/javasvn-1.0.4-1.src.rpm
Description: JavaSVN is a pure Java Subversion client library. You would like to use JavaSVN when
you need to access or modify Subversion repository from your Java application, be it
a standalone program, plugin or web application. Being a pure Java program, JavaSVN
doesn't need any additional configuration or native binaries to work on any OS that
runs Java

Comment 2 Parag AN(पराग) 2006-06-05 06:37:51 UTC
This not a review but some comments on SPEC file
rpmlint on your source rpm returns
W: javasvn summary-not-capitalized a pure Java Subversion client library
E: javasvn description-line-too-long JavaSVN is a pure Java Subversion client
library. You would like to use JavaSVN when
E: javasvn description-line-too-long you need to access or modify Subversion
repository from your Java application, be it
E: javasvn description-line-too-long a standalone program, plugin or web
application. Being a pure Java program, JavaSVN
E: javasvn description-line-too-long doesn't need any additional configuration
or native binaries to work on any OS that
W: javasvn invalid-license TMate License
E: javasvn unknown-key GPG#72a0dcfd


Comment 3 Ben Konrath 2006-06-14 04:35:50 UTC
We may have lost some useful comments here. It would be great if people could
re-post anything still relevant. Thanks.

Comment 4 Jason Tibbitts 2006-06-14 20:33:21 UTC
The only comment that was missing is:

------- Additional Comments From robert@marcanoonline.com  2006-06-11 19:06 EST
-------
updated

http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/javasvn.spec
http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/javasvn-1.0.4-3.src.rpm

I applied the debuginfo workaround explained on bug #191014

Checked rpmlint warnings:,
 invalid-license TMate License - http://tmate.org/svn/license.html
   What to to about it, it is a BSD license with an added clause about the
availiablity of the source code

 wrong-file-end-of-line-encoding for HTML files is not fixed because it is not
needed


Comment 5 Robert Marcano 2006-06-26 03:22:30 UTC
Updated:

http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/javasvn.spec
http://www.marcanoonline.com/downloads/fedora/package_submissions/subclipse/javasvn-1.0.4-4.src.rpm

* Sun Jun 25 2006 Robert Marcano <robert@marcanoonline.com> 1.0.4-4
- created javadoc subpackage
- dependency changed from ganymed to ganymed-ssh2

Comment 6 Jason Tibbitts 2006-06-26 17:21:59 UTC
Note that 1.0.6 is out, and I can no longer fetch 1.0.4 from upstream.

I looked at the license and it seems acceptable to me, but it also doesn't
correspond to anything rpnlint already knows about.  I suggest just leaving
things as-is and ignoring the rpmlint complaint.  I also suggest ignoring the
non-standard-group warning on the javadoc subpackage.

W: javasvn invalid-license TMate License
W: javasvn-debuginfo invalid-license TMate License
W: javasvn-javadoc non-standard-group Development/Documentation
W: javasvn-javadoc invalid-license TMate License

Other than that it does build fine in mock (with ganymed-ssh2 in a local repo)
and looks OK.  If you update to 1.0.6 I'll do a full review.

Comment 8 Jason Tibbitts 2006-06-26 19:42:33 UTC
There's no reason to BuildReqires: coreutils; it's in the default buildroot.  It
would be pretty foolish to have a spec without cp and rm.

rpmlint says:
W: javasvn invalid-license TMate License
W: javasvn-debuginfo invalid-license TMate License
W: javasvn-javadoc non-standard-group Development/Documentation
W: javasvn-javadoc invalid-license TMate License
All of which are OK.

So no blockers.

Review:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream:
   fcb8db8a61cde8b5191ff6b1b87c5977  org.tmatesoft.svn_1.0.6.src.zip
* latest version is being packaged.
O BuildRequires are proper (redundant BR: coreutils)
* package builds in mock (development, x86_64).
O rpmlint has ignorable complaints.
* final provides and requires are sane:
  javasvn-1.0.6-1.fc6.x86_64.rpm
   javasvn-1.0.6.jar.so()(64bit)
   javasvn = 1.0.6-1.fc6
  =
   /usr/bin/rebuild-gcj-db
   ganymed-ssh2 >= 209
   java-gcj-compat >= 1.0.33
   libgcj.so.7()(64bit)
   libz.so.1()(64bit)
  javasvn-javadoc-1.0.6-1.fc6.x86_64.rpm
   javasvn-javadoc = 1.0.6-1.fc6
  =
   (nothing)
* shared libraries are present, internal to gcj; rebuild-gcj-db is called properly)
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is not present; not test suite upstream.
* scriptlets present are OK (rebuild-gcj-db)
* code, not content.
* javadoc documentation split off to -javadoc subpackage.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

APPROVED