Co-installability with EL7 boost is important, please test it!

I've tried a package build and it failed for me. I found this in the log file:

+ ./b2 -d+2 -q -j8 --without-mpi --without-graph_parallel --build-dir=serial variant=release threading=multi debug-symbols=on pch=off python=2.7 stage
/builddir/build/BUILD/boost_1_59_0/tools/build/src/tools/gcc.jam:149: in gcc.init from module gcc
error: toolset gcc initialization:
error: no command provided, default command 'g++' not found
error: initialized from /builddir/build/BUILD/boost_1_59_0/tools/build/src/user-config.jam:4

Not sure if something is missing in my mock environment, or we need g++ as a build requirement.

Just a note:

It's not required to open review requests for different versions of packages already in the distribution, though of course you can do so if you wish.

https://fedoraproject.org/wiki/Package_Review_Process#Review_Purpose
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Process

But please, follow the guidelines for naming such packages.  There is no version "159" of boost as far as I know; if the version is "1.59" then this package should be named "boost1.59".

https://fedoraproject.org/wiki/Packaging:Naming#Multiple_packages_with_the_same_base_name

@Jason: it's a RDO package review, RDO being based upon CentOS 7 (though we try tofollow Fedora guidelines when possible)
Actually, we're following the //-installable boost package in EPEL convention (Boost 1.48 being shipped as boost148)

@Javier: builds fine in mock and CBS
scratch build: https://cbs.centos.org/koji/taskinfo?taskID=140372

We can build a binary rpm from the source and it can be installed and co-exist with the centos system default.

However, better if you can build mongodb 3.x with this level of boost so that further test can be done.

This also requirement for facter3 / puppet4.

mongodb 3.2.8 build has been tested in local mock, it only requires changing 3 lines in Fedora spec

I have managed to build the package using a plain epel-7-x86_64 buildroot, but it still fails with the mock configuration used by DLRN. The packages are co-installable with boost 1.53.0 from the base repo, no issues found.

I found an issue when trying to run bjam159, got the following error message:

# bjam159
Unable to load Boost.Build: could not find "boost-build.jam"
---------------------------------------------------------------
Attempted search from /tmp/repo up to the root
at /usr/share/boost-build
and in these directories from BOOST_BUILD_PATH and BOOST_ROOT: /usr/share/boost-build.
Please consult the documentation at 'http://www.boost.org'.

File boost-build.jam is placed at /usr/share/boost159-build/, so we may need to patch the default search path for bjam to match it.

We can remove bjam159 from the package and move forward.

Ok, I fixed bjam159, I uploaded fixed package at same location.

<mock-chroot> sh-4.2# /usr/bin/bjam159 
warning: No toolsets are configured.
warning: Configuring default toolset "gcc".
warning: If the default is wrong, your build may not work correctly.
warning: Use the "toolset=xxxxx" option to override our guess.
warning: For more configuration options, please consult
warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
error: no Jamfile in current directory found, and no target references specified.


Now, package should be good. I also created leatherman fedora review for facter3.
https://bugzilla.redhat.com/show_bug.cgi?id=1419271

I will build boost159 as preview in CBS, and update facter/puppet in Fedora/CBS as soon as leatherman gets reviewed.

Created attachment 1248047 [details]
fedora-review output

fedora-review has found a few issues:

- boost159-static obsoletes boost-devel-static < 1.34.1-14, but it doesn't provide it (it provides boost159-devel-static).
- same happens to boost159-mpich2, boost159-mpich-devel, boost159-mpich2-python. I guess we could remove all obsoletes to avoid issues with the main boost packages.
- It has BR: python-devel, while it should be python2-devel
- It doesn't like that libraries define an rpath, I'd need more information on this.
- Some subpackages seem to be missing an ldconfig in %postin and %postun: boost159-openmpi, boost159-openmpi-python, boost159-graph-openmpi, boost159-mpich, boost159-mpich-python, boost159-graph-mpich

As part of the SHOULD items:

- There should be no %clean section in the spec

The following are non-issues:

- licensecheck is finding two GPL-licensed files, but those are covered by the special exception in the Bison license, so there is no issue there.

- Header files in -devel subpackage are in an example, so expected.

- Documentation is already in a -doc subpackage.

1. ack for removing Obsoletes
2. ack for python2-devel BR
3. rpath issue was fixed in Fedora, I backported the patch
http://pkgs.fedoraproject.org/cgit/rpms/boost.git/commit/boost.spec?id=310c56bc25c3c0af00d64699cf1a57700db4a097
4. MPI subpackages are special case, they don't need ldconfig to run through scriptlets, there's a comment about it
# MPI subpackages don't need the ldconfig magic.  They are hidden by
# default, in MPI back-end-specific directory, and only show to the
# user after the relevant environment module has been loaded.
# rpmlint will report that as errors, but it is fine.


New package uploaded
Spec URL: https://hguemar.fedorapeople.org/reviews/boost159.spec
SRPM URL: https://hguemar.fedorapeople.org/reviews/boost159-1.59.0-2.el7.src.rpm

- The ldconfig errors for MPI subpackages are expected and not an issue. 

- licensecheck is finding two GPL-licensed files, but those are covered by the special exception in the Bison license, so there is no issue there.

- Header files in -devel subpackage are in an example, so expected.

- Documentation is already in a -doc subpackage.

The package is APPROVED, review text included as attachment due to the 65535 char limitation in a comment.

Created attachment 1248095 [details]
Final fedora-review output, APPROVED

This is the final fedora-review output.

Package landed so closing.