Bug 227059 - Review Request: httpunit-1.6.2-1jpp - Automated web site testing toolkit
Review Request: httpunit-1.6.2-1jpp - Automated web site testing toolkit
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tania Bento
Fedora Package Reviews List
:
Depends On: 227075 227113
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-02 12:36 EST by Rafael H. Schloming
Modified: 2014-12-01 18:13 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-20 10:57:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tbento: fedora‑review+
wtogami: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Rafael H. Schloming 2007-02-02 12:36:50 EST
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.
Comment 1 Permaine Cheung 2007-02-14 14:44:59 EST
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@redhat.com> - 0.6-4
  - And fix the link syntax.
 
  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
  - And fix the link syntax.
 
  * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
  - 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
Comment 2 Permaine Cheung 2007-02-14 16:26:11 EST
(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@redhat.com> - 0.6-4
>   - And fix the link syntax.
>  
>   * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com> 0.6-4
>   - And fix the link syntax.
>  
>   * Fri Jun 23 2006 Jesse Keating <jkeating@redhat.com>
>   - 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
Comment 3 Andrew Overholt 2007-02-15 11:33:16 EST
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
Comment 4 Permaine Cheung 2007-02-15 12:23:53 EST
(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


Comment 6 Tania Bento 2007-03-14 13:50:17 EDT
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.
Comment 7 Permaine Cheung 2007-03-14 17:03:44 EDT
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.
Comment 8 Tania Bento 2007-03-15 09:59:38 EDT
(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.
Comment 9 Permaine Cheung 2007-03-16 10:10:25 EDT
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.
Comment 10 Matt Wringe 2007-03-16 11:54:03 EDT
New Package CVS Request
=======================
Package Name: httpunit
Short Description: Automated web site testing toolkit
Owners: mwringe@redhat.com
Branches: devel

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