Taken. :)

Informal review of your spec file. My comments are in order of the spec file lines.

* MUST: Remove the Group: line. This tag is deprecated since Fedora 17.
https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview

* SHOULD: You can use the %{url} macro to shorten the links:
> URL:            https://bitbucket.org/verateam/vera/wiki/Home
> Source0:        https://bitbucket.org/verateam/vera/downloads/%{name}-%{version}.tar.gz
URL:            https://bitbucket.org/verateam/vera
Source0:        %{url}/downloads/%{name}-%{version}.tar.gz

* MUST: Where do you have the patch from? Please add a comment. You could inform upstream and use a link into the upstream tracker.
> Patch0:         0001-add_LIB_SUFFIX_to_lib_install_rules.patch

* SHOULD: Please add popd at the end of %build to identicate where your pushd environment ends.
> %build
> mkdir build
> pushd build

* SHOULD: Move the following rm line from %install into separate %clean section and better use the more commonly used %{buildroot} macro instead. Instructions to clean out the build root. Note that this section is now redundant in Fedora and is only necessary for EPEL.
https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview
> %install
> rm -rf $RPM_BUILD_ROOT
%clean
rm -rf %{buildroot}

* SHOULD: The README.txt file can go outside of the conditional to avoid further confusion.
> %files
> %if (0%{?rhel} == 06)
> %doc README.txt LICENSE_1_0.txt
> %else
> %doc README.txt
> %license LICENSE_1_0.txt
> %endif
%files
%if (0%{?rhel} == 06)
%doc LICENSE_1_0.txt
%else
%license LICENSE_1_0.txt
%endif
%doc README.txt

* SHOULD: Use the %{name] macro consistently. Also, there should not be an extension to any manpage cause rpmbuild can do the compression magically. For the documentation folder you can use the shorter %{_pkgdocdir} macro.
> %{_bindir}/vera++
…
> %{_datadir}/man/man1/vera++.1.gz
> %{_datadir}/%{name}/doc/vera++.html
%{_bindir}/{name}
…
%{_datadir}/man/man1/%{name}.1*
%{_pkgdocdir}/%{name}.html

* SHOULD: Why do you package the cmake and tcl files? Those look like source or general development files to me. Shouldn't they be placed into a -devel subpackage? Maybe do not include them at all (if in doubt).
> %{_libdir}/%{name}/*.cmake
> %{_libdir}/%{name}/*.cmake.in
…
> %{_libdir}/%{name}/rules/*.tcl
> %{_libdir}/%{name}/transformations/*.tcl

I could do also an official fedora-review run when my questions are answered.

(In reply to Raphael Groner from comment #2)
> * MUST: Remove the Group: line. This tag is deprecated since Fedora 17.
> https://fedoraproject.org/wiki/
> How_to_create_an_RPM_package#SPEC_file_overview

So should I remove this even if I'm targeting EPEL6?

> * SHOULD: You can use the %{url} macro to shorten the links:
> > URL:            https://bitbucket.org/verateam/vera/wiki/Home
> > Source0:        https://bitbucket.org/verateam/vera/downloads/%{name}-%{version}.tar.gz
> URL:            https://bitbucket.org/verateam/vera
> Source0:        %{url}/downloads/%{name}-%{version}.tar.gz

Fixed, thanks.

> * MUST: Where do you have the patch from? Please add a comment. You could
> inform upstream and use a link into the upstream tracker.
> > Patch0:         0001-add_LIB_SUFFIX_to_lib_install_rules.patch

Fixed

> * SHOULD: Please add popd at the end of %build to identicate where your
> pushd environment ends.
> > %build
> > mkdir build
> > pushd build

Fixed

> * SHOULD: Move the following rm line from %install into separate %clean
> section and better use the more commonly used %{buildroot} macro instead.
> Instructions to clean out the build root. Note that this section is now
> redundant in Fedora and is only necessary for EPEL.
> https://fedoraproject.org/wiki/
> How_to_create_an_RPM_package#SPEC_file_overview
> > %install
> > rm -rf $RPM_BUILD_ROOT
> %clean
> rm -rf %{buildroot}

Fixed

> * SHOULD: The README.txt file can go outside of the conditional to avoid
> further confusion.
> > %files
> > %if (0%{?rhel} == 06)
> > %doc README.txt LICENSE_1_0.txt
> > %else
> > %doc README.txt
> > %license LICENSE_1_0.txt
> > %endif
> %files
> %if (0%{?rhel} == 06)
> %doc LICENSE_1_0.txt
> %else
> %license LICENSE_1_0.txt
> %endif
> %doc README.txt

Good point, fixed.
 
> * SHOULD: Use the %{name] macro consistently. Also, there should not be an
> extension to any manpage cause rpmbuild can do the compression magically.
> For the documentation folder you can use the shorter %{_pkgdocdir} macro.
> > %{_bindir}/vera++
> …
> > %{_datadir}/man/man1/vera++.1.gz
> > %{_datadir}/%{name}/doc/vera++.html
> %{_bindir}/{name}
> …
> %{_datadir}/man/man1/%{name}.1*
> %{_pkgdocdir}/%{name}.html

Fixed for the man page, but %{_pkgdocdir} doesn't work on EPEL[67]
 
> * SHOULD: Why do you package the cmake and tcl files? Those look like source
> or general development files to me. Shouldn't they be placed into a -devel
> subpackage? Maybe do not include them at all (if in doubt).
> > %{_libdir}/%{name}/*.cmake
> > %{_libdir}/%{name}/*.cmake.in
> …
> > %{_libdir}/%{name}/rules/*.tcl
> > %{_libdir}/%{name}/transformations/*.tcl

These provide the CMake macros needed to integrate automatic vera++ checks into a CMake-based project. See "Running Vera++ as a test with CMake" and "Running Vera++ during the build with CMake" here:

https://bitbucket.org/verateam/vera/wiki/Running

> I could do also an official fedora-review run when my questions are answered.

Files are updated and ready for review. Thanks!

Thanks for the fixes. So let's look deeper into the project details.

(In reply to Taylor Braun-Jones from comment #3)
> (In reply to Raphael Groner from comment #2)
> > * MUST: Remove the Group: line. This tag is deprecated since Fedora 17.
> > https://fedoraproject.org/wiki/
> > How_to_create_an_RPM_package#SPEC_file_overview
> 
> So should I remove this even if I'm targeting EPEL6?

Not sure for what it is needed at all. 

> > * SHOULD: Why do you package the cmake and tcl files? Those look like source
> > or general development files to me. Shouldn't they be placed into a -devel
> > subpackage? Maybe do not include them at all (if in doubt).
> > > %{_libdir}/%{name}/*.cmake
> > > %{_libdir}/%{name}/*.cmake.in
> > …
> > > %{_libdir}/%{name}/rules/*.tcl
> > > %{_libdir}/%{name}/transformations/*.tcl
> 
> These provide the CMake macros needed to integrate automatic vera++ checks
> into a CMake-based project. See "Running Vera++ as a test with CMake" and
> "Running Vera++ during the build with CMake" here:
> 
> https://bitbucket.org/verateam/vera/wiki/Running

* Okay, vera++ can be used as a standalone executable besides a full integration into another project at build time. Please put those *.cmake* files into an own (sub-)package named vera++-devel or cmake-vera++ because they are not needed for the minimal use case. Put the main package as a Requires. For the tcl files, please see my next comment as this seems to be another special case.
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

* Further, you would have to comply with tcl guideline in particular, package especially the *.tcl files into tcl-vera++ as the special guideline tells. Also pay attention to the other requirements there.
https://fedoraproject.org/wiki/Packaging:Tcl

--
Some other new things I see as general review points by now:

* There is some ctest stuff provided in the upstream source. You could use that for a %check section in your spec file.
https://bitbucket.org/verateam/vera/src/30f9235797e5e6c34fda48bdaa05af1c0e558dd8/vera.ctest?at=master
https://fedoraproject.org/wiki/Packaging:Cmake#Specfile_Usage

* For EPEL, you have to use cmake28 as for RHEL instead of just cmake. Please adjust the contitional.

* Please put the generated files from the doc subfolders also in the package (or a %{name}-doc named and noarch subpackage if the content is more than 1MB in size), you could do this easily by help from the %doc macro.
https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation

* Plugins (lua, python, tcl) could also get their own subpackage named as %{name}-plugins. But this is SHOULD only if it saves some significant space in the main package (>1MB).
https://bitbucket.org/verateam/vera/src/30f9235797e5e6c34fda48bdaa05af1c0e558dd8/src/plugins/?at=master
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Subpackages

* There's also a manpage generated that you should include into the package.
https://bitbucket.org/verateam/vera/src/30f9235797e5e6c34fda48bdaa05af1c0e558dd8/doc/CMakeLists.txt?at=master#cl-36
https://fedoraproject.org/wiki/Packaging:Guidelines#Manpages

(In reply to Raphael Groner from comment #4)
> Thanks for the fixes. So let's look deeper into the project details.
> 
> (In reply to Taylor Braun-Jones from comment #3)
> > (In reply to Raphael Groner from comment #2)
> > > * MUST: Remove the Group: line. This tag is deprecated since Fedora 17.
> > > https://fedoraproject.org/wiki/
> > > How_to_create_an_RPM_package#SPEC_file_overview
> > 
> > So should I remove this even if I'm targeting EPEL6?
> 
> Not sure for what it is needed at all. 

Neither am I. Removed.

> > > * SHOULD: Why do you package the cmake and tcl files? Those look like source
> > > or general development files to me. Shouldn't they be placed into a -devel
> > > subpackage? Maybe do not include them at all (if in doubt).
> > > > %{_libdir}/%{name}/*.cmake
> > > > %{_libdir}/%{name}/*.cmake.in
> > > …
> > > > %{_libdir}/%{name}/rules/*.tcl
> > > > %{_libdir}/%{name}/transformations/*.tcl
> > 
> > These provide the CMake macros needed to integrate automatic vera++ checks
> > into a CMake-based project. See "Running Vera++ as a test with CMake" and
> > "Running Vera++ during the build with CMake" here:
> > 
> > https://bitbucket.org/verateam/vera/wiki/Running
> 
> * Okay, vera++ can be used as a standalone executable besides a full
> integration into another project at build time. Please put those *.cmake*
> files into an own (sub-)package named vera++-devel or cmake-vera++ because
> they are not needed for the minimal use case. Put the main package as a
> Requires. For the tcl files, please see my next comment as this seems to be
> another special case.
> https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

Okay, cmake files moved into devel subpackage

> * Further, you would have to comply with tcl guideline in particular,
> package especially the *.tcl files into tcl-vera++ as the special guideline
> tells. Also pay attention to the other requirements there.
> https://fedoraproject.org/wiki/Packaging:Tcl
> 
> --
> Some other new things I see as general review points by now:
> 
> * There is some ctest stuff provided in the upstream source. You could use
> that for a %check section in your spec file.
> https://bitbucket.org/verateam/vera/src/
> 30f9235797e5e6c34fda48bdaa05af1c0e558dd8/vera.ctest?at=master
> https://fedoraproject.org/wiki/Packaging:Cmake#Specfile_Usage

This is what I have in the current .spec file posted for review:

%check
cd build
# Skip test that fails when run inside a mock chroot. See:
# https://bitbucket.org/verateam/vera/issue/73
ctest --output-on-failure --exclude-regex RuleDUMP

Is that what you are referring to?
> * For EPEL, you have to use cmake28 as for RHEL instead of just cmake.
> Please adjust the contitional.

So you want something like this:

%if (0%{?rhel} == 6) || (0%{?epel} == 6)

Is that right? If so, I can certainly do that, but I'm not sure what the point of the extra conditional is. Under what scenario would check for (0%{?rhel} == 6) not be sufficient?

> * Please put the generated files from the doc subfolders also in the package
> (or a %{name}-doc named and noarch subpackage if the content is more than
> 1MB in size), you could do this easily by help from the %doc macro.
> https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation

The only doc file that gets generated is vera++.html which is only 59K.

> * Plugins (lua, python, tcl) could also get their own subpackage named as
> %{name}-plugins. But this is SHOULD only if it saves some significant space
> in the main package (>1MB).
> https://bitbucket.org/verateam/vera/src/
> 30f9235797e5e6c34fda48bdaa05af1c0e558dd8/src/plugins/?at=master
> https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
> https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Subpackages

So even the .tcl files would go in this %{name}-plugins package? I like that approach best because even though the sum of all the .py, tcl, and .lua files is less than 200K currently, I expect that it will continue to grow since python and lua support is a brand new feature. And I think grouping all of these files into a %{name}-plugins seems more sensible and discoverable than putting some into a tcl-vera++ package.

> * There's also a manpage generated that you should include into the package.

Isn't that covered by the following line?

%{_datadir}/man/man1/%{name}.1*

Looking into the details of vera++, the Fedora Tcl guidelines, and the %{name}-plugins subpackage option:

* A tcl-%{name} package does not apply because vera++ includes a build-in Tcl interpretter.

* I'm not sure a %{name}-plugins subpackage makes sense either because the out-of-the-box expected behavior is to be able to run a default set of checks and transformations be simply running `vera++ foo.cpp`

I've updated the spec and srpm links with the latest fixes.

Tried with fedora-review but mock build fails for rawhide. Relevant log snippet:

/usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/vera++-1.3.0/build/CMakeFiles 36
[ 63%] Building CXX object src/CMakeFiles/vera.dir/structures/SourceLines.cpp.o
cd /builddir/build/BUILD/vera++-1.3.0/build/src && /usr/lib64/ccache/c++   -DVERA_LUA -DVERA_PYTHON -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic  -isystem /usr/include/python2.7 -I/builddir/build/BUILD/vera++-1.3.0/build/src    -o CMakeFiles/vera.dir/structures/SourceLines.cpp.o -c /builddir/build/BUILD/vera++-1.3.0/src/structures/SourceLines.cpp
c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

I'll attach the full build.log file.

Created attachment 1011553 [details]
c++: internal compiler error: Killed (program cc1plus)

build.log as mock gives me within a run of fedora-review.

"c++: internal compiler error: Killed (program cc1plus)"

(In reply to Raphael Groner from comment #8)
> Tried with fedora-review but mock build fails for rawhide. 

Thanks. Yes, I need to look into that as soon as f22, epel6, and epel7 are squared away. I'm guessing it's related to:

https://bitbucket.org/verateam/vera/issue/71

Okay, for now this is FTBFS. Each package must be build for rawhide to comply with policy.

Unfortunately, we must wait for upstream or any available patch to fix gcc5. While this is not happening, the review is stalled.

Thanks, I didn't realize that was the policy (nor did the two reviewers of my recently approved ceres-solver package request which also has problems building with gcc-5.0)

I'm not able to reproduce the rawhide error that you're are seeing. Since what you were seeing was an internal compiler error, I wonder if it was a buggy gcc-c++ package that has already been updated in the last 5 hours. I did however hit a couple failing unit tests due to incompatibility with Lua 5.3. I have simply disabled Lua support on Fedora > 22 for now. Upstream bug report:

https://bitbucket.org/verateam/vera/issue/74/vera-segfaults-when-built-with-lua-53#comment-17202574

Successful rawhide scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=9425142

The spec and srpm files at the original URLs have been updated.

(In reply to Taylor Braun-Jones from comment #12)
…
> I'm not able to reproduce the rawhide error that you're are seeing. Since
> what you were seeing was an internal compiler error, I wonder if it was a
> buggy gcc-c++ package that has already been updated in the last 5 hours.

That's odd. I am using fedora-review in a f21 system, with general use case as mock in a chroot for rawhide.

> I did however hit a couple failing unit tests due to incompatibility with Lua
> 5.3. I have simply disabled Lua support on Fedora > 22 for now. Upstream bug
> report:
> 
> https://bitbucket.org/verateam/vera/issue/74/vera-segfaults-when-built-with-
> lua-53#comment-17202574

You could use BR: compat-lua-devel as like for compat-lua / compat-lua-libs packages instead, they have 5.1.5 as version.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- If (and only if) the source package includes the text of the license(s) in
  its own file, then that file, containing the text of the license(s) for the
  package is included in %doc.
  Note: Cannot find LICENSE_1_0.txt in rpm(s)
  See:
  http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text

==> Ignore, we use %license since this is a new guideline but still fedora-review without patch.

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[!]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "BSL (v1.0)", "Unknown or generated". 45 files have unknown license.
     Detailed output of licensecheck in /home/builder/fedora-
     review/1208738-vera++/licensecheck.txt

==> Please fix or clarify for the bundled cpptcl.
    Maybe you should unbundle into a separate package.
    See http://cpptcl.cvs.sourceforge.net/viewvc/cpptcl/src/LICENSE?revision=1.1&view=markup
    The test sources should be okay without any license text.

vera.ctest : Licensed under the Apache License, Version 2.0 (see
	     inside the file for the complete license and copyright)

==> Please add ASL 2.0 to License: and mention it in comment for the tests.
    http://www.apache.org/licenses/LICENSE-2.0.txt

[x]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[?]: Package contains no bundled libraries without FPC exception.

==> See above for bundled cpptcl. Currently, there's no package available for cpptcl.

[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: %clean present but not required

==> OK, required for EPEL.

[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[!]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     vera++-devel

==> Please fix.

[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[!]: Spec use %global instead of %define unless justified.
     Note: %define requiring justification: %define enable_lua_support 1,
     %define enable_lua_support 0

==> Please fix.

[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: vera++-1.3.0-1.fc23.x86_64.rpm
          vera++-devel-1.3.0-1.fc23.x86_64.rpm
          vera++-1.3.0-1.fc23.src.rpm
vera++.x86_64: W: only-non-binary-in-usr-lib

==> Ignore.

vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/F001.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T003.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/F002.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/L002.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T007.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T019.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/L005.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T002.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T009.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/profiles/full 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/trim_right.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T013.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/move_namespace.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T014.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/L006.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/DUMP.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T005.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/L003.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/to_lower.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T008.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T012.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T010.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/move_macros.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/to_xml.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T015.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T018.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T001.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T006.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/profiles/boost 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T017.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/L004.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/to_xml2.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T016.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T004.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/L001.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/rules/T011.tcl 0644L /usr/bin/tclsh
vera++.x86_64: E: non-executable-script /usr/lib64/vera++/transformations/move_includes.tcl 0644L /usr/bin/tclsh

==> Please fix. You can remove the shebang from all those files in the list because they won't be called directly.
http://wiki.rosalab.ru/en/index.php/Rpmlint_Errors#non-executable-script
Adjust this for tclsh: https://fedoraproject.org/wiki/Packaging_tricks#Remove_shebang_from_Python_libraries

vera++-devel.x86_64: W: spelling-error %description -l en_US vera -> Vera, era, aver

==> Ignore. False positive.

vera++-devel.x86_64: W: only-non-binary-in-usr-lib
vera++-devel.x86_64: W: no-documentation

==> Ignore.

vera++.src: W: invalid-url Source0: https://bitbucket.org/verateam/vera/downloads/vera++-1.3.0.tar.gz HTTP Error 403: Forbidden

==> I do not understand. Maybe due to ++ is not resolvable. Tested in browser and works.

3 packages and 0 specfiles checked; 37 errors, 5 warnings.




Rpmlint (installed packages)
----------------------------
Cannot parse rpmlint output:


Requires
--------
vera++ (rpmlib, GLIBC filtered):
    libboost_filesystem.so.1.57.0()(64bit)
    libboost_program_options.so.1.57.0()(64bit)
    libboost_python.so.1.57.0()(64bit)
    libboost_regex.so.1.57.0()(64bit)
    libboost_system.so.1.57.0()(64bit)
    libboost_wave.so.1.57.0()(64bit)
    libc.so.6()(64bit)
    libdl.so.2()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    liblua-5.3.so()(64bit)
    libluabind.so.0.9.0()(64bit)
    libm.so.6()(64bit)
    libpython2.7.so.1.0()(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libtcl8.6.so()(64bit)
    rtld(GNU_HASH)

vera++-devel (rpmlib, GLIBC filtered):
    vera++(x86-64)



Provides
--------
vera++:
    vera++
    vera++(x86-64)

vera++-devel:
    vera++-devel
    vera++-devel(x86-64)



Source checksums
----------------
https://bitbucket.org/verateam/vera/downloads/vera++-1.3.0.tar.gz :
  CHECKSUM(SHA256) this package     : 9415657a09438353489db10ca860dd6459e446cfd9c649a1a2e02268da66f270
  CHECKSUM(SHA256) upstream package : 9415657a09438353489db10ca860dd6459e446cfd9c649a1a2e02268da66f270


Generated by fedora-review 0.5.2 (63c24cb) last change: 2014-07-14
Command line :/usr/bin/fedora-review -v -m fedora-rawhide-x86_64 -o=--yum --clean --init -b 1208738
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG

Created attachment 1011857 [details]
licensecheck.txt

(In reply to Raphael Groner from comment #13)

> > I did however hit a couple failing unit tests due to incompatibility with Lua
> > 5.3. I have simply disabled Lua support on Fedora > 22 for now. Upstream bug
> > report:
> > 
> > https://bitbucket.org/verateam/vera/issue/74/vera-segfaults-when-built-with-
> > lua-53#comment-17202574
> 
> You could use BR: compat-lua-devel as like for compat-lua / compat-lua-libs
> packages instead, they have 5.1.5 as version.

Thanks for the heads up, I hadn't thought to check for a compat- version of lua. Unfortunately, it didn't solve the crash like I had hoped it would, so for now I've left lua support disabled for Fedora > 22

> [!]: License field in the package spec file matches the actual license.
>      Note: Checking patched sources after %prep for licenses. Licenses found:
>      "BSL (v1.0)", "Unknown or generated". 45 files have unknown license.
>      Detailed output of licensecheck in /home/builder/fedora-
>      review/1208738-vera++/licensecheck.txt
> 
> ==> Please fix or clarify for the bundled cpptcl.
>     Maybe you should unbundle into a separate package.
>     See
> http://cpptcl.cvs.sourceforge.net/viewvc/cpptcl/src/LICENSE?revision=1.
> 1&view=markup
>     The test sources should be okay without any license text.

I added the following comment above the License field:

# Bundled cpptcl package has a non-standard open source license - but more
# permissive than Boost so Boost is the "effective" license. See:
#
# https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ

> vera.ctest : Licensed under the Apache License, Version 2.0 (see
> 	     inside the file for the complete license and copyright)
> 
> ==> Please add ASL 2.0 to License: and mention it in comment for the tests.
>     http://www.apache.org/licenses/LICENSE-2.0.txt

Fixed

> [!]: Fully versioned dependency in subpackages if applicable.
>      Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
>      vera++-devel
> 
> ==> Please fix.

This must be a fedora-review bug - I have exactly this line for the devel subpackage.

> [!]: Spec use %global instead of %define unless justified.
>      Note: %define requiring justification: %define enable_lua_support 1,
>      %define enable_lua_support 0
> 
> ==> Please fix.

Fixed.

> ==> Please fix. You can remove the shebang from all those files in the list
> because they won't be called directly.
> http://wiki.rosalab.ru/en/index.php/Rpmlint_Errors#non-executable-script
> Adjust this for tclsh:
> https://fedoraproject.org/wiki/
> Packaging_tricks#Remove_shebang_from_Python_libraries

Fixed.

Still some open issues I would like to see fixed in the final package:

- ASL 2.0 is meant for vera.ctest but not for vera.cmake (there's no such named file!) as you mention it in the comment, though I am not sure if this license includes then also the full source for the tests. Please be careful here and better ask upstream if in doubt. That can be pointless since it is valid only for the tests and they do not go into the compiled RPM.
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#Multiple_licensing_situations

- You can add "BuildArch: noarch" and "Requires: cmake" (or cmake28 respectively) to the devel subpackage because it does not include by itself any arch dependent binaries and is useful only with cmake at hand.


APPROVED

(In reply to Raphael Groner from comment #16)
> Still some open issues I would like to see fixed in the final package:
> 
> - ASL 2.0 is meant for vera.ctest but not for vera.cmake (there's no such
> named file!) as you mention it in the comment, though I am not sure if this
> license includes then also the full source for the tests. Please be careful
> here and better ask upstream if in doubt. That can be pointless since it is
> valid only for the tests and they do not go into the compiled RPM.
> https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/
> FAQ#Multiple_licensing_situations

Sounds good. I've emailed legal.org to get it figured out.

> - You can add "BuildArch: noarch" and "Requires: cmake" (or cmake28
> respectively) to the devel subpackage because it does not include by itself
> any arch dependent binaries and is useful only with cmake at hand.

Makes sense. Fixed.

> APPROVED

Thanks for your help, Raphael. Do you mind if I add you as a co-maintainer? If so, what is your Fedora Account username?

New Package SCM Request
=======================
Package Name: vera++
Short Description: A tool for verification, analysis and transformation of C++ source code
Upstream URL: http://bitbucket.org/verateam/vera
Owners: nocnokneo
Branches: f20 f21 f22 el6 epel7
InitialCC:

Git done (by process-git-requests).

Is there still any interest to maintain this package? If not, I'm going to close this.

No builds found so far at koji neither bodhi.

Closing for now. Please feel free to reopen if there's still any interest for the package.

Yes, leaving closed for now makes sense. My schedule has changed leaving me with less time to work on things like this. I may get back around to this in the future though.

Hi Taylor,

Would it be possible to make an initial build at least? The review was approved, so pushing to SCM and making a build shouldn't take more than 5 minutes. I could help co-maintain the package if you'd like - I'm sure I can help with normal updates and things :)

Cheers!
Ankur

Ankur, please follow our policy for stalled reviews.
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

Setting as dead, as policy recommends.

Ankur, I'd be willing to co-maintain the package with you. But it appears that the Fedora Policy requires that a new ticket be opened at this point (if I understand things correctly?). If you'd like to do that, feel free to list me as a co-maintainer and/or reviewer.

As there's now a vital sign from the original requester and I approved this package in past, I'll re-approve.

Taylor, please go ahead with the package continuation. Thanks.

Friendly ping?

Stalled review, again. Sorry, I gave enough chances.
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews#Submitter_not_responding

Ankur, if you're still interested in this package, please start with the official nonresponsive maintainer process and request to orphan this package.
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers