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.
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.
I'll take this.
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
(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
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?
FYI, ATrpms has a CMake 2.8 package which replaces the system version.
(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?
Bug report for the main cmake package licensing question: BZ#820334
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
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.
(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.
(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.
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 ***
Thanks for reviewing this Richard.
New Package SCM Request ======================= Package Name: cmake28 Short Description: A package of CMake 2.8.x Owners: jgu Branches: el6 InitialCC:
Git done (by process-git-requests).
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.
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?
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?