Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 193889 - Review Request: ht2html - The www.python.org Web site generator
Summary: Review Request: ht2html - The www.python.org Web site generator
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT 193898
TreeView+ depends on / blocked
 
Reported: 2006-06-02 18:59 UTC by Igor Foox
Modified: 2010-08-02 16:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-02 16:23:26 UTC
Type: ---
Embargoed:
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Igor Foox 2006-06-02 18:59:57 UTC
Spec URL: http://people.redhat.com/ifoox/extras/ht2html.spec
SRPM URL: http://people.redhat.com/ifoox/extras/ht2html-2.0-1jpp_1fc.src.rpm
Description:
This script is called ht2html because it generates .html files from .ht template files. The format of these .ht files is essentially normal HTML, with a set of optional RFC 2822-like headers at the top of the file. These headers specify certain options that ht2html's various classes support.

This is my first package submission to Fedora Extras, so I need a sponsor.

Comment 1 Jason Tibbitts 2006-06-23 16:40:13 UTC
Just some comments until Hans feels confident sponsoring you:

Please just use a plain integer for the release number.

I suggest not compressing ht2html; it saves all of eleven bytes makes
maintanence incrementally nore difficult.

Source0: isn't a URL, and in addition that source file isn't available from
upstream.  (They only supply a .gz file.)  Suggest using
http://dl.sf.net/%{name}/%{name}-%{version}.tar.gz

Please don't use Vendor or Distribution.

I'm not sure why you have BR: python-devel; this package just copies files into
place.

I can find no information indicating that this software is in the public domain.
 Can you provide a reference?

RPM will compile all of the .py files; you will need to %ghost the .pyo files
which are generated.

Comment 2 Igor Foox 2006-06-23 20:39:39 UTC
Hi Jason, thanks for your comments. I've updated a new spec file and SRPM here:
http://people.redhat.com/ifoox/extras/ht2html.spec
http://people.redhat.com/ifoox/extras/ht2html-2.0-1jpp_2fc.src.rpm

> Please just use a plain integer for the release number.
This package is taken from jpackage.org, and I'd like to keep the versioning
consistent with theirs. Is the non-numeric release a big problem here?
 
> I suggest not compressing ht2html; it saves all of eleven bytes makes
> maintanence incrementally nore difficult.

Done.

> Source0: isn't a URL, and in addition that source file isn't available from
> upstream.  (They only supply a .gz file.)  Suggest using
> http://dl.sf.net/%{name}/%{name}-%{version}.tar.gz

Done.
 
> Please don't use Vendor or Distribution.

Done.

> I'm not sure why you have BR: python-devel; this package just copies files into
> place.

You're right, done.

> 
> I can find no information indicating that this software is in the public domain.
>  Can you provide a reference?

There seems to be no mention of licensing in the software itself, but I found
mention of  in the sourceforge net. However, rpmlint tells me that both 'Python
License' and '' are invalid. Is there a cannonical way to call this license?

> RPM will compile all of the .py files; you will need to %ghost the .pyo files
> which are generated.

I've %ghosted the .pyo files, and listed *.py and *.pyc files as seperate
entries in the %files section.

Comment 3 Igor Foox 2006-06-23 20:41:16 UTC
(In reply to comment #2)

> > I can find no information indicating that this software is in the public domain.
> >  Can you provide a reference?
> 
> There seems to be no mention of licensing in the software itself, but I found
> mention of  in the sourceforge net. However, rpmlint tells me that both 'Python
> License' and '' are invalid. Is there a cannonical way to call this license?

Sorry this should read:
There seems to be no mention of licensing in the software itself, but I found
mention of Python License (CNRI Python License) in the sourceforge net. However,
rpmlint tells me that both 'Python
License' and 'Python License (CNRI Python License)' are invalid. Is there a
cannonical way to call this license?

Comment 4 Jason Tibbitts 2006-06-23 23:35:31 UTC
(In reply to comment #2)

> This package is taken from jpackage.org, and I'd like to keep the versioning
> consistent with theirs. Is the non-numeric release a big problem here?

The guidelines are clear: http://fedoraproject.org/wiki/Packaging/NamingGuidelines

Non-Numeric Version in Release

There are two cases in which non-numeric versions occur in the Release field:

    * Pre-release packages
    * Snapshot packages

This package is neither.  We want simple integer release numbers when possible.
 Just imagine what this package would look like with a proper dist tag added:
"ht2html-2.0-1jpp_2fc.fc6.rpm".  That's just insane.

> There seems to be no mention of licensing in the software itself, but I found
> mention of  in the sourceforge net. However, rpmlint tells me that both 'Python
> License' and 'Python License (CNRI Python License)' are invalid. Is there a
cannonical way to call this license?

rpmlint can be a bit confusing; in this case, the valid licenses accepted are
overridden by a Fedora-specific file /usr/share/rpmlint/config.  The string to
use is "Python Software Foundation License".  However, honestly with absolutely
no license mentioned in the source, you really do need to contact upstream and
get some sort of statement.  When you get that, include the correspondence in
the package.  (In a perfect world they'd make a new release which includes a
license statement, but this package is pretty old so I doubt that would happen.)

Comment 5 Igor Foox 2006-06-26 17:41:37 UTC
New files:
http://people.redhat.com/ifoox/extras/ht2html-2.0-1.src.rpm
http://people.redhat.com/ifoox/extras/ht2html.spec

(In reply to comment #4)
> Non-Numeric Version in Release

I fixed this, changing the release to simply 1.

> 
> > There seems to be no mention of licensing in the software itself, but I found
> > mention of  in the sourceforge net. However, rpmlint tells me that both 'Python
> > License' and 'Python License (CNRI Python License)' are invalid. Is there a
> cannonical way to call this license?
> 
> rpmlint can be a bit confusing; in this case, the valid licenses accepted are
> overridden by a Fedora-specific file /usr/share/rpmlint/config.  The string to
> use is "Python Software Foundation License".  However, honestly with absolutely
> no license mentioned in the source, you really do need to contact upstream and
> get some sort of statement.  When you get that, include the correspondence in
> the package.  (In a perfect world they'd make a new release which includes a
> license statement, but this package is pretty old so I doubt that would happen.)

On friday the mailing list archives on sourceforge were unavailable. Today I
found a message [1] to the ML from the main author of ht2html, stating that it
is licensed under the PSF license. So I chaned the license to Python Software
Foundation License".

[1] - http://sourceforge.net/mailarchive/forum.php?thread_id=1785154&forum_id=8327

Comment 6 Jason Tibbitts 2006-07-24 15:54:25 UTC
Let's try to get things moving.  Igor, I'll sponsor you.  I'll work up a full
review in a minute, but one thing that I can immediately see should be done is
to take the mailing list correspondence and include it in the package so that
there's some statement of the license there.


Comment 7 Igor Foox 2006-07-24 17:34:29 UTC
Hi Jason,

Thanks again for looking at this. Here are the new files:

New files:
http://people.redhat.com/ifoox/extras/ht2html-2.0-2.src.rpm
http://people.redhat.com/ifoox/extras/ht2html.spec

I just included a comment that references the ML thread above just above the
License tag.

Should I also include a %{?dist} tag in the release?


Comment 8 Jason Tibbitts 2006-07-24 17:52:20 UTC
Honestly I'd actually copy the relevant text of that message into a file that
you include as %doc, and also include the URL of the original along with a bit
of explanation.  Someone with an installed package who wants to check the
license won't have access to the specfile.  I also don't think including a just
URL is sufficient, especially given how difficult sourceforge can be to reach
sometimes.

I personally would always use the dist tag because of the amount of work it
saves when maintaining identical packages across multiple distribution releases.
 But it's up to you.

I note that the final package has no requirement on Python.  I believe this is a
blocker.

Review:
* source files match upstream:
   925d359f7db48c44ed0bc3044cebd3f0  ht2html-2.0.tar.gz
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
X dist tag is present (not a blocker but you probably want to use it)
* build root is correct.
* license field matches the actual license.
X license is open source-compatible.  Statement of license should be included as
%doc in the package.
* latest version is being packaged.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (development, x86_64).
* noarch package; no debuginfo.
* rpmlint is silent.
X final provides and requires: missing python requirement.
   ht2html = 2.0-2
  =
   /bin/sh
   /usr/bin/env
* %check is not present; no test suite upstream.
* no shared libraries are present.
* 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.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

Comment 9 Igor Foox 2006-07-24 18:47:20 UTC
New files:
http://people.redhat.com/ifoox/extras/ht2html-2.0-3.src.rpm
http://people.redhat.com/ifoox/extras/ht2html.spec


I've created a LICENSE file that explains the situation and provides the actualy
license, as well as quotes and references the ML post.

I've added a Requires for Python and also a %{?dist} to the release.

Comment 10 Jason Tibbitts 2006-07-24 23:58:29 UTC
Unfortunately the Python requirement results in a package that won't install:

Error: Missing Dependency: Python is needed by package ht2html

The requirement should be for "python".  Other than that one issue, everything
looks good.  The information you include in LICENSE is especially complete.

Apart from changing the case of a single letter, I think this is ready to go, so
I'll go ahead and approve and you can fix it when you check in.

I see you've already done the CLA, so go ahead and request your cvsextras and
fedorabugs memberships and I'll take care of them.  Then you can check in and
request your builds.  Let me know if you have any problems.

APPROVED

Comment 11 Jason Tibbitts 2006-08-08 22:14:26 UTC
Any reason this hasn't been built yet?  I see that it's in CVS and has branched
for FC-5, but I don't see any packages in the repository and of course this bug
hasn't been closed.

Comment 12 Jason Tibbitts 2006-08-30 06:01:25 UTC
It's been another three weeks.  Is anything going to happen here?

Comment 13 Igor Foox 2006-09-02 16:23:26 UTC
My appologies for the very long delay, I was away and couldn't attend to these
packages. They have now been built.

Comment 14 Milos Jakubicek 2010-08-02 06:10:51 UTC
Package Change Request
======================
Package Name: ht2html
New Branches: EL-5 EL-6
Owners: mjakubicek rlandmann

Comment 15 Kevin Fenzi 2010-08-02 16:22:51 UTC
GIT done (by process-git-requests).


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