Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1208738 - Review Request: vera++ - A tool for verification, analysis and transformation of C++ source code [NEEDINFO]
Summary: Review Request: vera++ - A tool for verification, analysis and transformation...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: NotReady
Depends On:
Blocks: FE-DEADREVIEW
TreeView+ depends on / blocked
 
Reported: 2015-04-03 04:46 UTC by Taylor Braun-Jones
Modified: 2016-03-03 16:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-03 16:44:28 UTC
projects.rg: needinfo? (taylor)
projects.rg: needinfo? (taylor)
gwync: fedora-cvs+


Attachments (Terms of Use)
c++: internal compiler error: Killed (program cc1plus) (deleted)
2015-04-06 21:20 UTC, Raphael Groner
no flags Details
licensecheck.txt (deleted)
2015-04-07 16:39 UTC, Raphael Groner
no flags Details

Description Taylor Braun-Jones 2015-04-03 04:46:56 UTC
Spec URL: http://files.braun-jones.org/vera++.spec
SRPM URL: http://files.braun-jones.org/vera++-1.3.0-1.el7.centos.src.rpm
Description:
Vera++ is a programmable tool for verification, analysis and transformation of
C++ source code. Vera++ is mainly an engine that parses C++ source files and
presents the result of this parsing to scripts in the form of various
collections - the scripts are actually performing the requested tasks.

Fedora Account System Username: nocnokneo

Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=9403681

Comment 1 Raphael Groner 2015-04-04 18:03:48 UTC
Taken. :)

Comment 2 Raphael Groner 2015-04-04 18:28:35 UTC
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.

Comment 3 Taylor Braun-Jones 2015-04-04 21:09:27 UTC
(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!

Comment 4 Raphael Groner 2015-04-05 14:46:33 UTC
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

Comment 6 Taylor Braun-Jones 2015-04-06 02:52:55 UTC
(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*

Comment 7 Taylor Braun-Jones 2015-04-06 13:40:04 UTC
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.

Comment 8 Raphael Groner 2015-04-06 21:16:59 UTC
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.

Comment 9 Raphael Groner 2015-04-06 21:20:00 UTC
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)"

Comment 10 Taylor Braun-Jones 2015-04-06 21:22:44 UTC
(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

Comment 11 Raphael Groner 2015-04-06 21:31:23 UTC
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.

Comment 12 Taylor Braun-Jones 2015-04-07 02:25:07 UTC
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.

Comment 13 Raphael Groner 2015-04-07 16:35:44 UTC
(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

Comment 14 Raphael Groner 2015-04-07 16:39:41 UTC
Created attachment 1011857 [details]
licensecheck.txt

Comment 15 Taylor Braun-Jones 2015-04-11 04:35:54 UTC
(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.

Comment 16 Raphael Groner 2015-04-12 16:36:00 UTC
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

Comment 17 Taylor Braun-Jones 2015-04-13 03:18:50 UTC
(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@lists.fedoraproject.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?

Comment 18 Taylor Braun-Jones 2015-04-14 00:07:32 UTC
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:

Comment 19 Gwyn Ciesla 2015-04-14 12:46:07 UTC
Git done (by process-git-requests).

Comment 20 Raphael Groner 2015-08-19 07:56:35 UTC
Is there still any interest to maintain this package? If not, I'm going to close this.

Comment 21 Raphael Groner 2015-08-19 07:58:54 UTC
No builds found so far at koji neither bodhi.

Comment 22 Raphael Groner 2015-09-13 17:21:52 UTC
Closing for now. Please feel free to reopen if there's still any interest for the package.

Comment 23 Taylor Braun-Jones 2015-09-15 02:02:23 UTC
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.

Comment 24 Ankur Sinha (FranciscoD) 2016-02-02 11:06:49 UTC
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

Comment 25 Raphael Groner 2016-02-04 22:12:05 UTC
Ankur, please follow our policy for stalled reviews.
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

Comment 26 Raphael Groner 2016-02-04 22:13:27 UTC
Setting as dead, as policy recommends.

Comment 27 Taylor Braun-Jones 2016-02-06 21:57:58 UTC
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.

Comment 28 Raphael Groner 2016-02-06 22:50:41 UTC
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.

Comment 29 Raphael Groner 2016-02-13 16:52:55 UTC
Friendly ping?

Comment 30 Raphael Groner 2016-03-03 16:44:28 UTC
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


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