Latest upstream release: 1.67.0-beta1 Current version/release in rawhide: 1.66.0-5.fc29 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
Latest upstream release: 1.67.0 Current version/release in rawhide: 1.66.0-5.fc29 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
============================= build openmpi-x86_64-py3 ================== + echo ============================= build openmpi-x86_64-py3 ================== + ./b2 -d+2 -q -j8 --user-config=./python3-config.jam --with-mpi --with-graph_parallel --build-dir=openmpi-x86_64-py3 variant=release threading=multi debug-symbols=on pch=off python=3.6 stage Performing configuration checks - default address-model : 64-bit - default architecture : x86 - symlinks supported : yes warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at /builddir/build/BUILD/boost_1_67_0/python3-config.jam:6 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:57 error: Unable to find file or target named error: '/boost/python//boost_python3' error: referred to from project at error: 'libs/mpi/build' RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.hu6PGo (%build) Bad exit status from /var/tmp/rpm-tmp.hu6PGo (%build)
PR 1605019 has nothing to do with a new version of Boost that isn't even in rawhide yet.
Latest upstream release: 1.68.0 Current version/release in rawhide: 1.66.0-14.fc29 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
Hi, do you already have an idea when boost 1.68.0 could be available in Fedora? Thanks! -Jan
(In reply to Jan Zizka from comment #5) > Hi, > > do you already have an idea when boost 1.68.0 could be available in Fedora? > > Thanks! > > -Jan Just created an entry for Boost 1.69 on Fedora 30: https://fedoraproject.org/wiki/Changes/F30Boost169 If Boost 1.69 is not ready on time, Boost 1.68 will be used as fallback.
(In reply to Denis Arnaud from comment #6) > Just created an entry for Boost 1.69 on Fedora 30: > https://fedoraproject.org/wiki/Changes/F30Boost169 > If Boost 1.69 is not ready on time, Boost 1.68 will be used as fallback. Nice! Thanks ;)
Since Boost 1.67 fails to build in rawhide, it seems optimistic to state that 1.68 will be used as a fallback. The default will be for F30 to keep using Boost 1.66.0 unless somebody figures out the latest reason that Boost.Python breaks the build.
Latest upstream release: 1.70.0.beta1 Current version/release in rawhide: 1.69.0-6.fc30 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
Latest upstream release: 1.70.0 Current version/release in rawhide: 1.69.0-6.fc30 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
Dear maintainers, I would like to draw your attention to the new CMake package that is shipped with Boost 1.70 by default. While this is awesome, a number of compatibility problems have been reported and (partially) addressed: See https://github.com/boostorg/boost_install/issues?q=is%3Aissue and https://gitlab.kitware.com/cmake/cmake/issues?scope=all&state=all&search=Boost+1.70. Some were fixed for the next Boost release and some fixes will also make it into CMake 3.15: https://gitlab.kitware.com/cmake/cmake/blob/master/Help/release/dev/FindBoost-fphsa.rst tldr; I recommend to disable the CMake package generation when packaging Boost 1.70 (configure with `--no-cmake-config`) and reenable once you package future Boost 1.71+. By this time CMake 3.15 is likely to be released and packaged, too. This could render the transition to Boost's new included CMake package much smoother for many CMake based projects that depend on Boost (also affects non-fedora-packaged projects built on Fedora against the system Boost). Thank you for considering this!
Will it include Boost.Beast?
(In reply to Sergey Avseyev from comment #12) > Will it include Boost.Beast? I'm not sure what you're asking, Boost.Beast has been included since Fedora 28.
Sorry then. I thought it would come a sub-package I couldn't find it in https://src.fedoraproject.org/rpms/boost/blob/master/f/boost.spec Also CMake construct fails to find it in the system (while it can find other components) include(FindBoost) find_package(Boost REQUIRED COMPONENTS system beast) But with "dnf whatprovides */beast.hpp" I can see that /usr/include/boost/beast.hpp is actually installed with boost-devel
Sub-packages are used for shared libraries that programs might depend on at runtime. For header-only libraries there's no shared library, so just install boost-devel to get all the headers.
Latest upstream release: 1.71.0.beta1 Current version/release in rawhide: 1.69.0-9.fc31 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
The following Sources of the specfile are not valid URLs so we cannot automatically build the new version for you. Please use URLs in your Source declarations if possible. - libboost_thread.so
Latest upstream release: 1.71.0 Current version/release in rawhide: 1.69.0-9.fc31 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
Latest upstream release: 1.72.0.beta1 Current version/release in rawhide: 1.69.0-13.fc32 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
Latest upstream release: 1.72.0 Current version/release in rawhide: 1.69.0-5.fc32 URL: http://www.boost.org/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6845/
For reference: - Current version (1.72.0): https://www.boost.org/users/history/version_1_72_0.html - Change request on Fedora: https://fedoraproject.org/wiki/Changes/F32Boost172
Are you plan update boost to 1.72?
(In reply to Vasiliy Glazov from comment #25) > Are you plan update boost to 1.72? Hi Vasiliy, the change request (https://fedoraproject.org/wiki/Changes/F32Boost172) was eventually not completed/approved, as we had issues with the build. So, we will have to wait for the next Fedora release (and most probably go for Boost 1.73).
F32 has already branched from rawhide, so we could update rawhide now. I hope to do that soon, but the GCC 10 release schedule and a pandemic are higher priority right now. If the Boost 1.73 release happens first, we'll use that.
Whats inpact of pandemic for boost update in rawhide?
I'm the boost package maintainer. My schedule is already busy, and heavily disrupted now. I'm not going to go into details of why, that's none of your business.
If you busy it is your deal. I just asked of pandemic.
> I'm not going to go into details of why, that's none of your business. Why are you so toxic? If you have no time to maintain Boost, feel free to retire it or give this package to another maintainer. We cannot update lots of packaged due to ancient version of Boost in repositories even in Rawhide.
(In reply to Vitaly Zaitsev from comment #31) > > I'm not going to go into details of why, that's none of your business. > > Why are you so toxic? If you have no time to maintain Boost, feel free to > retire it or give this package to another maintainer. Oddly enough there isn't a huge queue of people lining up to take it on and deal with entitled users. > We cannot update lots of packaged due to ancient version of Boost in > repositories even in Rawhide. 1) so say that, and provide evidence (which packages? what is the minimum boost requirement? where has the problem been reported?) instead of being argumentative and rude. 2) 1.69 is not "ancient", don't be ridiculous. I added a comment here to give more information about the lack of update. I regret doing so now. I won't bother in future.
I need it for pulseeffects 4.7.2.
> so say that, and provide evidence (which packages? what is the minimum boost requirement? where has the problem been reported?) instead of being argumentative and rude. nheko, mtxclient require at least 1.70. > 2) 1.69 is not "ancient", don't be ridiculous. Yes, it is. Release date: December 12th, 2018.
I've remembered why I abandoned the boost update in December. Boost 1.70.0 and 1.71.0 fail to build with: ...updating 24 targets... common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_graph_parallel.so.1.71.0 common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_wserialization.so.1.71.0 common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_mpi.so.1.71.0 common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_serialization.so.1.71.0 ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_graph_parallel.so common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_graph_parallel.a ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_wserialization.so ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_serialization.so ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_mpi.so ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_serialization.so.1 ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_serialization.so.1.71 ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_mpi.so.1.71 ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_mpi.so.1 common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_wserialization.a ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_wserialization.so.1 common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_serialization.a ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_wserialization.so.1.71 ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_graph_parallel.so.1 ln-UNIX /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_graph_parallel.so.1.71 common.copy /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/libboost_mpi.a ...updated 24 targets... + mkdir -p /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/python3.8/site-packages/openmpi/boost + touch /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/python3.8/site-packages/openmpi/boost/__init__.py + mv /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/mpi.so /builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/python3.8/site-packages/openmpi/boost/ mv: cannot stat '/builddir/build/BUILDROOT/boost-1.71.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/mpi.so': No such file or directory And 1.72.0 fails with: + echo ============================= build openmpi-x86_64 ================== + ./b2 -d+2 -q -j8 --with-mpi --with-graph_parallel --build-dir=openmpi-x86_64 variant=release threading=multi debug-symbols=on pch=off python=3.8 stage Performing configuration checks - default address-model : 64-bit - default architecture : x86 warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at /builddir/build/BUILD/boost_1_72_0/tools/build/src/user-config.jam:6 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:120 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:145 error: Name clash for '<p/builddir/build/BUILD/boost_1_72_0/stage/lib>libboost_serialization.so.1.72.0' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - none error: - <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Anybody should feel free to fix those problems, instead of just moaning about the work other people have done on it.
Thanks Jonathan! A few more pointers: * Boost 1.72 project on Copr: https://copr.fedorainfracloud.org/coprs/denisarnaud/boost1.72/ * Preparation for Boost 1.72 integration within Fedora (as it is not so easy to work on development branches on the official Git repository): https://github.com/fedorapackaging/fedorareviews/tree/trunk/reviews/boost/boost_xxx_boost172
Dear maintainers, during any packaging efforts of Boost 1.72, please be aware of the following bug released in Boost.Process: https://github.com/boostorg/process/issues/116. Other distros appear to have patched it on packaging level: https://github.com/OpenMandrivaAssociation/boost/commit/167e6d8982319d16d846f8d337b93723b807de9a https://github.com/microsoft/vcpkg/pull/10453 Thank you for your consideration!
(In reply to Jonathan Wakely from comment #35) > I've remembered why I abandoned the boost update in December. > > Boost 1.70.0 and 1.71.0 fail to build with: ... > Anybody should feel free to fix those problems, instead of just moaning > about the work other people have done on it. Thanks for your work.
Thanks to Jonathan (!), another relevant discussion about Boost.Python: https://groups.google.com/d/topic/boost-developers-archive/XaYrvMrWcmk/discussion
Vitaly, since this is never going to be fixed you should probably use https://bugzilla.redhat.com/show_bug.cgi?id=1823227 as the blocker for mtxclient and nheko.
(In reply to Dennis Klein from comment #11) > tldr; I recommend to disable the CMake package generation when packaging > Boost 1.70 (configure with > `--no-cmake-config`) and reenable once you package future Boost 1.71+. By > this time CMake 3.15 is likely > to be released and packaged, too. This could render the transition to > Boost's new included CMake package > much smoother for many CMake based projects that depend on Boost (also > affects non-fedora-packaged projects > built on Fedora against the system Boost). Dennis, rawhide now has boost-1.73.0-3.fc33 (and cmake-3.17.3-2.fc33). I didn't use --no-cmake-config because your comment above suggests the versions we have should be OK, but if there are problems please create new bugs here. Thanks. (In reply to Dennis Klein from comment #37) > during any packaging efforts of Boost 1.72, please be aware of the following > bug released in Boost.Process: > https://github.com/boostorg/process/issues/116. This one is fixed in 1.73.0
(In reply to Jonathan Wakely from comment #41) > (In reply to Dennis Klein from comment #11) > > tldr; I recommend to disable the CMake package generation when packaging > > Boost 1.70 (configure with > > `--no-cmake-config`) and reenable once you package future Boost 1.71+. By > > this time CMake 3.15 is likely > > to be released and packaged, too. This could render the transition to > > Boost's new included CMake package > > much smoother for many CMake based projects that depend on Boost (also > > affects non-fedora-packaged projects > > built on Fedora against the system Boost). > > Dennis, rawhide now has boost-1.73.0-3.fc33 (and cmake-3.17.3-2.fc33). I > didn't use --no-cmake-config because your comment above suggests the > versions we have should be OK, but if there are problems please create new > bugs here. Thanks. > > > (In reply to Dennis Klein from comment #37) > > during any packaging efforts of Boost 1.72, please be aware of the following > > bug released in Boost.Process: > > https://github.com/boostorg/process/issues/116. > > This one is fixed in 1.73.0 Awesome, that sounds great, thank you!