protobuf fails to build with Python 3.9.0b1. ... ./google/protobuf/parse_context.h:397:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] 397 | return *ptr == tag; | ~~~~~^~~~~~ ./google/protobuf/parse_context.h: In instantiation of 'bool google::protobuf::internal::ExpectTag(const char*) [with unsigned int tag = 138]': google/protobuf/map_lite_unittest.pb.cc:1635:73: required from here ./google/protobuf/parse_context.h:397:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] ./google/protobuf/parse_context.h: In instantiation of 'bool google::protobuf::internal::ExpectTag(const char*) [with unsigned int tag = 146]': google/protobuf/map_lite_unittest.pb.cc:1647:73: required from here ./google/protobuf/parse_context.h:397:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] ./google/protobuf/parse_context.h: In instantiation of 'bool google::protobuf::internal::ExpectTag(const char*) [with unsigned int tag = 810]': google/protobuf/map_lite_unittest.pb.cc:4197:73: required from here ./google/protobuf/parse_context.h:397:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] ./google/protobuf/parse_context.h: In instantiation of 'bool google::protobuf::internal::ExpectTag(const char*) [with unsigned int tag = 818]': google/protobuf/map_lite_unittest.pb.cc:4210:73: required from here ./google/protobuf/parse_context.h:397:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] CXX google/protobuf/no_warning_test-unittest_lite.pb.o In file included from ./google/protobuf/map_type_handler.h:34, from ./google/protobuf/map.h:49, from ./google/protobuf/generated_message_table_driven.h:34, from ./google/protobuf/unittest_lite.pb.h:26, from google/protobuf/unittest_lite.pb.cc:4: ./google/protobuf/parse_context.h: In instantiation of 'bool google::protobuf::internal::ExpectTag(const char*) [with unsigned int tag = 248]': google/protobuf/unittest_lite.pb.cc:2361:73: required from here ./google/protobuf/parse_context.h:397:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] 397 | return *ptr == tag; | ~~~~~^~~~~~ ... For the build logs, see: https://copr-be.cloud.fedoraproject.org/results/@python/python3.9/fedora-rawhide-x86_64/01396337-protobuf/ For all our attempts to build protobuf with Python 3.9, see: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/package/protobuf/ Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.9: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/ Let us know here if you have any questions. Python 3.9 will be included in Fedora 33. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.9. A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon. We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.
See also https://koschei.fedoraproject.org/package/protobuf?collection=f33
This comment is mass posted to all bugs blocking the Python 3.9 tracker, sorry if it is not 100 % relevant. When in doubt, please ask. The Python 3.9 rebuild is in progress in a Koji side tag. If you fix this bug, please don't rebuild the package in regular rawhide, but do it in the side tag with: $ fedpkg build --target=f33-python The rebuild is progressing slowly and it is possible this package won't have all the required build dependencies yet. If that's the case, please just leave the fix committed and pushed and we will eventually rebuild it for you. You are not asked to go and try rebuild all the missing dependencies yourself. If you know there is a bootstrap loop in the dependencies, let me know and we can untangle it together. If you want to test your fix or reproduce the failure, you can still use the Copr repo mentioned in the initial comment of this bug: https://copr.fedorainfracloud.org/coprs/g/python/python3.9/
This might be a gcc issue: https://github.com/protocolbuffers/protobuf/issues/7514 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95148 Jakub, are you able to help?
I plan to push -Wno-error=type-limits for now as a workaround. Running a scratchbuild before I do that.
Didn't help :( https://koji.fedoraproject.org/koji/taskinfo?taskID=45067587
I was just to ask if you tried it already with a newer version of protobuf (3.12.1), which would require a lot of rebuilds, but then I saw the github issue and that seems to happen on the latest master branch of protobuf. So a newer version of protobuf will probably not help. Having a closer look I do not see -Wno-error=type-limits applied in the %check section. This probably also needs to be applied to in the %check section.
(In reply to Adrian Reber from comment #6) > Having a closer look I do not see -Wno-error=type-limits applied in the > %check section. This probably also needs to be applied to in the %check > section. Yes, that works. Thanks for the tip.
Python 3.9 update: The f33-python side tag is currently being merged. New builds in f33-python are no longer possible, but python3 is not yet updated to Python 3.9 in rawhide. You can check when Python is Python 3.9 with: $ koji wait-repo f33-build --build python3.9-3.9.0~b1-3.fc3 And build the packages normally after that.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
PR: https://src.fedoraproject.org/rpms/protobuf/pull-request/5 The update however introduces a soname bump so an announcement to the devel list and a rebuild of all the dependent packages will be required.
Setting needinfo on Adrian as he seemed to have handled the previous updates
I can do the rebuild. I will announce it on the devel list and do a COPR test run.
FEDORA-2020-7cb9b0c7a3 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days