Bug 819678 - (cmake28) Review Request: cmake28 - A package of CMake 2.8.x for EL6
Review Request: cmake28 - A package of CMake 2.8.x for EL6
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Richard Shaw
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FEniCS
  Show dependency treegraph
 
Reported: 2012-05-07 20:21 EDT by Jonathan Underwood
Modified: 2013-10-28 08:00 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-15 10:26:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
hobbes1069: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2012-05-07 20:21:50 EDT
Spec URL: http://jgu.fedorapeople.org/cmake28.spec
SRPM URL: http://jgu.fedorapeople.org/cmake28-2.8.8-1.el6.src.rpm
Description: Currently RHEL6 ships with CMake 2.6.x which is very old. This is a parallel installable package of the 2.8.x release of CMake - executable etc have been renamed. The idea is that this exists in EL6 until RHEL6 gets an update. If ever.
Comment 1 Jonathan Underwood 2012-05-07 20:30:02 EDT
For reference, this bug asks the RHEL6 maintainer to update to CMake 2.8, and has no response:

https://bugzilla.redhat.com/show_bug.cgi?id=606892

This was my motivation for developing the cmake28 package. If RHEL ships a more up to date package, we can simply retire the cmake28 package.
Comment 2 Richard Shaw 2012-05-08 09:13:53 EDT
I'll take this.
Comment 3 Richard Shaw 2012-05-08 09:40:23 EDT
Quick spec review:

1. I see some things that are no longer needed like BuildRoot:, rm -rf $RPM_BUILD_ROOT in %install, %clean, and %defattr in %files but I'm assuming that these are in the Fedora cmake package so I guess it's not worth deviating from their package. 

2. Should the Require for the -gui package be arch dependent? i.e.:
Requires:       %{name} = %{version}-%{release}
to
Requires:       %{name}${?_isa} = %{version}-%{release}


There's a lot of rpmlint output but I'm assuming it's largely the same as the regular cmake package in Fedora. The only two things I think should be fixed are:
cmake28.src:24: W: mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 24)
cmake28.x86_64: E: non-executable-script /usr/share/cmake28/Modules/SquishRunTestCase.sh 0644L /bin/sh
Comment 4 Jonathan Underwood 2012-05-08 13:40:29 EDT
(In reply to comment #3)
> Quick spec review:
> 
> 1. I see some things that are no longer needed like BuildRoot:, rm -rf
> $RPM_BUILD_ROOT in %install, %clean, and %defattr in %files but I'm assuming
> that these are in the Fedora cmake package so I guess it's not worth deviating
> from their package. 
> 

Yes, I took the approach of deviating as little as possible. These things are harmless, but enable build on older rhel, if you were masochistic enough to try.

> 2. Should the Require for the -gui package be arch dependent? i.e.:
> Requires:       %{name} = %{version}-%{release}
> to
> Requires:       %{name}${?_isa} = %{version}-%{release}
> 

Probably so - have changed this.

> 
> There's a lot of rpmlint output but I'm assuming it's largely the same as the
> regular cmake package in Fedora. 

Yes - I'm loathed to deviate too much from the original package.

> The only two things I think should be fixed
> are:
> cmake28.src:24: W: mixed-use-of-spaces-and-tabs (spaces: line 9, tab: line 24)

Fixed.

> cmake28.x86_64: E: non-executable-script
> /usr/share/cmake28/Modules/SquishRunTestCase.sh 0644L /bin/sh

This is intentional, the header of that file says:

#
# This script launches a GUI test using Squish.  You should not call
# the script directly; instead, you should acces it via the
# SQUISH_ADD_TEST macro that is defined in FindSquish.cmake.

Spec URL: http://jgu.fedorapeople.org/cmake28.spec
SRPM URL: http://jgu.fedorapeople.org/cmake28-2.8.8-2.el6.src.rpm
Comment 5 Richard Shaw 2012-05-08 14:53:13 EDT
Ok, one more thing that I'd like reported here even if we can't fix it. I'm wondering if the license statement is complete. Using licensecheck and some tricks I get the following:

$ licensecheck -r . | awk 'match($0,":"){print substr($0,RSTART+2)}' | sort | uniq -c | sort -g -r
    768 UNKNOWN
    636 *No copyright* UNKNOWN
    105 BSD (2 clause)
     90 GENERATED FILE
     37 MIT/X11 (BSD like)
     19 zlib/libpng
     11 *No copyright* GENERATED FILE
      9 BSD (3 clause)
      4 GPL (with incorrect FSF address)
      2 ISC
      2 GPL (v3 or later)
      2 GPL
      2 BSD (4 clause)
      2 BSD (2 clause) GENERATED FILE
      1 *No copyright* ISC

I don't see anything that's incompatible as far as I can tell but I'm no licensing guru but shouldn't the License field be something more like:

License: BSD and MIT and GPL and zlib

or something like that?
Comment 6 Kevin Kofler 2012-05-08 15:52:22 EDT
FYI, ATrpms has a CMake 2.8 package which replaces the system version.
Comment 7 Richard Shaw 2012-05-08 17:11:28 EDT
(In reply to comment #6)
> FYI, ATrpms has a CMake 2.8 package which replaces the system version.

Well ATrpms doesn't play by all the same rules anyway :)

Since you dropped in, can you comment on my license analysis?
Comment 8 Jonathan Underwood 2012-05-09 12:24:48 EDT
Bug report for the main cmake package licensing question: BZ#820334
Comment 9 Jonathan Underwood 2012-05-09 12:26:20 EDT
With fixed License field:

Spec URL: http://jgu.fedorapeople.org/cmake28.spec
SRPM URL: http://jgu.fedorapeople.org/cmake28-2.8.8-3.el6.src.rpm
Comment 10 Richard Shaw 2012-05-09 12:39:51 EDT
Ok, this looks pretty good so there's only two things I think we need at this point:

1. There doesn't seem to be any sort of license file distributed with the source, at least not one that's obvious like LICENSE or COPYING. 

http://www.cmake.org/cmake/project/license.html

says the same thing as Copyright.txt in the source but there's no specific license referenced.  

2. I'd like to wait until the maintainer comments on 820334 before we call it approved, although it can always be fixed later. The license field is set by good faith effort to be in compliance with the guidelines.
Comment 11 Jonathan Underwood 2012-05-09 19:31:09 EDT
(In reply to comment #10)
> Ok, this looks pretty good so there's only two things I think we need at this
> point:
> 
> 1. There doesn't seem to be any sort of license file distributed with the
> source, at least not one that's obvious like LICENSE or COPYING. 
> 
> http://www.cmake.org/cmake/project/license.html
> 
> says the same thing as Copyright.txt in the source but there's no specific
> license referenced.  
> 

I'm not sure I follow here - Copyright.txt is essentially the license file, as it stipulates the license for the project, modulo the files with differing licenses where it says:

"Some source files contain additional notices of original copyright by their contributors; see each source for details.  Third-party software packages supplied with CMake under compatible licenses provide their own copyright notices documented in corresponding subdirectories." 

I guess I'm not sure what you're asking for that's not in Copyright.txt ?


> 2. I'd like to wait until the maintainer comments on 820334 before we call it
> approved, although it can always be fixed later. The license field is set by
> good faith effort to be in compliance with the guidelines.

OK I am happy to wait a bit for this, but I don't think this should be a blocker in itself.
Comment 12 Richard Shaw 2012-05-09 20:05:11 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > Ok, this looks pretty good so there's only two things I think we need at this
> > point:
> > 
> > 1. There doesn't seem to be any sort of license file distributed with the
> > source, at least not one that's obvious like LICENSE or COPYING. 
> > 
> > http://www.cmake.org/cmake/project/license.html
> > 
> > says the same thing as Copyright.txt in the source but there's no specific
> > license referenced.  
> > 
> 
> I'm not sure I follow here - Copyright.txt is essentially the license file, as
> it stipulates the license for the project, modulo the files with differing
> licenses where it says:

I guess I was confused since it doesn't come out and say "This is a BSD license" like GPL does. Licensecheck says Copyright.txt is BSD (3 Clause). OK, moving on :)


> > 2. I'd like to wait until the maintainer comments on 820334 before we call it
> > approved, although it can always be fixed later. The license field is set by
> > good faith effort to be in compliance with the guidelines.
> 
> OK I am happy to wait a bit for this, but I don't think this should be a
> blocker in itself.

I figure we give him a day or two and just run with it after that and fix it later if anything needs to be changed.
Comment 13 Richard Shaw 2012-05-10 09:21:27 EDT
Ok, the result of bug 820334 works for me. 

+: OK
-: must be fixed
=: should be fixed (at your discretion)
?: Question or clairification needed
N: not applicable

MUST:
[+] rpmlint output: shown in comment.
[+] follows package naming guidelines
[+] spec file base name matches package name
[+] package meets the packaging guidelines
[+] package uses a Fedora approved license: BSD and MIT and zlib
[+] license field matches the actual license.
[+] license file is included in %doc: Copyright.txt
[+] spec file is in American English
[+] spec file is legible
[+] sources match upstream: md5sum matches (ba74b22c788a0c8547976b880cd02b17)
[+] package builds on at least one primary arch: Tested x86_64
[N] appropriate use of ExcludeArch
[+] all build requirements in BuildRequires
[N] spec file handles locales properly
[N] ldconfig in %post and %postun
[+] no bundled copies of system libraries
[+] no relocatable packages
[+] package owns all directories that it creates
[+] no files listed twice in %files
[+] proper permissions on files
[+] consistent use of macros
[+] code or permissible content
[N] large documentation in -doc
[+] no runtime dependencies in %doc
[N] header files in -devel
[N] static libraries in -static
[N] .so in -devel
[N] -devel requires main package
[+] package contains no libtool archives
[+] package contains a desktop file, uses desktop-file-install/validate
[+] package does not own files/dirs owned by other packages
[+] all filenames in UTF-8

SHOULD:
[+] query upstream for license text
[N] description and summary contains available translations
[+] package builds in mock
[+] package builds on all supported arches: Tested x86_64
[=] package functions as described: Not tested
[+] sane scriptlets
[+] subpackages require the main package
[+] placement of pkgconfig files
[+] file dependencies versus package dependencies
[+] package contains man pages for binaries/scripts

*** APPROVED ***
Comment 14 Jonathan Underwood 2012-05-10 09:42:40 EDT
Thanks for reviewing this Richard.
Comment 15 Jonathan Underwood 2012-05-10 09:47:57 EDT
New Package SCM Request
=======================
Package Name: cmake28 
Short Description: A package of CMake 2.8.x 
Owners: jgu
Branches: el6
InitialCC:
Comment 16 Jon Ciesla 2012-05-10 10:48:32 EDT
Git done (by process-git-requests).
Comment 17 Richard Shaw 2012-06-15 10:26:43 EDT
Looks like you forgot to add the BZ# to the update so it wasn't automatically closed when the package made it to stable. Closing.
Comment 18 Björn "besser82" Esser 2013-10-26 09:33:17 EDT
As Richard Shaw told me in rhbz #1023623 I'm requesting a branch for el5, too.

#####

Package Change Request
======================
Package Name: cmake28
New Branches: el5
Owners: besser82 jgu
InitialCC: ml-sig

Jon:  Can you please add InitialCC: ml-sig to el6-branch, too?
Comment 19 Björn "besser82" Esser 2013-10-26 09:42:36 EDT
Forgot to add `hobbes1069` to list of owners.  Here's the corrected SCM-change-request:

Package Change Request
======================
Package Name: cmake28
New Branches: el5
Owners: besser82 jgu hobbes1069
InitialCC: ml-sig

Jon:  Can you please add InitialCC: ml-sig to el6-branch, too?
Comment 20 Jon Ciesla 2013-10-28 08:00:38 EDT
Git done (by process-git-requests).

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