Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Merge Review: jakarta-commons-discovery https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225927 ------- Additional Comments From mwringe@xxxxxxxxxx 2007-04-04 18:23 EST ------- (In reply to comment #2) > Please fix items marked by X: > MUST: > * package is named appropriately > - match upstream tarball or project name > - try to match previous incarnations in other distributions/packagers for > consistency > - specfile should be %{name}.spec > - non-numeric characters should only be used in Release (ie. cvs or > something) > - for non-numerics (pre-release, CVS snapshots, etc.), see > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageRelease > - if case sensitivity is requested by upstream or you feel it should be > not just lowercase, do so; otherwise, use all lower case for the name > * is it legal for Fedora to distribute this? > - OSI-approved > - not a kernel module > - not shareware > - is it covered by patents? > - it *probably* shouldn't be an emulator > - no binary firmware > * license field matches the actual license. > * license is open source-compatible. > - use acronyms for licences where common > * specfile name matches %{name} > * verify source and patches (md5sum matches upstream, know what the patches do) > - if upstream doesn't release source drops, put *clear* instructions on > how to generate the the source drop; ie. > # svn export blah/tag blah > # tar cjf blah-version-src.tar.bz2 blah > * skim the summary and description for typos, etc. > * correct buildroot > - should be: > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > * if %{?dist} is used, it should be in that form (note the ? and % > locations) > X license text included in package and marked with %doc Fixed > - should the README.txt, RELEASE-NOTES.txt be marked as %doc as well? > * keep old changelog entries; use judgement when removing (too old? > useless?) > * packages meets FHS (http://www.pathname.com/fhs/) > * rpmlint on <this package>.srpm gives no output > - W: jakarta-commons-discovery non-standard-group Development/Libraries/Java - > this is OK > * changelog are OK > * Packager tag should not be used > * Vendor tag should not be used > * Distribution tag should not be used > * use License and not Copyright > * Summary tag should not end in a period > * if possible, replace PreReq with Requires(pre) and/or Requires(post) > * specfile is legible > - this is largely subjective; use your judgement > * package successfully compiles and builds on at least x86 > * BuildRequires are proper > - builds in mock will flush out problems here > - the following packages don't need to be listed in BuildRequires: > bash > bzip2 > coreutils > cpio > diffutils > fedora-release (and/or redhat-release) > gcc > gcc-c++ > gzip > make > patch > perl > redhat-rpm-config > rpm-build > sed > tar > unzip > which > * summary should be a short and concise description of the package > * description expands upon summary (don't include installation > instructions) > * make sure lines are <= 80 characters > * specfile written in American English > * make a -doc sub-package if necessary > - see > > http://fedoraproject.org/wiki/Packaging/Guidelines#head-9bbfa57478f0460c6160947a6bf795249488182b > * packages including libraries should exclude static libraries if possible > * don't use rpath > * config files should usually be marked with %config(noreplace) > * GUI apps should contain .desktop files > * should the package contain a -devel sub-package? > * use macros appropriately and consistently > - ie. %{buildroot} and %{optflags} vs. $RPM_BUILD_ROOT and $RPM_OPT_FLAGS > * don't use %makeinstall > * locale data handling correct (find_lang) > - if translations included, add BR: gettext and use %find_lang %{name} at the > end of %install > * consider using cp -p to preserve timestamps > * split Requires(pre,post) into two separate lines > * package should probably not be relocatable > * package contains code > - see http://fedoraproject.org/wiki/Packaging/Guidelines#CodeVsContent > - in general, there should be no offensive content > * package should own all directories and files > * there should be no %files duplicates > * file permissions should be okay; %defattrs should be present > * %clean should be present > * %doc files should not affect runtime > * if it is a web apps, it should be in /usr/share/%{name} and *not* /var/www > * verify the final provides and requires of the binary RPMs > will do this when this can be built in mock > * run rpmlint on the binary RPMs > will do this when this can be built in mock > > SHOULD: > * package should include license text in the package and mark it with %doc > * package should build on i386 > * package should build in mock > It doesn't build in mock currently: > javadoc: > [mkdir] Created dir: /builddir/build/BUILD/commons-discovery-0.4-src/dist > [mkdir] Created dir: /builddir/build/BUILD/commons-discovery-0.4-src/dist/docs > [mkdir] Created dir: > /builddir/build/BUILD/commons-discovery-0.4-src/dist/docs/api > [javadoc] Generating Javadoc > [javadoc] Javadoc execution > [javadoc] Unknown option: - > [javadoc] Parsing > /builddir/build/BUILD/commons-discovery-0.4-src/src/java/org/apache/commons/discovery/ResourceNameIterator.java > .... > [javadoc] 1 error. > > and when copying the files over, it fails with: > + mkdir -p > /var/tmp/jakarta-commons-discovery-0.4-2jpp.1.fc7-root-mockbuild/usr/share/javadoc/jakarta-commons-discovery-0.4 > + cp -pr 'dist/docs/api/*' > /var/tmp/jakarta-commons-discovery-0.4-2jpp.1.fc7-root-mockbuild/usr/share/javadoc/jakarta-commons-discovery-0.4 > cp: cannot stat `dist/docs/api/*': No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.1025 (%install) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.1025 (%install) > srpm that will actually build properly: https://mwringe.108.redhat.com/files/documents/175/335/jakarta-commons-discovery-0.4-2jpp.1.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review