When trying to manipulate python3 packages for epel6, I get a lot of problems like this: (0) rharwood@seton:~/python3-gssapi.epel/el6 <el6> FEDORA $ fedpkg build error: line 40: %package -n python3-gssapi: package python3-gssapi already exists error: query of specfile /home/rharwood/python3-gssapi.epel/el6/python3-gssapi.spec failed, can't parse Could not get n-v-r-e from /home/rharwood/python3-gssapi.epel/el6/python3-gssapi.spec Note: You can skip NVR construction & NVR check with --skip-nvr-check. See help for more info. Could not execute build: Cannot continue without properly constructed NVR. {1} (2) rharwood@seton:~/python3-gssapi.epel/el6 <el6> FEDORA $ and rharwood@seton:~/python3-gssapi.epel/el6 <el6> FEDORA $ fedpkg commit -c Could not execute commit: error: line 40: %package -n python3-gssapi: package python3-gssapi already exists error: query of specfile /home/rharwood/python3-gssapi.epel/el6/python3-gssapi.spec failed, can't parse This package isn't for the host system (fc30); it's for an epel6 system. fedpkg shouldn't be expanding this variable here, and it definitely shouldn't be fatal.
Fedpkg does not expand anything. It merely runs rpm to extract NVR from the spec file. fedpkg -v -d will show the exact command that is being run. I'm getting this: $ rpm --define '_sourcedir /tmp/python3-gssapi' --define '_specdir /tmp/python3-gssapi' --define '_builddir /tmp/python3-gssapi' --define '_srcrpmdir /tmp/python3-gssapi' --define '_rpmdir /tmp/python3-gssapi' --define 'dist %{?distprefix}.el6' --define 'rhel 6' --eval '%undefine fedora' --define 'el6 1' --eval '%undefine fc30' -q --qf "??%{NAME} %{EPOCH} %{VERSION} %{RELEASE}??" --specfile "/tmp/python3-gssapi/python3-gssapi.spec" error: line 40: %package -n python3-gssapi: package python3-gssapi already exists error: query of specfile /tmp/python3-gssapi/python3-gssapi.spec failed, can't parse For build you might be able to work around it by using fedpkg build --skip-nvr-check. For commit you can just use git directly.
Regardless of what's ultimately responsible, I think it is not unreasonable to want to build epel packages, and fedpkg is the tool to do that. While there are workarounds and some commands (though not all) do have forcing flags, it is cumbersome and very much not a good user experience as things stand now.
The following works okay as a workaround: mock epel-7-x86_64 --buildsrpm --spec whatever.spec --source . cp /var/lib/mock/epel-7-x86_64/results/whatever*x86_64.rpm . mock epel-7-x86_64 --rebuild whatever*x86_64.rpm
This is probably a mock rather than fedpkg bug.
I don't really see how mock is involved in `fedpkg commit -c`, for instance. But if that fixes it, I'm not going to complain :)
Right now mock is not involved. However to reliably fix this issue, it would have to be used for any query on the spec file. That would probably have significant performance penalties. Either way it's not a small change.
I can reproduce the issue for example with command $ fedora-review -rn python3-m2crypto-0.35.2-5.el7.src.rpm -m epel-7-x86_64 (src.rpm from https://bugzilla.redhat.com/show_bug.cgi?id=1772387#c1 ) $ fedora-review -rn python3-dateutil-2.8.0-2.el7.src.rpm -m epel-7-x86_64 INFO: Processing local files: python3-dateutil-2.8.0-2.el7.src.rpm INFO: Getting .spec and .srpm Urls from : Local files in /home/user INFO: --> SRPM url: file:///home/user/python3-dateutil-2.8.0-2.el7.src.rpm INFO: Using review directory: /home/user/python3-dateutil errore: line 26: %package -n python3-dateutil: package python3-dateutil already exists ERROR: "Can't parse specfile: can't parse specfile\n" (logs in /home/user/.cache/fedora-review.log) Exception ignored in: <FedoraReview.spec_file._Null object at 0x7f5bd71d2e90> AttributeError: '_Null' object has no attribute 'flush' [user@theta-1 ~]$ cat /home/user/.cache/fedora-review.log 11-14 16:10 root DEBUG fedora-review 0.7.3 44b83c7 2019-09-18 21:41:36 -0400 started 11-14 16:10 root DEBUG Command line: /usr/bin/fedora-review -rn python3-dateutil-2.8.0-2.el7.src.rpm -m epel-7-x86_64 11-14 16:10 root INFO Processing local files: python3-dateutil-2.8.0-2.el7.src.rpm 11-14 16:10 root DEBUG Active settings after processing options 11-14 16:10 root DEBUG bz_url: https://bugzilla.redhat.com 11-14 16:10 root DEBUG _con_handler: <StreamHandler <stderr> (INFO)> 11-14 16:10 root DEBUG _log_config_done: True 11-14 16:10 root DEBUG cache: False 11-14 16:10 root DEBUG resultdir: None 11-14 16:10 root DEBUG init_done: True 11-14 16:10 root DEBUG uniqueext: None 11-14 16:10 root DEBUG configdir: None 11-14 16:10 root DEBUG log_level: 20 11-14 16:10 root DEBUG prebuilt: False 11-14 16:10 root DEBUG verbose: False 11-14 16:10 root DEBUG name: python3-dateutil-2.8.0-2.el7.src.rpm 11-14 16:10 root DEBUG use_colors: True 11-14 16:10 root DEBUG session_log: /home/user/.cache/fedora-review.log 11-14 16:10 root DEBUG bug: None 11-14 16:10 root DEBUG url: None 11-14 16:10 root DEBUG copr_build_descriptor: None 11-14 16:10 root DEBUG list_checks: False 11-14 16:10 root DEBUG list_flags: False 11-14 16:10 root DEBUG list_plugins: False 11-14 16:10 root DEBUG version: False 11-14 16:10 root DEBUG flags: [] 11-14 16:10 root DEBUG repo: None 11-14 16:10 root DEBUG mock_config: epel-7-x86_64 11-14 16:10 root DEBUG no_report: False 11-14 16:10 root DEBUG nobuild: False 11-14 16:10 root DEBUG mock_options: --no-bootstrap-chroot --no-cleanup-after --no-clean 11-14 16:10 root DEBUG other_bz: None 11-14 16:10 root DEBUG plugins_arg: None 11-14 16:10 root DEBUG single: None 11-14 16:10 root DEBUG rpm_spec: True 11-14 16:10 root DEBUG exclude: None 11-14 16:10 root DEBUG checksum: sha256 11-14 16:10 root DEBUG plugins: {} 11-14 16:10 root INFO Getting .spec and .srpm Urls from : Local files in /home/user 11-14 16:10 root INFO --> SRPM url: file:///home/user/python3-dateutil-2.8.0-2.el7.src.rpm 11-14 16:10 root INFO Using review directory: /home/user/python3-dateutil 11-14 16:10 root DEBUG find_urls completed: 0.043 11-14 16:11 root DEBUG Avoiding init of working mock root 11-14 16:11 root DEBUG Url download completed: 3.339 11-14 16:11 root DEBUG ReviewError: "Can't parse specfile: can't parse specfile\n" Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/FedoraReview/spec_file.py", line 75, in parse_spec self.spec = spec(self.filename) ValueError: can't parse specfile During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py", line 236, in run self._do_run(outfile) File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py", line 226, in _do_run self._do_report(outfile) File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py", line 99, in _do_report self._run_checks(self.bug.spec_file, self.bug.srpm_file, outfile) File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py", line 108, in _run_checks self.checks = Checks(spec, srpm) File "/usr/lib/python3.7/site-packages/FedoraReview/checks.py", line 280, in __init__ self.spec = SpecFile(spec_file, self.flags) File "/usr/lib/python3.7/site-packages/FedoraReview/spec_file.py", line 86, in __init__ parse_spec() File "/usr/lib/python3.7/site-packages/FedoraReview/spec_file.py", line 77, in parse_spec raise SpecParseReviewError("Can't parse specfile: " + ex.__str__()) FedoraReview.review_error.SpecParseReviewError: "Can't parse specfile: can't parse specfile\n" 11-14 16:11 root ERROR ERROR: "Can't parse specfile: can't parse specfile\n" (logs in /home/user/.cache/fedora-review.log) 11-14 16:11 root DEBUG Report completed: 4.813 seconds
This is probably a better work around. Update your own ~/.rpmmacros to simulate the target build, so for EPEL7 cat ~/.rpmmacros %python3_pkgversion 36 or EPEL6 %python3_pkgversion 34 This should avoid the clash for mock, fedpkg, fedora-packager, ... on EPEL6 and EPEL7 Obviously be sure to remove the setting before doing any non EPEL6-7 packaging or else bad things will happen. Steve.
(In reply to Steve Traylen from comment #8) > This is probably a better work around. Update your own ~/.rpmmacros to > simulate the target build, so for > > EPEL7 > > cat ~/.rpmmacros > > %python3_pkgversion 36 > > or EPEL6 > > %python3_pkgversion 34 > > > This should avoid the clash for mock, fedpkg, fedora-packager, ... on EPEL6 > and EPEL7 > > Obviously be sure to remove the setting before doing any non EPEL6-7 > packaging or else bad things will happen. > > Steve. It worked, thank you very much
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Conservatively only bumping to fc31 because that's what I can easily test, but I have no reason to suspect it's been fixed in any newer versions either.
I just found this bugzilla by coincidence. I think this RFE should fix the problem for good: https://pagure.io/rpkg/issue/495
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still broken on Fedora 33 and newer.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
rhpkg (fedpkg backend) now supports this as an opt-in flag: https://docs.pagure.org/rpkg/releases/1.64.html#support-building-srpms-in-target-mock
Fixed in rpkg-1.64-2 in all supported Fedora releases.