I an effort to update another package, I have updated dev-libs/protobuf to 23.3. Even though dev-libs/protobuf doesn't have an ebuild > 21, it is a documented issue. https://bugs.gentoo.org/906811 has an ebuild for dev-libs/protobuf-22.3 and I am in the process of modifying it a bit to work with 23.3. https://github.com/protocolbuffers/protobuf/issues/12746#issuecomment-1553244976 CMake's `FindProtobuf` is broken for 22.x and up, and `find_package(protobuf CONFIG)` needs to be used. https://github.com/protocolbuffers/protobuf/issues/12746#issuecomment-1555328698 `FIND_PACKAGE(Protobuf)` falls back to the `FindPackage` implementation shipped with cmake, which is broken. What you want is `FIND_PACKAGE(Protobuf CONFIG)` Adding sed -e '/find_package/ s/(Protobuf)/(Protobuf CONFIG)/' -i CMakeLists.txt to src_prepare() fixes the problem.
...and only >=protobuf-22 provides this new cmake config? If you do that, this effectively raises Marble's minimum protobuf dependency, otherwise the following happens: > -- The following OPTIONAL packages have not been found: > > * Protobuf > Parsing of OSM PBF files. Did someone file a cmake bug about their broken FindProtobuf module?
*** Bug 909087 has been marked as a duplicate of this bug. ***
From https://github.com/protocolbuffers/protobuf/issues/11545#issuecomment-1382652052: > Note, you can also use cmake to install protobuf in 21.x, in which case the > cmake files should get set up properly. Would that give us a viable upgrade path?
The main problem comes down to downstream packages using `find_package(protobuf)` and not `find_package(protobuf config)`. When cmake falls back to the `FindPackage` implementation that is shipped with cmake, things break. The `protobuf config` change needs to be done on downstream packages if they are going to use protobuf >= 22.x. Some already do, but those that don't break when they try to compile. marble and opencv are the two than I ran into that broke, though three other packages recompiled just fine because they have already use `find_package(protobuf config)`.
But how can they use it if the version of protobuf providing cmake config isn't even in ::gentoo yet?
dev-java/protobuf-java-3.23.3 is fine but needs newer version (20230125.3) of dev-cpp/abseil-cpp: https://github.com/gentoo/gentoo/compare/master...vaukai:gentoo:protobuf-java-3.23.3
Though I will admit that I have started this wrong and am learning while I am going (using pkgdev, etc), I do have an ebuild for dev-cpp/abseil-cpp-20230125.3 at https://github.com/gentoo/gentoo/pull/31609. In my commit message for that package specifically, I noted that I recognized the historical reasons for having the gtest source for testing, but I was able to test successfully multilib on amd64 without it.
(In reply to Andreas Sturmlechner from comment #5) > But how can they use it if the version of protobuf providing cmake config > isn't even in ::gentoo yet? Sorry, I missed your comment earlier but I see you found my ebuild in the PRs. First, thank you for the comments on the ebuild itself; I will be making those changes. Second, I believe that `find_package(protobuf config)` works with versions <22.x, but `find_package(protobuf)` does not work with version >=22.x.
(In reply to Mark Conway from comment #8) > Second, I believe that `find_package(protobuf config)` works with versions <22.x The result of an attempt at that was already shown in comment #1 :)
(In reply to Andreas Sturmlechner from comment #9) > (In reply to Mark Conway from comment #8) > > Second, I believe that `find_package(protobuf config)` works with versions <22.x > The result of an attempt at that was already shown in comment #1 :) https://github.com/protocolbuffers/protobuf/tree/3.0.x/cmake `find_package(protobuf config)` seems to have been available since 3.0.x, 7 years ago, and until 22.x `find_package(protobuf)` has "just worked". Am I missing something?
See also comment #3 or simply check `equery f protobuf` with dev-libs/protobuf-21.9 installed - the autotools build system does not install any cmake files.
Ah yes, so that is what I was missing. So a viable upgrade path, which you were also asking for in comment 3, would be to either use cmake for all versions of protobuf so the cmake files are installed, or change the autotools build to also install the cmake files. I would suggest the former since, from 22.x onward, it is the only option for installing. Would that work for you?
All versions <21.9 were cleaned up recently. Yes, a cmake-based 21.12 version bump should work, then revdeps could migrate to cmake config based search for protobuf (and raise their dep to >=21.12).
I'm drafting something based on Mark's work, I might regret it..
Same for kosmindoormap: https://invent.kde.org/libraries/kosmindoormap/-/commit/eac8c57528b5ef8e694df4072ed7a60be799c270
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6d231d90376246566071cd3bd91ada45d8f57abc commit 6d231d90376246566071cd3bd91ada45d8f57abc Author: Sam James <sam@gentoo.org> AuthorDate: 2023-07-13 11:49:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-08-21 17:29:13 +0000 dev-libs/protobuf: add 21.12 Bug: https://bugs.gentoo.org/909081 Closes: https://bugs.gentoo.org/906811 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/protobuf/Manifest | 1 + dev-libs/protobuf/protobuf-21.12.ebuild | 105 ++++++++++++++++++++++++++++++++ dev-libs/protobuf/protobuf-23.3.ebuild | 2 +- 3 files changed, 107 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e1b78fe7fbe91f171bf2ff36af6b345913ca80e0 commit e1b78fe7fbe91f171bf2ff36af6b345913ca80e0 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-08-21 19:27:41 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-08-21 19:35:53 +0000 dev-libs/kosmindoormap: Fix build against >=dev-libs/protobuf-23.3 Bug: https://bugs.gentoo.org/909081 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../kosmindoormap-23.04.3-protobuf-23-1.patch | 31 +++++++++++++++++++ .../kosmindoormap-23.04.3-protobuf-23-2.patch | 35 ++++++++++++++++++++++ .../kosmindoormap/kosmindoormap-23.04.3.ebuild | 2 ++ 3 files changed, 68 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=384f80153eacb97f62b8374dad7b201adc1dbcad commit 384f80153eacb97f62b8374dad7b201adc1dbcad Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-08-21 19:22:15 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-08-21 19:35:53 +0000 kde-apps/marble: Fix build against >=dev-libs/protobuf-23.3 Bug: https://bugs.gentoo.org/909081 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../marble-23.04.3-cxx17-for-protobuf-23.patch | 29 ++++++++++++++++++++++ kde-apps/marble/marble-23.04.3.ebuild | 2 ++ 2 files changed, 31 insertions(+)
*** Bug 921971 has been marked as a duplicate of this bug. ***
What is the status here? Why is it still blocking bug #912819?
(In reply to Volkmar W. Pogatzki from comment #19) > Why is it still blocking bug #912819? Why wouldn't it? If it's fixed, it's fixed, but the blocker wouldn't be removed.
(In reply to Larry the Git Cow from comment #17) > The bug has been referenced in the following commit(s): > [...] > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=384f80153eacb97f62b8374dad7b201adc1dbcad > > commit 384f80153eacb97f62b8374dad7b201adc1dbcad > Author: Andreas Sturmlechner <asturm@gentoo.org> > AuthorDate: 2023-08-21 19:22:15 +0000 > Commit: Andreas Sturmlechner <asturm@gentoo.org> > CommitDate: 2023-08-21 19:35:53 +0000 > > kde-apps/marble: Fix build against >=dev-libs/protobuf-23.3 > > Bug: https://bugs.gentoo.org/909081 > Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> > > .../marble-23.04.3-cxx17-for-protobuf-23.patch | 29 > ++++++++++++++++++++++ > kde-apps/marble/marble-23.04.3.ebuild | 2 ++ > 2 files changed, 31 insertions(+) So this commit seems to have fixed 'marble-23.04.3' which is already gone. Presently stable is 'marble-23.08.5'. Unless 'marble-23.08.5' is still affected please close this bug. Bugs for other packages please be added to the tracker.
Why would fixing marble somehow fix dev-build/cmake? If we agree that every cmake revdep in ::gentoo has successfully worked around the issue, and we won't fix the module shipped by cmake itself, then we may close this as WONTFIX or CANTFIX, at least as of now I still see the upstream bug open.
I'll close this as the two packages listed as affected are fixed. If there is anything else please let me know.
