Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py If you feel that this output has mistakes, please open an issue at https://pagure.io/releng/ Your package (usd) Fails To Install in Fedora 41: can't install usd-libs: - nothing provides liboslquery.so.1.12()(64bit) needed by usd-libs-23.11-8.fc41.x86_64 If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. To reproduce, use the koji/local repo only, e.g. in mock: $ mock -r fedora-41-x86_64 --config-opts mirrored=False install usd-libs P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks!
Preparing to rebuild for an unannounced SONAME bump in https://bodhi.fedoraproject.org/updates/FEDORA-2024-520f9008dd.
A follow-up to https://bugzilla.redhat.com/show_bug.cgi?id=2262330#c6: Luya, I see now that you were already taking care of the rebuild[1]. Unfortunately, the build failed[2]. Working in a side tag and ideally doing some kind of impact check / test build ahead of time would still make this a lot cleaner and safer. [1] https://src.fedoraproject.org/rpms/usd/c/d2b6fdaf414e48f7ad4da1eaee2be65728823e93?branch=rawhide [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2427991 ---- It looks the current and compat versions of tbb are now both linked in. That’s an issue, and we’ll need to make sure the stack is using one or the other. /usr/bin/ld: warning: libtbb.so.12, needed by /usr/lib64/libOpenImageIO.so, may conflict with libtbb.so.2 /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::setStreamMetadataPtr(std::ios_base&, std::shared_ptr<openvdb::v11_0::io::StreamMetadata>&, bool)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::uninitialize()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::MappedFile::createBuffer() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::DelayedLoadMetadata::getMask(unsigned long) const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::beginName() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::GridBase::META_FILE_BBOX_MIN' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::GridBase::META_FILE_BBOX_MAX' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::StreamMetadata::gridMetadata()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::unzipFromStream(std::istream&, char*, unsigned long)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::close()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getDataCompression(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::initialize()' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::endName() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::GridBase::getName[abi:cxx11]() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::GridDescriptor::nameAsString(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getStreamMetadataPtr(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getHalfFloat(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::isOpen() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::bloscFromStream(std::istream&, char*, unsigned long)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::readGrid(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, openvdb::v11_0::math::BBox<openvdb::v11_0::math::Vec3<double> > const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getGridBackgroundValuePtr(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::getFormatVersion(std::ios_base&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::File(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::StreamMetadata::leaf() const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::DelayedLoadMetadata::getCompressedSize(unsigned long) const' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::File::open(bool, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)> const&)' /usr/bin/ld: /usr/lib64/libOpenImageIO.so: undefined reference to `openvdb::v11_0::io::StreamMetadata::delayedLoadMeta() const' collect2: error: ld returned 1 exit status Also, it seems like something is going on with openvdb. Let me know, what, if anything, you want me to try to help with here.
Yes, please. For some reasons, the best on COPR went fine but failed on the main repository.
It looks like the packages that depend on openvdb needed to be rebuilt for the ABI change in https://src.fedoraproject.org/rpms/openvdb/c/0a623bb75651129b8062f834eebea18f89e3caec?branch=rawhide. I’m doing a local test-rebuild to try to confirm this theory. If it’s correct, but presumably luxcorerender, openvkl, and prusa-slicer probably need to be rebuilt too (and of course blender, but the FTBFS must be fixed first). If I get a usable local test-rebuild of usd, I’ll go ahead and open a side tag and take care of these rebuilds. I’m only looking at Rawhide right now. I have no idea what the current situation is in F40.
Sidetag is ready for F40 on 'fedpkg build --target=f40-build-side-86961'.
FEDORA-2024-be3463bb24 (luxcorerender-2.7-0.16.beta1.fc41, OpenImageIO-2.5.7.0-2.fc41, and 3 more) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-be3463bb24
(In reply to Fedora Update System from comment #6) > FEDORA-2024-be3463bb24 (luxcorerender-2.7-0.16.beta1.fc41, > OpenImageIO-2.5.7.0-2.fc41, and 3 more) has been submitted as an update to > Fedora 41. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-be3463bb24 Everything that depended on openvdb rebuilt successfully in F41 except blender, which still failed (in a scratch build) with: /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined reference to 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb::v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock const&)' /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined reference to 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb::v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock const&)' /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined reference to 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb::v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock const&)' collect2: error: ld returned 1 exit status
FEDORA-2024-be3463bb24 (luxcorerender-2.7-0.16.beta1.fc41, OpenImageIO-2.5.7.0-2.fc41, and 3 more) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Luya Tshimbalanga from comment #5) > Sidetag is ready for F40 on 'fedpkg build --target=f40-build-side-86961'. Can you please take care of the builds for this one, since as the creator of the side tag, you’ll have to create the (ABI-breaking!) update anyway? A good build order (given openvdb is done) is: 1. koji wait-repo f40-build-side-86961 --build=openvdb-11.0.0-7.fc40 2. bump releases and build OpenImageIO, openvkl, prusa-slicer 3. koji wait-repo f40-build-side-86961 --build=OpenImageIO-2.5.7.0-2.fc40 4. bump releases and build luxcorerender, usd 5. koji wait-repo f40-build-side-86961 --build=usd-23.11-10.fc40 6. do a scratch-build of blender in the side tag and see what it looks like (Some of the release numbers in the koji wait-repo commands might be a little different, depending on how you handle the release bumps.)
(In reply to Ben Beasley from comment #7) > Everything that depended on openvdb rebuilt successfully in F41 except > blender, which still failed (in a scratch build) with: > > /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined > reference to > 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb:: > v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock > const&)' > /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined > reference to > 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb:: > v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock > const&)' > /usr/include/openvdb/points/AttributeArray.h:1166: error: undefined > reference to > 'openvdb::v11_0abi10::points::AttributeArray::AttributeArray(openvdb:: > v11_0abi10::points::AttributeArray const&, tbb::spin_mutex::scoped_lock > const&)' > collect2: error: ld returned 1 exit status Note that I won’t be attempting to debug this.