new Spec URL: https://copr-be.cloud.fedoraproject.org/results/andreamanzi/boost-python34/epel-7-x86_64/00809104-boost-python34/boost-python34.spec

I first asked to include this package in EPEL7 but the request was not accepted by the mantainer (https://bugzilla.redhat.com/show_bug.cgi?id=1622889) and i was suggested to package this lib by myself. 
The spec file derives from the boost package spec file. In this case i build and package only the python3 library.

I have also created a copr project at:

https://copr.fedorainfracloud.org/coprs/andreamanzi/boost-python34/

 - Use %{python3_pkgversion} instead of hardcoded 34

 - Not needed:

rm -rf $RPM_BUILD_ROOT

%clean
rm -rf $RPM_BUILD_ROOT

%defattr(-, root, root, -)

 - License must be installed with %license, not %doc

 - Add %ldconfig_scriptlets for the library

 - This is not used by your package, I think you can remove it too

%ifnarch %{ix86} x86_64
  # Avoid using Boost.Context on non-x86 arches.  s390 is not
  # supported at all and there were _syntax errors_ in PPC code.  This
  # should be enabled on a case-by-case basis as the arches are tested
  # and fixed.
  %bcond_with context
%else
  %bcond_without context
%endif

thanks!
i made the suggested changes to the spec file

new Spec URL: https://copr-be.cloud.fedoraproject.org/results/andreamanzi/boost-python34/epel-7-x86_64/00812979-boost-python3/boost-python34.spec

cheers
Andrea

Hmmm you're gonna encounter problems with your package naming once Python is upgraded (it is planned soon). I suggest you keep the main package name to boost-python3 as a dummy empty package then add a subpackage named boost-python%{python3_pkgversion}. Also rename the devel subpackage to be boost-python%{python3_pkgversion}-devel

 - Add gcc-c++  as BR

 - python-devel → python2-devel

 - Use %global instead of %define


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

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


Issues:
=======
- If your application is a C or C++ application you must list a
  BuildRequires against gcc, gcc-c++ or clang.
  Note: No gcc, gcc-c++ or clang found in BuildRequires
  See: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B
- Spec file name must match the spec package %{name}, in the format
  %{name}.spec.
  Note: boost-python34.spec should be boost-python3.spec
  See:
  http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Spec_file_name


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

C/C++:
[x]: Provides: bundled(gnulib) in place as required.
     Note: Sources not installed
[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 successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
     Note: Using prebuilt packages
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: 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 %license.
[x]: License field in the package spec file matches the actual license.
     Note: Cannot run licensecheck: Command 'licensecheck -r
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked' returned non-zero exit status -15
[x]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
     Note: Especially check following dirs for bundled code:
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/test/railsys/program/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/test/railsys/libx/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/tools/auto_index/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/example/libraries,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/engine/boehm_gc/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/boost/spirit/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/boostbook/test/more/tests/libs,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/tools/quickbook/test/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/test/prebuilt/ext,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/boost/numeric/odeint/external,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/boost/spirit/repository/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/example/variant/libs,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-
     unpacked/Source0/boost_1_53_0/tools/build/v2/example/pch/include,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/boost/numeric/interval/ext,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/libs,
     /home/bob/packaging/review/boost-python34/review-boost-python34
     /upstream-unpacked/Source0/boost_1_53_0/boost/fusion/include
[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]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[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 does not own files or directories owned by other packages.
[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]: Dist tag is present.
[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 does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: File names are valid UTF-8.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 0 bytes in 0 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

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

Generic:
[x]: Reviewer should test that the package builds in mock.
[-]: 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).
[?]: Package functions as described.
[-]: 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.
[-]: %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 version_enc 1_53_0,
     %define toplev_dirname boost_%{version_enc}, %define sonamever
     %{version}
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.

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

Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Bad spec filename: /home/bob/packaging/review/boost-python34
     /review-boost-python34/srpm-unpacked/boost-python34.spec
     See: (this test has no URL)
[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.


Rpmlint
-------
Checking: boost-python3-1.53.0-27.el7.src.rpm
boost-python3.src: W: spelling-error %description -l en_US versa -> avers, verse, verso
boost-python3.src: E: invalid-spec-name
boost-python3.src:294: W: mixed-use-of-spaces-and-tabs (spaces: line 294, tab: line 278)
1 packages and 0 specfiles checked; 1 errors, 2 warnings.

thanks again!
i did as you suggested but i cannot build anymore the package in copr now

this is the new spec

https://gitlab.cern.ch/dmc/boost-python34/raw/master/boost-python3.spec

and this is the error i see 

https://copr-be.cloud.fedoraproject.org/results/andreamanzi/boost-python34/srpm-builds/00813041/builder-live.log

looks like when runnin rpkg to build the srpm the macro %{python3_pkgversion} resolves to 3 instead of 34, possible?

No worry it's usual with Python 3 specific packages.

It will work in Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=30348873 because Koji rebuild the SRPM in a RHEL chroot.

Don't forget to rename your SPEC "boost-python3.spec".

Package approved.

If you have trouble rebuilding your SRPM, just use this where you have your SPEC and sources:

rpmbuild --define "python3_pkgversion 34" --define "_sourcedir $PWD" --define "_srcrpmdir $PWD" --target epel-7-x86_64 -bs boost-python3.spec

thanks a lot for your help!

why isn't it called python3-boost? ;)

Hi Igor,
i used the name of the package already available in F28, should i move to the new naming convention also in EPEL7
thanks
Andrea

(In reply to Igor Gnatenko from comment #9)
> why isn't it called python3-boost? ;)

Please, let's not start this again! Somebody changed the boost-python3 packages in Fedora to be python3-boost and I have to change them back.

It is not a python module, it's a C++ library for working with python. The naming conventions for python modules do not apply to packages which are not python modules.

> Source2: libboost_thread-mt.so

This can be dropped, it's only needed for the boost-thread subpackage in the main RHEL boost package.


Most of the patches can be dropped as they aren't relevant to Boost.Python, but the following are needed:

> Patch9: boost-1.53.0-attribute.patch

> Patch17: boost-1.53.0-static_assert-unused_typedef.patch

> Patch49: boost-1.54.0-python-unused_typedef.patch

> Patch55: boost-1.53.0-buildflags.patch

> Patch61: boost-1.53.0-python-libpython_dep.patch
> Patch62: boost-1.53.0-python-abi_letters.patch
> Patch63: boost-1.53.0-python-test-PyImport_AppendInittab.patch
> Patch64: boost-1.53.0-no-rpath.patch

I think the rest can be dropped.

Should there be a boost-python3-static subpackage, containing the libboost_python3.a archive? In RHEL libboost_python.a is included in the boost-static subpackage.

In RHEL there are subpackages which include Python2 modules for OpenMPI and MPICH:

%files openmpi-python
%defattr(-, root, root, -)
%doc LICENSE_1_0.txt
%{_libdir}/openmpi/lib/libboost_mpi_python*.so.%{sonamever}
%{_libdir}/openmpi/lib/mpi.so


%files mpich-python
%defattr(-, root, root, -)
%doc LICENSE_1_0.txt
%{_libdir}/mpich/lib/libboost_mpi_python*.so.%{sonamever}
%{_libdir}/mpich/lib/mpi.so


This EPEL package doesn't provide Did you decide not to provide Python3 versions of those for EPEL, or was that unintentional? Packaging them for RHEL 7 might be complicated, because the python2 and python3 modules can't both live at the same path:
%{_libdir}/mpich/lib/mpi.so

In Fedora they are installed to different locations, via the sitearch macros:

%files mpich-python2
%license LICENSE_1_0.txt
%{_libdir}/mpich/lib/libboost_mpi_python.so.%{sonamever}
%{python2_sitearch}/mpich/boost/


%files mpich-python3
%license LICENSE_1_0.txt
%{_libdir}/mpich/lib/libboost_mpi_python3.so.%{sonamever}
%{python3_sitearch}/mpich/boost/

For EPEL it might be best to just ignore the MPI modules until somebody needs them (which is what your spec file does now).

(In reply to Jonathan Wakely from comment #13)
> This EPEL package doesn't provide Did you decide not to provide Python3

Oops, I lost a word there. That was meant to say:

This EPEL package doesn't provide them. Did you decide ...

Hi Jonathan
thanks for your comments, i'm going to drop the not needed lib and patches.

Regarding the missing static, OpenMPI and MPICH packages, i have to admit that i decided to package only what i need for my project:-)

Looks like i can easily add the static package, while for MPI ones if it's complicated in EPEL7 i would prefer not to add them.
cheers
Andrea

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/boost-python3

sorry to bother..but i made a stupid mistake..

i first build the package in EPEL7 without making the changes with discussed (adding static packages and remove not needed patches) and i forgot to run it as scratch build..

i tried to remove the package with koji untag-pck but the build is still there and i cannot build again with the same version and release after i made the needed changes ( i need to have the same version and release as the available boost libs)

how do you solve this? is there a way to remove the existing build?
thanks a lot
Andrea

You can't. You need to bump the Release tag with your changes and build it again. There is no undo button for this.

ok, i had to relax the dependencies over boost-devel then ( version  and not version-release ), hope this is not an issue
thanks
Andrea

That seems right to me. You should not have to rebuild boost-python3 for every change to boost (and vice versa).

A change to the RHEL boost-1.53.0 package *might* require a rebuild for boost-python3 but that would be rare.

Or you should depend on the %{version}-%release} of *boost* not the %{release} of your package. The %{release} of your package should be independent of the boost one.

Package is in repositories