Latest upstream release: 3.0.0-preview1 Current version/release in rawhide: 2.11.0-1.fc32 URL: https://github.com/catchorg/Catch2 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/7680/
An HTTP error occurred downloading the package's new Source URLs: Getting https://github.com/philsquared/Catch/archive/v3.0.0/catch-3.0.0.tar.gz to ./catch-3.0.0.tar.gz
This one’s going to be fun once it actually lands: - Might end up being confusingly “Catch2 version 3”? - Switches from single-header to upstream supporting only use as a static library For now, I don’t think we want bugs filed for preview releases, so I’ve adjusted the version filter at https://release-monitoring.org/project/7680/
Latest upstream release: 3.0.1 Current version/release in rawhide: 2.13.8-2.fc37 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/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/7680/
Scratch build failed. Details below: GenericError: File upload failed: cli-build/1652847577.0519826.kKXMmKHX/catch-3.0.1-1.fc34.src.rpm Traceback: File "/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line 198, in build output["build_id"] = self._scratch_build(session, package.name, srpm) File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line 451, in _scratch_build session.uploadWrapper(source, serverdir) File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 3053, in uploadWrapper self.fastUpload(localfile, path, name, callback, blocksize, overwrite, volume=volume) File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 2988, in fastUpload raise GenericError("File upload failed: %s/%s" % (path, name)) If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues
*** Bug 1957535 has been marked as a duplicate of this bug. ***
Releases retrieved: 3.1.0 Upstream release that is considered latest: 3.1.0 Current version/release in rawhide: 2.13.8-2.fc37 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/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/7680/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/catch
Created attachment 1897853 [details] Update to 3.1.0 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.1.0-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=89624810
Created attachment 1918363 [details] Update to 3.1.0 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.1.0-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=93109380
Releases retrieved: 3.1.1 Upstream release that is considered latest: 3.1.1 Current version/release in rawhide: 2.13.8-3.fc37 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/7680/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/catch
Created attachment 1918905 [details] Update to 3.1.1 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.1.1-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=93203374
Releases retrieved: 3.2.0 Upstream release that is considered latest: 3.2.0 Current version/release in rawhide: 2.13.8-3.fc37 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/7680/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/catch
Created attachment 1924854 [details] Update to 3.2.0 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.2.0-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=94255757
Releases retrieved: 3.2.1 Upstream release that is considered latest: 3.2.1 Current version/release in rawhide: 2.13.8-3.fc37 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/7680/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/catch
Created attachment 1931570 [details] Update to 3.2.1 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.2.1-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=95175107
I have a new package that I'm adding that I'd to have the v3 of this package available for. Is there something I can do to help out? I actually started a new package because my search for "Catch2" didn't turn up anything and I didn't notice until the file conflict checker noted my paths belonged to "catch-devel" already ;). I can make some tweaks to the spec and put up a PR along with some tests, and try to run down any compatibility issues with packages that already use this package if you'd like.
Well I need to create a catch2 package first and then look at what needs doing to move this to catch 3 but it's non-trivial as catch 3 has a rather different model. I'll see if I can find some time over the holidays to have a look at it.
(In reply to Tom Hughes from comment #21) > Well I need to create a catch2 package first and then look at what needs > doing to move this to catch 3 but it's non-trivial as catch 3 has a rather > different model. To elaborate on this, “Catch2 v2” is a header-only library, while upstream says this[1] about “Catch2 v3” (what a name!): > v3 is the next major version of Catch2 and brings three significant changes: > > • Catch2 is now split into multiple headers > • Catch2 is now compiled as a static library > • C++14 is the minimum required C++ version > > Note that we still provide one header + one translation unit (TU) distribution but do not consider it the primarily supported option. You should also expect that the compilation times will be worse if you use this option. So the vast majority of dependent packages will now expect to use Catch2 (v3!) as a static library, which we don’t like[2] but might be justifiable here to avoid a massive patching effort, and those that don’t expect a static library will expect to bundle a header *and* a C++ source file, which is probably even worse. (Thanks, Tom, for volunteering to find the “least-worst” way to deal with all of this. Let me know if there’s anything I can help out with.) [1] https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md#migrating-from-v2-to-v3 [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_static_libraries
Whether we build it as static or dynamic is largely irrelevant from a user's point of view - there should be any need for people to patch projects which use it any differently. Or are you referring to patching the catch source so that it can build dynamically? Is that not supported at all at the moment? I'm not really sure why upstream seem so insistent on static builds?
(In reply to Tom Hughes from comment #23) > Whether we build it as static or dynamic is largely irrelevant from a user's > point of view - there should be any need for people to patch projects which > use it any differently. You’re right, patching dependent packages to unbundle or to use a shared library will depend on how deeply they have baked in assumptions about bundled or static libraries, and how overengineered their build systems are. If they just use CMake or pkgconfig in a straightforward way then it should mostly just work. > Or are you referring to patching the catch source so that it can build > dynamically? Is that not supported at all at the moment? I'm not really sure > why upstream seem so insistent on static builds? This is mostly what I was thinking about. From the documentation, I really thought that upstream didn’t support dynamic/shared libraries at all. However, I just took a look at the current Catch2 v3 sources, and found a CMake option CATCH_CONFIG_SHARED_LIBRARY and even provisions for .so versioning, so this might actually be straightforward after all. It looks like the .so versioning support was added in 3.1.1, so maybe it’s good we didn’t rush to package v3 right away.
I had actually already started working on a spec file thinking it wasn't packaged yet (I looked for a "Catch2" package, not a "Catch" package). Here is my starting point https://pagure.io/python-catch2/blob/main/f/Catch2.spec . It isn't fully finalized, as once I did a test run of fedora-review on it, that is when it flagged the file conflict with python3-catch. I started with the dynamic library build, since as you point out the option is there. However, I am a little concerned about pretending like the presence of a shared library implies it behaves like a shared library. In particular, the so-versioning really isn't. It is just the package version: set_target_properties(Catch2 PROPERTIES DEBUG_POSTFIX "d" VERSION ${PROJECT_VERSION} SOVERSION ${PROJECT_VERSION}) https://github.com/catchorg/Catch2/blob/devel/src/CMakeLists.txt#L343 And they specifically state that: > Catch2 provides no ABI stability guarantees whatsoever. Catch2 provides rich C++ interface, and trying to freeze its ABI would take a lot of pointless work. > > Catch2 is not designed to be distributed as dynamic library, and you should really be able to compile everything with the same compiler binary. https://github.com/catchorg/Catch2/blob/devel/docs/faq.md#what-is-catch2s-abi-stability-policy In the spec I had started with putting the versioned so in the -devel subpackage, but as I've thought on it, I think that we probably need to just do it as a static library, since regardless of the ability of production a dynamically linked library, it doesn't sound like it will actually behave like one.
That all might be OK. If the SOVERSION is the same as the version, then e.g. “3.2.1” is the .so version, which correctly reflects the lack of ABI stability, as it is bumped even on patch releases. Meanwhile, the problems of different compiler versions, vendors, and options mostly vanish in a distribution like Fedora, where the compiler and a lot of the options are standardized across all packages.
(In reply to Ben Beasley from comment #26) > That all might be OK. If the SOVERSION is the same as the version, then e.g. > “3.2.1” is the .so version, which correctly reflects the lack of ABI > stability, as it is bumped even on patch releases. Meanwhile, the problems > of different compiler versions, vendors, and options mostly vanish in a > distribution like Fedora, where the compiler and a lot of the options are > standardized across all packages. That's a great point, and in fact it is: > ❯ objdump -p libCatch2.so.3.2.1 | grep SONAME > SONAME libCatch2.so.3.2.1 So then each release ends up being an SO bump. Since this is a unit testing package, I wonder if it ever makes sense for a package to link to it with its runtime? I suppose if there was another unit testing oriented library that expanded on Catch2, and thus linked back to it as an implementation, then there might be installed files actually linked to the Catch2 library. Even in that case, I'd expect the headers would need to be available to be useful. Is there value in providing the shared library in a non-devel package?
This isn’t entirely new ground. It’s pretty much the same situation as gtest (https://src.fedoraproject.org/rpms/gtest/): - is a testing framework - is packaged as a shared library even though upstream wants everybody to compile it with the project being tested so the compiler and flags are the same - offers no ABI stability - uses the entire version number as the .so version
Ah I see, I suppose it shouldn't be a surprise there is a precedent!
Releases retrieved: 3.3.0 Upstream release that is considered latest: 3.3.0 Current version/release in rawhide: 2.13.10-1.fc38 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/7680/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/catch
Created attachment 1939888 [details] Update to 3.3.0 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.3.0-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=96546622
Releases retrieved: 3.3.1 Upstream release that is considered latest: 3.3.1 Current version/release in rawhide: 2.13.10-1.fc38 URL: https://github.com/catchorg/Catch2 Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/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/7680/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/catch
Created attachment 1941040 [details] Update to 3.3.1 (#1786881)
the-new-hotness/release-monitoring.org's scratch build of catch-3.3.1-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=96863259
FEDORA-2023-86aa93897c has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-86aa93897c
FEDORA-2023-86aa93897c has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-86aa93897c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-86aa93897c has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.