Releases retrieved: 21.12 Upstream release that is considered latest: 21.12 Current version/release in rawhide: 3.19.6-1.fc38 URL: https://developers.google.com/protocol-buffers 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/3715/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/protobuf
Created attachment 1932850 [details] Update to 21.12 (#2153789)
the-new-hotness/release-monitoring.org's scratch build of protobuf-21.12-1.fc36.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=95399580
Releases retrieved: 22.0 Upstream release that is considered latest: 22.0 Current version/release in rawhide: 3.19.6-2.fc38 URL: https://developers.google.com/protocol-buffers 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/3715/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/protobuf
Scratch build failed. Details below: FileNotFoundError: [Errno 2] No such file or directory: '/var/tmp/thn-hvrqxeh8/%{_emacs_version}' Traceback: File "/usr/local/lib/python3.10/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.10/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.10/site-packages/hotness/builders/koji.py", line 451, in _scratch_build session.uploadWrapper(source, serverdir) File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3110, in uploadWrapper self.fastUpload(localfile, path, name, callback, blocksize, overwrite, volume=volume) File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 2988, in fastUpload fo = open(localfile, 'rb') 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
I’ve been focused on a few other big package upgrades, but I guess it’s about time to return to protobuf before it, and grpc, fall *too* far behind. The next step should probably be an upgrade to https://github.com/protocolbuffers/protobuf/releases/tag/v3.20.3 in F39/Rawhide. That will involve rebuilding all dependent packages. After that, it’s on to the 4.0 series, currently at https://github.com/protocolbuffers/protobuf/releases/tag/v22.0. The impact is probably going to be huge, and take a long time to work through in COPR. I suspect it would be appropriate to write up a Change Proposal for this, probably after we’ve done some work in COPR to understand what it is we need to do. Since there are so many dependent packages, we’ll need a provenpackager to handle rebuilds for 3.20.x and for all future similar upgrades. Is there a volunteer on the CC list for this bug? Is it time for mhayden, me (FAS music), or both to apply for provenpackager status?
(In reply to Ben Beasley from comment #5) > I’ve been focused on a few other big package upgrades, but I guess it’s > about time to return to protobuf before it, and grpc, fall *too* far behind. > > The next step should probably be an upgrade to > https://github.com/protocolbuffers/protobuf/releases/tag/v3.20.3 in > F39/Rawhide. That will involve rebuilding all dependent packages. > > After that, it’s on to the 4.0 series, currently at > https://github.com/protocolbuffers/protobuf/releases/tag/v22.0. The impact > is probably going to be huge, and take a long time to work through in COPR. > I suspect it would be appropriate to write up a Change Proposal for this, > probably after we’ve done some work in COPR to understand what it is we need > to do. Why go the step to 3.20.3 at all? Why not just directly to the latest version? I have done the previous updates of protobuf in rawhide and I always went to the latest version. > Since there are so many dependent packages, we’ll need a provenpackager to > handle rebuilds for 3.20.x and for all future similar upgrades. Is there a > volunteer on the CC list for this bug? Is it time for mhayden, me (FAS > music), or both to apply for provenpackager status? I can to the rebuilds. I have done the whole thing a couple of times, first in COPR and then in a koji side tag.
(In reply to Adrian Reber from comment #6) > Why go the step to 3.20.3 at all? Why not just directly to the latest > version? > > I have done the previous updates of protobuf in rawhide and I always went to > the latest version. I think the transition from 3.x to 4.x is going to take a lot more time and effort than a typical “minor release” update. I know a lot of dependent packages have required upstream changes for Protobuf 4, and I suspect this will involve coordinating a lot of dependent package updates. For example, it will definitely have to be coordinated with a grpc update. Going to the last 3.x release first could be a hedge against not getting the 4.x work done in time for F39. But we could attempt going straight to 4.x and see how it goes, if we like. > I can to the rebuilds. I have done the whole thing a couple of times, first > in COPR and then in a koji side tag. Thanks!
I tried to build 3.20.3 and it fails with Python 3.11 build errors. Have you tried building 3.20.3 on current rawhide?
Releases retrieved: 22.1 Upstream release that is considered latest: 22.1 Current version/release in rawhide: 3.19.6-2.fc38 URL: https://developers.google.com/protocol-buffers 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/3715/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/protobuf
Scratch build failed. Details below: FileNotFoundError: [Errno 2] No such file or directory: '/var/tmp/thn-bxgbv13w/%{_emacs_version}' Traceback: File "/usr/local/lib/python3.10/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.10/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.10/site-packages/hotness/builders/koji.py", line 451, in _scratch_build session.uploadWrapper(source, serverdir) File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3110, in uploadWrapper self.fastUpload(localfile, path, name, callback, blocksize, overwrite, volume=volume) File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 2988, in fastUpload fo = open(localfile, 'rb') 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
Releases retrieved: 22.2 Upstream release that is considered latest: 22.2 Current version/release in rawhide: 3.19.6-2.fc38 URL: https://developers.google.com/protocol-buffers 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/3715/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/protobuf
Scratch build failed. Details below: FileNotFoundError: [Errno 2] No such file or directory: '/var/tmp/thn-n_151os0/%{_emacs_version}' Traceback: File "/usr/local/lib/python3.10/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.10/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.10/site-packages/hotness/builders/koji.py", line 451, in _scratch_build session.uploadWrapper(source, serverdir) File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3110, in uploadWrapper self.fastUpload(localfile, path, name, callback, blocksize, overwrite, volume=volume) File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 2988, in fastUpload fo = open(localfile, 'rb') 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
It looks like bug 1831350 is getting updated by release-monitoring, so I’ll set this one as a duplicate of that one. *** This bug has been marked as a duplicate of bug 1831350 ***