I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
(Since there is overlap between the packages that depend on boost and tbb I'm doing them all at once) https://fedoraproject.org/wiki/Changes/F40Boost183 https://fedoraproject.org/wiki/Changes/F39TBB2020.3
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
(Since there is overlap between the packages that depend on boost and tbb I'm doing them all at once) https://fedoraproject.org/wiki/Changes/F40Boost183 https://fedoraproject.org/wiki/Changes/F39TBB2020.3
Most of the packages have now been rebuilt and will be merged to rawhide soon (I hope!). See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
The following packages failed to build, for the reasons shown. Some other packages that depend on these ones couldn't be built due to these failures. There are some others that weren't rebuild, like OpenImageIO and python-graph-tool, but the maintainers are aware.
root unit tests 213 - gtest-math-matrix-test-testMatrixTSparse (Failed)
0ad ../../contrib/libzip/mkstemp.c:76:15: error: implicit declaration of function ‘getpid’ [-Wimplicit-function-declaration]
botan unit tests fail?
codeblocks needs non-existent squirrel-devel.i686
easystroke cellrenderertextish.c:422:56: error: assignment to ... [-Wincompatible-pointer-types]
espresso unit tests fail?
galera Errors while running CTest
glob2 scons-3: command not found
gnucash gnucash-5.5/redhat-linux-build/bindings/python/gnucash_core.c: error: -Wno-implicit-int detected - is this intentional ? [-Werror]
heaptrack Could NOT find Libunwind (missing: LIBUNWIND_HAS_UNW_BACKTRACE)
libpst configure: error: cannot import Python module "distutils".
libzypp libzypp-17.31.8/zypp-curl/proxyinfo/proxyinfolibproxy.h:18:10: fatal error: proxy.h: No such file or directory
nextpnr gui/quadtree.h:228:20: error: assignment of read-only member
osmium-tool rapidjson/document.h:319:82: error: assignment of read-only member ‘rapidjson::GenericStringRef<CharType>::length’
prusa-slicer PrusaSlicer-version_2.4.2/src/slic3r/GUI/Plater.cpp:5128:21: error: call of overloaded ‘load_files(<brace-enclosed initializer list>)’ is ambiguous
slic3r The package does -std=c++NN -U__STRICT_ANSI__ which is dumb and doesn't work. Just use -std=gnu++NN instead, which actually works. bits/c++config.h:2509:2: warning: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" [-Wcpp]
systemtap new GCC warnings promoted to errors with -Werror
vtk linker error: "defined in discarded section"
On Thu, 18 Jan 2024 at 22:15, Jonathan Wakely jwakely@redhat.com wrote:
heaptrack Could NOT find Libunwind (missing: LIBUNWIND_HAS_UNW_BACKTRACE)
This one's already fixed in dist-git! (thanks, aleasto)
On Thu, 18 Jan 2024 22:15:18 +0000 Jonathan Wakely jwakely@redhat.com wrote:
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
(Since there is overlap between the packages that depend on boost and tbb I'm doing them all at once) https://fedoraproject.org/wiki/Changes/F40Boost183 https://fedoraproject.org/wiki/Changes/F39TBB2020.3
Most of the packages have now been rebuilt and will be merged to rawhide soon (I hope!). See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
The following packages failed to build, for the reasons shown. Some other packages that depend on these ones couldn't be built due to these failures. There are some others that weren't rebuild, like OpenImageIO and python-graph-tool, but the maintainers are aware.
codeblocks needs non-existent squirrel-devel.i686
ah, we should have removed the dep after switching to the bundled patched squirrel, fix in progress
Dan
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
Please DO NOT build your package in rawhide if we're rebuilding it in the boost side tag. It will require another rebuild in the side tag and another bodhi update and delay the mass rebuild by several more hours while the gating tests run.
On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely jwakely@redhat.com wrote:
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
Please DO NOT build your package in rawhide if we're rebuilding it in the boost side tag. It will require another rebuild in the side tag and another bodhi update and delay the mass rebuild by several more hours while the gating tests run.
OK, the side tag has been merged. Builds can be done in rawhide again now.
On Fri, 2024-01-19 at 00:21 +0000, Jonathan Wakely wrote:
On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely jwakely@redhat.com wrote:
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
Please DO NOT build your package in rawhide if we're rebuilding it in the boost side tag. It will require another rebuild in the side tag and another bodhi update and delay the mass rebuild by several more hours while the gating tests run.
OK, the side tag has been merged. Builds can be done in rawhide again now.
not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2 needs pass in all "Test Gating" or is running again "Test Gating" for new build(s)
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, 19 Jan 2024 at 01:27, Sérgio Basto sergio@serjux.com wrote:
On Fri, 2024-01-19 at 00:21 +0000, Jonathan Wakely wrote:
On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely jwakely@redhat.com wrote:
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
Please DO NOT build your package in rawhide if we're rebuilding it in the boost side tag. It will require another rebuild in the side tag and another bodhi update and delay the mass rebuild by several more hours while the gating tests run.
OK, the side tag has been merged. Builds can be done in rawhide again now.
not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2 needs pass in all "Test Gating" or is running again "Test Gating" for new build(s)
(The new build that I think you caused btw!)
I'm not sure what's going on with the waiting status, but it's in stable, and the new packages are in the buildroot and being used by the mass rebuild.
It looks like openvdb-devel manages to accidentally depend on the tbb compat package on i686 only, which breaks OpenImageIO because OpenImageIO depends on the updated tbb, and that conflicts with the compat package:
Problem: package tbb2020.3-devel-2020.3-3.fc40.i686 conflicts with tbb-devel provided by tbb-devel-2021.11.0-2.fc40.i686 - package openvdb-devel-11.0.0-2.fc40.i686 requires pkgconfig(tbb) >= 3.0, but none of the providers can be installed - conflicting requests
This is because openvdb-devel Requires pkgconfig(tbb), but on i686 the current tbb-devel provides only pkgconfig(tbb32), not pkgconfig(tbb).
The best and simplest fix is probably to adjust openvdb-devel so it Requires cmake(TBB) instead, which works on all architectures and is more technically accurate anyway. However, I haven’t attempted to actually implement this fix.
This issue breaks the dependency chain openvdb → OpenImageIO → openshadinglanguage → usd → blender, which is the reason (or at least the initial/primary reason?) Blender failed in the mass rebuild[1].
I’m posting about this in part just to explain the problem in case anyone else is encountering something similar.
– Ben Beasley (FAS music)
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111976337
On 1/19/24 07:45, Jonathan Wakely wrote:
On Fri, 19 Jan 2024 at 01:27, Sérgio Bastosergio@serjux.com wrote:
On Fri, 2024-01-19 at 00:21 +0000, Jonathan Wakely wrote:
On Fri, 19 Jan 2024 at 00:10, Jonathan Wakelyjwakely@redhat.com wrote:
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakelyjwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
Please DO NOT build your package in rawhide if we're rebuilding it in the boost side tag. It will require another rebuild in the side tag and another bodhi update and delay the mass rebuild by several more hours while the gating tests run.
OK, the side tag has been merged. Builds can be done in rawhide again now.
not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2 needs pass in all "Test Gating" or is running again "Test Gating" for new build(s)
(The new build that I think you caused btw!)
I'm not sure what's going on with the waiting status, but it's in stable, and the new packages are in the buildroot and being used by the mass rebuild. -- _______________________________________________ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On Sat, 20 Jan 2024 at 15:10, Ben Beasley code@musicinmybrain.net wrote:
It looks like openvdb-devel manages to accidentally depend on the tbb compat package on i686 only, which breaks OpenImageIO because OpenImageIO depends on the updated tbb, and that conflicts with the compat package:
Problem: package tbb2020.3-devel-2020.3-3.fc40.i686 conflicts with tbb-devel provided by tbb-devel-2021.11.0-2.fc40.i686
- package openvdb-devel-11.0.0-2.fc40.i686 requires pkgconfig(tbb) >= 3.0, but none of the providers can be installed
- conflicting requests
This is because openvdb-devel Requires pkgconfig(tbb), but on i686 the current tbb-devel provides only pkgconfig(tbb32), not pkgconfig(tbb).
Aha, thanks for figuring that out! The problem was also observed at https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c43 but I didn't get the right explanation.
I'm not sure why the i686 package does that, maybe Jerry knows (I used his TBB COPR for the new tbb.spec).
The best and simplest fix is probably to adjust openvdb-devel so it Requires cmake(TBB) instead, which works on all architectures and is more technically accurate anyway. However, I haven’t attempted to actually implement this fix.
This issue breaks the dependency chain openvdb → OpenImageIO → openshadinglanguage → usd → blender, which is the reason (or at least the initial/primary reason?) Blender failed in the mass rebuild[1].
CC Richard Shaw who was puzzled by the same thing.
I’m posting about this in part just to explain the problem in case anyone else is encountering something similar.
– Ben Beasley (FAS music)
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111976337
On 1/19/24 07:45, Jonathan Wakely wrote:
On Fri, 19 Jan 2024 at 01:27, Sérgio Basto sergio@serjux.com wrote:
On Fri, 2024-01-19 at 00:21 +0000, Jonathan Wakely wrote:
On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely jwakely@redhat.com wrote:
On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely jwakely@redhat.com wrote:
I'll be building boost, tbb, and the packages that depend on them in the f40-build-side-81691 side tag over the next few hours (in advance of the mass rebuild tomorrow).
If your package gets a "Rebuilt for Boost 1.83.0" comment, please don't rebuild it in rawhide, we're building it in the side tag and will merge it back to rawhide. If you need to update your package before the mass rebuild, please let me and Patrick (CC'd) know and your changes can be built in the side tag too.
Please DO NOT build your package in rawhide if we're rebuilding it in the boost side tag. It will require another rebuild in the side tag and another bodhi update and delay the mass rebuild by several more hours while the gating tests run.
OK, the side tag has been merged. Builds can be done in rawhide again now.
not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2 needs pass in all "Test Gating" or is running again "Test Gating" for new build(s)
(The new build that I think you caused btw!)
I'm not sure what's going on with the waiting status, but it's in stable, and the new packages are in the buildroot and being used by the mass rebuild. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sat, Jan 20, 2024 at 8:32 AM Jonathan Wakely jwakely@redhat.com wrote:
Aha, thanks for figuring that out! The problem was also observed at https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c43 but I didn't get the right explanation.
I'm not sure why the i686 package does that, maybe Jerry knows (I used his TBB COPR for the new tbb.spec).
Upstream has this in src/tbb/CMakeLists.txt:
if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(TBB_PC_NAME tbb) else() set(TBB_PC_NAME tbb32) endif()
That makes the pkgconfig file install as tbb32.pc. I don't know why upstream is doing that. Maybe so 64-bit and 32-bit installs can coexist on the same system?
On 20/01/2024 16:07, Jerry James wrote:
Upstream has this in src/tbb/CMakeLists.txt:
if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(TBB_PC_NAME tbb) else() set(TBB_PC_NAME tbb32) endif()
That makes the pkgconfig file install as tbb32.pc. I don't know why upstream is doing that. Maybe so 64-bit and 32-bit installs can coexist on the same system?
The correct way to do that is to install in /usr/lib{,64}/pkgconfig instead of /usr/share/pkgconfig I think?
Tom
On Saturday, 20 January 2024 at 17:59, Tom Hughes via devel wrote:
On 20/01/2024 16:07, Jerry James wrote:
Upstream has this in src/tbb/CMakeLists.txt:
if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(TBB_PC_NAME tbb) else() set(TBB_PC_NAME tbb32) endif()
That makes the pkgconfig file install as tbb32.pc. I don't know why upstream is doing that. Maybe so 64-bit and 32-bit installs can coexist on the same system?
The correct way to do that is to install in /usr/lib{,64}/pkgconfig instead of /usr/share/pkgconfig I think?
Correct!
Regards, Dominik
On Sun, 21 Jan 2024 at 12:10, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 20 January 2024 at 17:59, Tom Hughes via devel wrote:
On 20/01/2024 16:07, Jerry James wrote:
Upstream has this in src/tbb/CMakeLists.txt:
if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(TBB_PC_NAME tbb) else() set(TBB_PC_NAME tbb32) endif()
That makes the pkgconfig file install as tbb32.pc. I don't know why upstream is doing that. Maybe so 64-bit and 32-bit installs can coexist on the same system?
The correct way to do that is to install in /usr/lib{,64}/pkgconfig instead of /usr/share/pkgconfig I think?
Thanks. It's already in /usr/lib/pkgconfig anyway, so it looks like the tbb32.pc name is just unnecessary.
I'll try a mock build with it renamed.
On Mon, 22 Jan 2024 at 13:24, Jonathan Wakely jwakely@redhat.com wrote:
On Sun, 21 Jan 2024 at 12:10, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 20 January 2024 at 17:59, Tom Hughes via devel wrote:
On 20/01/2024 16:07, Jerry James wrote:
Upstream has this in src/tbb/CMakeLists.txt:
if (CMAKE_SIZEOF_VOID_P EQUAL 8) set(TBB_PC_NAME tbb) else() set(TBB_PC_NAME tbb32) endif()
That makes the pkgconfig file install as tbb32.pc. I don't know why upstream is doing that. Maybe so 64-bit and 32-bit installs can coexist on the same system?
The correct way to do that is to install in /usr/lib{,64}/pkgconfig instead of /usr/share/pkgconfig I think?
Thanks. It's already in /usr/lib/pkgconfig anyway, so it looks like the tbb32.pc name is just unnecessary.
I'll try a mock build with it renamed.
I've pushed a fix for this to rawhide, thanks for the help. The mass rebuild hasn't got to tbb yet, so I've started a new build. When that finishes it should be possible to un-break openvdb.
-
Ben Beasley -
Dan Horák -
Dominik 'Rathann' Mierzejewski -
Jerry James -
Jonathan Wakely -
Sérgio Basto -
Tom Hughes