This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 462560 - Review Request: xmlpull-api - XmlPull v1 API is a simple to use XML pull parsing API
Review Request: xmlpull-api - XmlPull v1 API is a simple to use XML pull pars...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jerry James
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW 462923 462932
  Show dependency treegraph
 
Reported: 2008-09-17 00:12 EDT by John Guthrie
Modified: 2009-10-06 23:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-06 23:13:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Guthrie 2008-09-17 00:12:20 EDT
Spec URL: http://www.guthrie.info/RPMS/f9/xmlpull-api.spec
SRPM URL: http://www.guthrie.info/RPMS/f9/xmlpull-api-1.1.4b-2.fc9.src.rpm
Description: XmlPull v1 API is a simple to use XML pull parsing API that was
designed for simplicity and very good performance both in constrained
environment such as defined by J2ME and on server side when used in
J2EE application servers.
Comment 1 John Guthrie 2008-09-17 00:16:21 EDT
I do have a small question about how the release tag should be numbered.  On the upstream web site, they only have downloadable ZIP files for versions up to 1.1.3.4c.  However, in their CVS tree they have tags for 1_1_4 and 1_1_4b.  (I grabbed that last tag as I documented in the .spec file.)  Since, I grabbed the code out of CVS, should there be a "cvs" string in the release, or is that not necessary since I was grabbing a specific CVS tag?
Comment 2 Mary Ellen Foster 2008-11-25 08:22:05 EST
Dunno about the version naming; your rationale sounds plausible to me but I could also see it going the other way.

A few rpmlint issues:

xmlpull-api.i386: W: non-standard-group Development/Java
(==> Development/Libraries ?)

xmlpull-api.i386: W: incoherent-version-in-changelog 1.1.4b-2 ['0:1.1.4b-2.fc9', '0:1.1.4b-2']
This goes away if you remove the "Epoch: 0" from the spec file. Is the epoch actually necessary? If so, the changelog entry should be 0:1.1.4b-2

xmlpull-api-javadoc.i386: W: non-standard-group Development/Documentation
(==> Documentation ?)
Comment 3 Jason Tibbitts 2009-03-24 22:38:23 EDT
FYI, the first and third rpmlint issues above aren't something we care about.  As for the second, you should generally not use "Epoch: 0" in a Fedora package.  And to address the question in comment #1, the answer depends on whether upstream believes that version 1.1.4b actually exists.  Some upstreams do tag releases but don't worry about generating tarballs; other upstreams might make a tag but wouldn't want to get bug reports for a version they didn't release.  So you need to ask them.

Some other comments:

Please remove the commented cruft from the specfile.  (Well, you can't remove the horrible license block from the top, of course, but you can remove the other stuff that just clutters 

If you are going to use to use all of those macro forms (%{__cp} and such), you need to use them consistently.  Which means bare "ln" and "mv" should not be used.  The spec file looks much cleaner if you just don't use them, but that's up to you.

Why move the pre-build jars to "jar.no" instead of just deleting them?  You can delete them all with a single find command, so your %prep section could just be two lines.
Comment 4 John Guthrie 2009-03-31 23:09:58 EDT
Before this bug gets closed, I just want to say that I have seen these comments now, and I should have a new spec files out soon.
Comment 5 John Guthrie 2009-03-31 23:54:52 EDT
(In reply to comment #3)
> FYI, the first and third rpmlint issues above aren't something we care about. 
> As for the second, you should generally not use "Epoch: 0" in a Fedora package.

The Epoch: 0 has been removed.

>  And to address the question in comment #1, the answer depends on whether
> upstream believes that version 1.1.4b actually exists.  Some upstreams do tag
> releases but don't worry about generating tarballs; other upstreams might make
> a tag but wouldn't want to get bug reports for a version they didn't release. 
> So you need to ask them.
> 
> Some other comments:
> 
> Please remove the commented cruft from the specfile.  (Well, you can't remove
> the horrible license block from the top, of course, but you can remove the
> other stuff that just clutters 

Done.

> If you are going to use to use all of those macro forms (%{__cp} and such), you
> need to use them consistently.  Which means bare "ln" and "mv" should not be
> used.  The spec file looks much cleaner if you just don't use them, but that's
> up to you.

I converted everything to bare commands.

> Why move the pre-build jars to "jar.no" instead of just deleting them?  You can
> delete them all with a single find command, so your %prep section could just be
> two lines.  

Done.

I have posted a new spec file: http://www.guthrie.info/RPMS/f10/xmlpull-api.spec
I have also posted a new SRPM: http://www.guthrie.info/RPMS/f10/xmlpull-api-1.1.4b-3.fc10.src.rpm

These are still using the same source.  I need to verify that the source code is still up to date.  If it is not, then I will be posting a new SRPM with new source tomorrow.
Comment 6 John Guthrie 2009-04-01 00:10:24 EDT
By the way, here is the rpmlint output from the latest code:

xmlpull-api-javadoc.i386: W: non-standard-group Development/Documentation
xmlpull-api.i386: W: non-standard-group Development/Java
2 packages and 0 specfiles checked; 0 errors, 2 warnings.
Comment 7 Jerry James 2009-08-21 11:10:51 EDT
Output from rpmlint:

xmlpull-api.x86_64: W: non-standard-group Development/Java
xmlpull-api-javadoc.x86_64: W: non-standard-group Development/Documentation
xmlpull-api.spec:39: W: non-standard-group Development/Java
xmlpull-api.spec:66: W: non-standard-group Development/Documentation
xmlpull-api.spec:140: W: libdir-macro-in-noarch-package (main package) %{_libdir}/gcj/%{name}
3 packages and 1 specfiles checked; 0 errors, 5 warnings.

All of which are fine.  We don't care about the group, and gcj forces you to use %{_libdir}.

MUST items:
OK: rpmlint output
OK: package named according to Package Naming Guidelines
OK: spec file name matches package name
OK: package meets packaging guidelines
OK: package license meets licensing guidelines
OK: license field matches actual license
OK: license file included in %doc [1]
OK: spec file in American English
OK: spec file is legible
OK: sources match upstream sources [2]
OK: package builds successfully on at least one primary arch (x86_64)
NA: appropriate use of ExcludeArch
OK: all build dependencies in BuildRequires
NA: proper locale handling
NA: proper use of ldconfig
NA: relocatable packages need rationale
OK: package owns all created directories
OK: no duplicate listings in %files
OK: permissions on files
OK: %clean section
OK: consistent use of macros
OK: code or permissible content
NA: large documentation in -doc subpackage
OK: nothing in %doc needed at runtime
NA: header files in -devel
NA: static libraries in -static
NA: Requires: pkgconfig
NA: .so files in -devel
NA: -devel requires main package
OK: no libtool archives
NA: proper installation of desktop file
OK: does not own files/dirs owned by other packages
OK: clean at start of %install
OK: all filenames are valid UTF-8

SHOULD items:
NA: ask upstream to include license file
NA: provide translated summary and description
OK: package builds in mock (only tried Fedora 11 x86_64)
??: package builds into binary RPMs on all supported arches (did not check)
OK: package functions as described (only able to test lightly)
OK: sane scriptlets
OK: subpackages require main package
NA: placement of pkgconfig files
NA: file dependencies

Footnotes:
[1] %doc also includes LICENSE_TESTS.txt, which seems odd, since the tests are neither run nor included in the binary package.

[2] With regard to comments #1 and #3, note that there have been more CVS checkins (in 2006!) since the 1.1.4b tag, and the log entries for those checkins refer to version 1.2-RC1.  There have been no messages to the user or dev mailing lists since 2007.  Is upstream dead?

Here are a few more changes I would like you to consider.  I won't block the review on any of these, but I think they are worth considering.
1. Make the -javadoc subpackage be noarch.
2. Add the doc subdirectory to %doc.
3. Make an -addons subpackage to hold (parts of) the addons/java subdirectory.  This may be more trouble than it is worth.  I'll leave that judgment call to you.
4. Make a -samples subpackage to hold (parts of) the src/java/samples subdirectory.  Ditto #3.
Comment 8 Jerry James 2009-09-21 10:59:48 EDT
John, if you still want to submit this package to Fedora, please respond within the next week.
Comment 9 Jerry James 2009-10-06 23:13:07 EDT
Due to no response from the submitter, I am closing this bug.

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