Spec URL: http://people.redhat.com/rafaels/specs/httpunit-1.6.2-1jpp.spec SRPM URL: ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/SRPMS.free/httpunit-1.6.2-1jpp.src.rpm Description: HttpUnit emulates the relevant portions of browser behavior, including form submission, JavaScript, basic http authentication, cookies and automatic page redirection, and allows Java test code to examine returned pages either as text, an XML DOM, or containers of forms, tables, and links. A companion framework, ServletUnit is included in the package. Javadoc for httpunit Documentation for httpunit Demonstrations and samples for httpunit.
X indicates issues needed fixing. MUST: * package is named appropriately - match upstream tarball or project name - ok - try to match previous incarnations in other distributions/packagers for consistency - specfile should be %{name}.spec - ok - non-numeric characters should only be used in Release (ie. cvs or something) - ok - 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 - ok * is it legal for Fedora to distribute this? yes- MIT - 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. - ok * license is open source-compatible. - ok - use acronyms for licences where common * specfile name matches %{name} - ok * verify source and patches (md5sum matches upstream, know what the patches do) - ok - 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. X correct buildroot - should be: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) X if %{?dist} is used, it should be in that form (note the ? and % locations) Please fix Release: to 1jpp.1%{?dist} X license text included in package and marked with %doc license is not marked with %doc * 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: httpunit non-standard-group Development/Testing But this can be ignored. * changelog should be in one of these formats: * Fri Jun 23 2006 Jesse Keating <jkeating> - 0.6-4 - And fix the link syntax. * Fri Jun 23 2006 Jesse Keating <jkeating> 0.6-4 - And fix the link syntax. * Fri Jun 23 2006 Jesse Keating <jkeating> - 0.6-4 - And fix the link syntax. * Packager tag should not be used X Vendor tag should not be used X 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 - When adding gcj support, please get rid of BuildArch: noarch - please fix the javadoc symlink * 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) X make sure lines are <= 80 characters line 127 is longer than 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 X run rpmlint on the binary RPMs W: httpunit non-standard-group Development/Testing - ok W: httpunit no-documentation W: httpunit non-standard-group Development/Testing - ok W: httpunit-demo non-standard-group Development/Testing - ok W: httpunit-demo no-documentation W: httpunit-javadoc non-standard-group Development/Documentation - ok W: httpunit-javadoc dangerous-command-in-%post rm W: httpunit-javadoc dangerous-command-in-%postun rm W: httpunit-manual non-standard-group Development/Testing - ok W: httpunit-manual dangling-symlink /usr/share/doc/httpunit-manual-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 W: httpunit-manual symlink-should-be-relative /usr/share/doc/httpunit-manual-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 SHOULD: * package should include license text in the package and mark it with %doc * package should build on i386 * package should build in mock
(In reply to comment #1) > X indicates issues needed fixing. > MUST: > * package is named appropriately > - match upstream tarball or project name - ok > - try to match previous incarnations in other distributions/packagers for > consistency > - specfile should be %{name}.spec - ok > - non-numeric characters should only be used in Release (ie. cvs or > something) - ok > - 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 - ok > * is it legal for Fedora to distribute this? yes- MIT > - 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. - ok > * license is open source-compatible. - ok > - use acronyms for licences where common > * specfile name matches %{name} - ok > * verify source and patches (md5sum matches upstream, know what the patches do) - ok > - 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. > X correct buildroot > - should be: > %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Fixed. > X if %{?dist} is used, it should be in that form (note the ? and % > locations) > Please fix Release: to 1jpp.1%{?dist} Fixed. > X license text included in package and marked with %doc > license is not marked with %doc There's no license text included in the zip. > * 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: httpunit non-standard-group Development/Testing > But this can be ignored. > * changelog should be in one of these formats: > > * Fri Jun 23 2006 Jesse Keating <jkeating> - 0.6-4 > - And fix the link syntax. > > * Fri Jun 23 2006 Jesse Keating <jkeating> 0.6-4 > - And fix the link syntax. > > * Fri Jun 23 2006 Jesse Keating <jkeating> > - 0.6-4 > - And fix the link syntax. > > * Packager tag should not be used > X Vendor tag should not be used > X Distribution tag should not be used Got rid of these. > * 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 > - When adding gcj support, please get rid of BuildArch: noarch > - please fix the javadoc symlink > * 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) > X make sure lines are <= 80 characters > line 127 is longer than 80 characters Fixed. > * 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 > X run rpmlint on the binary RPMs > W: httpunit non-standard-group Development/Testing - ok > W: httpunit no-documentation It has no doc in the main package > W: httpunit non-standard-group Development/Testing - ok > W: httpunit-demo non-standard-group Development/Testing - ok > W: httpunit-demo no-documentation No docs in demo either. > W: httpunit-javadoc non-standard-group Development/Documentation - ok > W: httpunit-javadoc dangerous-command-in-%post rm > W: httpunit-javadoc dangerous-command-in-%postun rm Fixed javadoc stuff > W: httpunit-manual non-standard-group Development/Testing - ok > W: httpunit-manual dangling-symlink /usr/share/doc/httpunit-manual-1.6.2/api > /usr/share/javadoc/httpunit-1.6.2 > W: httpunit-manual symlink-should-be-relative > /usr/share/doc/httpunit-manual-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 > Don't know if there's anything that we can do about this. I've added a Requires: javadoc for doc subpackage. > > SHOULD: > * package should include license text in the package and mark it with %doc > * package should build on i386 Built fine. > * package should build in mock > spec file and srpm are available at: https://pcheung.108.redhat.com/files/documents/174/222/httpunit.spec https://pcheung.108.redhat.com/files/documents/174/223/httpunit-1.6.2-1jpp.1.src.rpm
Almost there: Xs are the only things that need doing MUST: * package is named appropriately * it is legal for Fedora to distribute this * license field matches the actual license. * license is open source-compatible. * specfile name matches %{name} X source and patches verified * md5sums match . it would be nice to have some comments regarding why the patches are necessary and/or what they do * skim the summary and description fine * correct buildroot * %{?dist} used properly X license text included in package and marked with %doc . there's no license text included in the zip * packages meet FHS X rpmlint on <this package>.srpm gives no output W: httpunit non-standard-group Development/Testing -> let's make this Development/Tools just for fun X changelog is fine except for %{?dist} in your entry - remove that * Packager tag not used * Vendor tag not used * Distribution tag not used * use License and not Copyright * Summary tag does not end in a period * no PreReq * specfile is legible X package successfully compiles and builds on at least x86 . can't build until jtidy and rhino are finished * BuildRequires are proper * summary should be a short and concise description of the package * description expands upon summary * make sure lines are <= 80 characters * specfile written in American English * -doc sub-package is fine * no libraries * no rpath * no config files * not a GUI app * no -devel sub-package? * macros used appropriately and consistently * no %makeinstall * no locale data * cp -p used * no Requires(pre,post) * package is not relocatable * package contains code * package owns all directories and files * no %files duplicates * file permissions okay; %defattrs present * %clean present * %doc files do not affect runtime * not a web app X verify the final provides and requires of the binary RPMs . can't do until jtidy and rhino done X run rpmlint on the binary RPMs . can't do until jtidy and rhino done SHOULD: X package should include license text in the package and mark it with %doc . nope X package should build on i386 . can't do until jtidy and rhino done X package should build in mock . can't do until jtidy and rhino done
(In reply to comment #3) > Almost there: Xs are the only things that need doing > > MUST: > * package is named appropriately > * it is legal for Fedora to distribute this > * license field matches the actual license. > * license is open source-compatible. > * specfile name matches %{name} > X source and patches verified > * md5sums match > . it would be nice to have some comments regarding why the patches are comments added > necessary and/or what they do > * skim the summary and description fine > * correct buildroot > * %{?dist} used properly > X license text included in package and marked with %doc > there's no license text included in the zip > * packages meet FHS > X rpmlint on <this package>.srpm gives no output > W: httpunit non-standard-group Development/Testing > > -> let's make this Development/Tools just for fun > Done > X changelog is fine except for %{?dist} in your entry - remove that Done > * Packager tag not used > * Vendor tag not used > * Distribution tag not used > * use License and not Copyright > * Summary tag does not end in a period > * no PreReq > * specfile is legible > X package successfully compiles and builds on at least x86 > . can't build until jtidy and rhino are finished > * BuildRequires are proper > * summary should be a short and concise description of the package > * description expands upon summary > * make sure lines are <= 80 characters > * specfile written in American English > * -doc sub-package is fine > * no libraries > * no rpath > * no config files > * not a GUI app > * no -devel sub-package? > * macros used appropriately and consistently > * no %makeinstall > * no locale data > * cp -p used > * no Requires(pre,post) > * package is not relocatable > * package contains code > * package owns all directories and files > * no %files duplicates > * file permissions okay; %defattrs present > * %clean present > * %doc files do not affect runtime > * not a web app will do the rest when jtidy and rhino are ready. > X verify the final provides and requires of the binary RPMs > . can't do until jtidy and rhino done > X run rpmlint on the binary RPMs > . can't do until jtidy and rhino done > > SHOULD: > X package should include license text in the package and mark it with %doc > . nope > X package should build on i386 > . can't do until jtidy and rhino done > X package should build in mock > . can't do until jtidy and rhino done
New spec file and srpm at https://pcheung.108.redhat.com/files/documents/174/222/httpunit.spec https://pcheung.108.redhat.com/files/documents/174/223/httpunit-1.6.2-1jpp.1.src.rpm
All the changes you made look good. I was able to build it on i386. I ran rpmlint on the binary RPMS and got the following output: W: httpunit no-documentation - W: httpunit-javadoc non-standard-group Development/Documentation W: httpunit-doc non-standard-group Development/Documentation W: httpunit-doc dangling-symlink /usr/share/doc/httpunit-doc-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 W: httpunit-doc symlink-should-be-relative /usr/share/doc/httpunit-doc-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 W: httpunit-demo non-standard-group Development/Testing W: httpunit-demo no-documentation They're all okay except for these two: W: httpunit-doc dangling-symlink /usr/share/doc/httpunit-doc-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 W: httpunit-doc symlink-should-be-relative /usr/share/doc/httpunit-doc-1.6.2/api /usr/share/javadoc/httpunit-1.6.2 I have also tried building on mock, but failed. It seems that rhino is still not ready.
Those warnings are there because this package has both a doc and a javadoc subpackage, and the api goes into the javadoc package, hence the symlink is used to reference to that.
(In reply to comment #7) > Those warnings are there because this package has both a doc and a javadoc > subpackage, and the api goes into the javadoc package, hence the symlink is used > to reference to that. Okay. I was also able to build on mock. APPROVED.
This bug should remained assigned to the reviewer, I was fixing it so I'll reassign to tbento. Added cc to mwringe since he needs to build it in plague.
New Package CVS Request ======================= Package Name: httpunit Short Description: Automated web site testing toolkit Owners: mwringe Branches: devel