Bug 427484

I didn't run rpmlint to see if it dinged the license, but the license in the
spec file (OPL + restrictions) is not allowed in Fedora:

http://fedoraproject.org/wiki/Licensing

For what reason are you using the optional restrictions?  All the Red Hat
branding is already protected by trademark.

(In reply to comment #1)
> I didn't run rpmlint to see if it dinged the license, but the license in the
> spec file (OPL + restrictions) is not allowed in Fedora:
> 
> http://fedoraproject.org/wiki/Licensing
> 
> For what reason are you using the optional restrictions?  All the Red Hat
> branding is already protected by trademark.

The main goal here is to allow Red Hat writers and developers to use Fedora as
their main work environment for documentation.

The Red Hat documentation uses the above license. The xml & images in this
package is embedded in the books at build time. I thought it easiest to use the
same license to avoid licensing conflicts ... some may read that as "not have to
talk to lawyers" :D

I need a license that allows the xml and images to be used in OPL + Restrictions
books.

(In reply to comment #2)
 
> The main goal here is to allow Red Hat writers and developers to use Fedora as
> their main work environment for documentation.

Which is, ironically, an argument for freeing Red Hat documentation from the
additional OPL restrictions.
 
> The Red Hat documentation uses the above license. The xml & images in this
> package is embedded in the books at build time. I thought it easiest to use the
> same license to avoid licensing conflicts ... some may read that as "not have to
> talk to lawyers" :D

The lawyers have already spoken, and thus we have:

http://fedoraproject.org/wiki/Licensing

FWIW, we just had a test case of this recently.  Several guides that went with
system-config-* packages and the PHP Manual were under the OPL with options. 
The result is the former changed their license, and the PHP Manual is not going
to appear in Fedora 9 because upstream did not want to change or dual-license.

> I need a license that allows the xml and images to be used in OPL + Restrictions
> books.

If Red Hat is the original copyright holder, they can dual-license under the OPl
without options.

I'll also get some to ask the lawyers if OPL licensed material can be included
in OPL + restrictions stuff.

No one is bugging me for this one either.

> I didn't run rpmlint to see if it dinged the license, but the license in the
> spec file (OPL + restrictions) is not allowed in Fedora:

The package is now licensed CC-BY-SA, so this should no longer be a problem. Re-opening request

New spec file:
https://fedorahosted.org/releases/p/u/publican/publican-redhat.spec

New SRPM:
http://rlandmann.fedorapeople.org/publican/publican-redhat-2.0-0.fc13.src.rpm

publican-redhat.spec:22: W: unversioned-explicit-obsoletes documentation-devel-%{brand}
publican-redhat.spec:14: W: mixed-use-of-spaces-and-tabs (spaces: line 14, tab: line 5)

Please fix the mixed-use-of-spaces-and-tabs.  I don't think the unversioned-explicit-obsoletes is an issue. (However, someone correct me if I'm wrong).

More to come.

[nb@newharmony01 noarch]$ rpmlint publican-redhat-2.0-0.fc13.noarch.rpm 
publican-redhat.noarch: W: incoherent-version-in-changelog 2.0 ['2.0-0.fc13', '2.0-0']
** Please fix the changelog

publican-redhat.noarch: W: obsolete-not-provided documentation-devel-RedHat
** Please add Provides: documentation-devel-RedHat if you are going to obsolete it

publican-redhat.noarch: E: version-control-internal-file /usr/share/publican/Common_Content/RedHat/xsl/.svn/text-base/html-single.xsl.svn-base
** Please remove the .svn directory in your spec

publican-redhat.noarch: W: hidden-file-or-dir /usr/share/publican/Common_Content/RedHat/xsl/.svn
publican-redhat.noarch: W: hidden-file-or-dir /usr/share/publican/Common_Content/RedHat/xsl/.svn
publican-redhat.noarch: E: version-control-internal-file /usr/share/publican/Common_Content/RedHat/xsl/.svn/text-base/html.xsl.svn-base
publican-redhat.noarch: E: version-control-internal-file /usr/share/publican/Common_Content/RedHat/xsl/.svn/text-base
publican-redhat.noarch: E: version-control-internal-file /usr/share/publican/Common_Content/RedHat/xsl/.svn/text-base/pdf.xsl.svn-base
publican-redhat.noarch: E: version-control-internal-file /usr/share/publican/Common_Content/RedHat/xsl/.svn/entries
1 packages and 0 specfiles checked; 5 errors, 4 warnings.

(In reply to comment #7)
> publican-redhat.spec:22: W: unversioned-explicit-obsoletes
> documentation-devel-%{brand}
> publican-redhat.spec:14: W: mixed-use-of-spaces-and-tabs (spaces: line 14, tab:
> line 5)
> 
> Please fix the mixed-use-of-spaces-and-tabs.  I don't think the
> unversioned-explicit-obsoletes is an issue. (However, someone correct me if I'm
> wrong).

It's a problem if anyone ever wishes to introduce a package (with any version number) called documentation-devel-%{brand} in the future. It's not unheard of for packages to be renamed one way and then back to the original name, or completely new packages to be introduced with names that have been used for something else in the past, so best practice is to use a versioned obsolete such as:

Obsoletes: documentation-devel-%{brand} <= V-R

where V-R is the version/release (including the dist tag, if any) of the last build using the old name.

Thanks Nick and Paul

New spec and srpm are here:

http://rlandmann.fedorapeople.org/publican/publican.spec

http://rlandmann.fedorapeople.org/publican/publican-redhat-2.0-1.fc13.src.rpm

I have 

* removed the .svn directories (oops -- very embarrassing!)
* specified Obsoletes:	documentation-devel-%{brand} <= 0.4-0
* specified Provides:	documentation-devel-%{brand}-%{version}-%{release}
* fixed the mixed use of tabs and spaces that I could find

However, rpmlint still warns:
* "obsolete-not-provided" and "unversioned-explicit-provides" -- it seems that it isn't parsing "documentation-devel-%{brand}-%{version}-%{release}", but as you can see, the obsolete is provided for, and the provides is indeed versioned
* it's still complaining about mixed use of spaces and tabs in the spec file: "mixed-use-of-spaces-and-tabs (spaces: line 22, tab: line 191)" -- however, there's certainly no spaces in line 22, and line 191 does not exist at all, so I'm not sure what else to do here.

(In reply to comment #10)

> New spec and srpm are here:
> 

Sorry -- Spec URL is:

http://rlandmann.fedorapeople.org/publican/publican-redhat.spec

(In reply to comment #10)

> * it's still complaining about mixed use of spaces and tabs in the spec file:
> "mixed-use-of-spaces-and-tabs (spaces: line 22, tab: line 191)" -- however,
> there's certainly no spaces in line 22, and line 191 does not exist at all, so
> I'm not sure what else to do here.    

Ah! Found and fixed -- no more warnings :)

You should have:

Provides:	documentation-devel-%{brand} = %{version}-%{release}
Obsoletes:	documentation-devel-%{brand} <= 0.4-0

That should fix the complaints about provides and obsoletes.

However, I note that the original submission in this review is for documentation-devel-RedHat-0.4-0.fc9, which is a higher release number (with the dist tag) than 
documentation-devel-RedHat-0.4-0. So I'd change the obsolete to:

Obsoletes:	documentation-devel-%{brand} < 0.4-1

Or maybe even:

Obsoletes:	documentation-devel-%{brand} < %{version}-%{release}

Many thanks Paul -- that does indeed fix the problems! :)

New spec and SRPM:

http://rlandmann.fedorapeople.org/publican/publican-redhat.spec

http://rlandmann.fedorapeople.org/publican/publican-redhat-2.0-2.fc13.src.rpm

I've also made the same changes to the other Publican brand package currently up for review (JBoss) -- https://bugzilla.redhat.com/show_bug.cgi?id=427483

[nb@sanjose01 SPECS]$ rpmlint publican-redhat.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
[nb@sanjose01 SRPMS]$ rpmlint publican-redhat-2.0-2.fc13.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[nb@sanjose01 SOURCES]$ sha1sum publican-redhat-2.0.tgz 
9568e41e868fbf507777ed841e2cbc46ae7c4cae  publican-redhat-2.0.tgz
[nb@sanjose01 SOURCES]$ sha1sum publican-redhat-2.0.tgz.1
9568e41e868fbf507777ed841e2cbc46ae7c4cae  publican-redhat-2.0.tgz.1

[YES] specfiles match
[YES] source files match upstream
[YES] package meets naming and versioning guidelines.
[YES] spec is properly named, cleanly written, and uses macros consistently.
[YES] dist tag is present.
[YES] build root is correct.
[YES] license field matches the actual license.
[YES] license is open source-compatible.
[YES] license text included in package.
[YES] latest version is being packaged.
[YES] BuildRequires are proper.
[YES] compiler flags are appropriate.
[YES] %clean is present. 
[YES] package builds in mock.
[YES] package installs properly.
[N/A] debuginfo package looks complete.
[YES] rpmlint is silent.
[YES] final provides and requires are sane
[N/A] %check is present and all tests pass:
[YES] no shared libraries are added to the regular linker search paths.
[YES] owns the directories it creates. 
[YES] doesn't own any directories it shouldn't.
[YES] no duplicates in %files.
[YES] file permissions are appropriate.
[YES] scriptlets match those on ScriptletSnippets page.
[YES] code, not content.
[YES] documentation is small, so no -docs subpackage is necessary.
[YES] %docs are not necessary for the proper functioning of the package.
[YES] no headers.
[YES] no pkgconfig files.
[YES] no libtool .la droppings.
[N/A] desktop files valid and installed properly.

This package is APPROVED

New Package SCM Request
=======================
Package Name: publican-redhat
Short Description: common files and templates needed to build documentation with the Red Hat brand with Publican.
Owners: jfearn rlandmann
Branches: f12 f13 f14
InitialCC:

The bug summary says "publican-RedHat"; the requested package name is "publican-redhat".  Which did you actually want?  Please adjust either the SCM request or the bug summary so that they match.

Thanks Jason -- publican-redhat is correct; summary adjusted accordingly

Git done (by process-git-requests).

Rudi, can you build this so we can resolve this bug?

Thanks Nick -- I built and pushed this last week:

http://koji.fedoraproject.org/koji/buildinfo?buildID=190706

was there something else I needed to do in this bug?

(In reply to comment #22)
> Thanks Nick -- I built and pushed this last week:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=190706
> 
> was there something else I needed to do in this bug?

Yes, close it :)

(In reply to comment #23)

> Yes, close it :)

Ah! Thanks :)