fedora-infrastructure

#11767 Spec file parsing fails with rpmautospec in Koji
Closed: Fixed by nphilipp. Opened by music.

Closed: Fixed
Reopen Issue

NOTE

If your issue is for security or deals with sensitive info please
mark it as private using the checkbox below.

Describe what you would like us to do:

Please investigate why packages that use rpmautospec are failing in Koji with rpmautospec.exc.SpecParseFailure: Couldn’t parse spec file […].spec.

Example: https://koji.fedoraproject.org/koji/taskinfo?taskID=113290117

I first encountered this in https://koji.fedoraproject.org/koji/taskinfo?taskID=113239379; I built that package successfully by converting it back to a conventional release field and changelog.

It seems like whatever is happening is new as of the last day or so (as of 2024-02-10; I think I saw the first failure on 2024-02-09), and it seems like it might affect all packages that use rpmautospec.

When do you need this to be done by? (YYYY/MM/DD)

ASAP; if this truly affects all rpmautospec packages, the impact will be widespread.

It looks like rpmautospec was updated to 0.6.1 yesterday, https://bodhi.fedoraproject.org/updates/?packages=python-rpmautospec, https://github.com/fedora-infra/rpmautospec, but when I manually installed the packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=2400455 on F39 I still couldn’t reproduce the problem. Still, it might be related.

I upgraded builders to f39 on wed, and with that came a update to python-rpmautospec to 0.6.1...

I've now downgraded to 0.5.1 and confirmed that this works around the issue you were hitting.

Can you file a upstream rpmautospec bug on this? https://github.com/fedora-infra/rpmautospec/issues

Then hopefully @nphilipp can look monday...

Metadata Update from @kevin:
- Issue close_status updated to: Upstream
- Issue status updated to: Closed (was: Open)

Filed upstream: https://github.com/fedora-infra/rpmautospec/issues/68

I upgraded builders to f39 on wed, and with that came a update to python-rpmautospec to 0.6.1...

I've now downgraded to 0.5.1 and confirmed that this works around the issue you were hitting.

Is there a chance that one or more builders didn’t get downgraded, or didn’t have kojid restarted?

I just saw this again in a Fedora CI scratch build on buildvm-s390x-18.s390.fedoraproject.org today, https://koji.fedoraproject.org/koji/taskinfo?taskID=113351214.
Edited by music

Metadata Update from @music:
- Issue status updated to: Open (was: Closed)

well, buildvm-s390x-19 was the parent there, the actual task ran on buildvm-a64-09.iad2.fedoraproject.org... but both of them are on 0.5.1.

I did another check, theres 0 builders using 0.6.1. ;(

I also made sure kojid was restarted 23h ago and it was.

I'm not sure if this is the same issue...

Maybe the downgrade wasn’t the real fix, and something else caused it to succeed before? This is pretty confusing…

I think I'm seeing this too:

https://koji.fedoraproject.org/koji/taskinfo?taskID=113400475

Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=113400475
Watching tasks (this may be safely interrupted)...
113400475 build (f38-candidate, /rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98): free
113400475 build (f38-candidate, /rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98): free -> open (buildvm-s390x-20.s390.fedoraproject.org)
  113400484 buildSRPMFromSCM (/rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98): free
  113400484 buildSRPMFromSCM (/rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98): free -> open (buildvm-a64-14.iad2.fedoraproject.org)
113400475 build (f38-candidate, /rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98): open (buildvm-s390x-20.s390.fedoraproject.org) -> FAILED: CallbackError: Error running postSCMCheckout callback from rpmautospec_koji.rpmautospec_builder:
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/koji/plugin.py", line 221, in run_callbacks
    func(cbtype, *cb_args, **cb_kwargs)
  File "/usr/lib/python3.12/site-packages/rpmautospec_koji/rpmautospec_builder.py", line 19, in process_distgit_cb
    if not process_distgit(srcdir, enable_caching=False):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/rpmautospec/subcommands/process_distgit.py", line 103, in process_distgit
    raise SpecParseFailure(f"Couldn’t parse spec file {processor.specfile.name}")
rpmautospec.exc.SpecParseFailure: Couldn’t parse spec file python-fslpy.spec
  0 free  1 open  0 done  1 failed
  113400484 buildSRPMFromSCM (/rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98): open (buildvm-a64-14.iad2.fedoraproject.org) -> FAILED: CallbackError: Error running postSCMCheckout callback from rpmautospec_koji.rpmautospec_builder:
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/koji/plugin.py", line 221, in run_callbacks
    func(cbtype, *cb_args, **cb_kwargs)
  File "/usr/lib/python3.12/site-packages/rpmautospec_koji/rpmautospec_builder.py", line 19, in process_distgit_cb
    if not process_distgit(srcdir, enable_caching=False):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/rpmautospec/subcommands/process_distgit.py", line 103, in process_distgit
    raise SpecParseFailure(f"Couldn’t parse spec file {processor.specfile.name}")
rpmautospec.exc.SpecParseFailure: Couldn’t parse spec file python-fslpy.spec
  0 free  0 open  0 done  2 failed
113400475 build (f38-candidate, /rpms/python-fslpy.git:5e227085d03b0d2e7b31e2579991c6bf975abe98) failed

I’ve looked into this issue on my own (only found this ticket now). I think the reason is that builders where this works (e.g. buildvm-x86-*) have the RPM macro packages installed which are necessary to parse the spec files. Older versions (< 0.5) used rpm --specfile ... to parse spec files, i.e. depended on rpm-build which in turn depended on redhat-rpm-config (and so forth). The rpmautospec updates currently in testing let the Koji plugin explicitly depend on redhat-rpm-config which should fix the issue after the updates are deployed onto the builders.
Edited by nphilipp

I’ve looked into this issue on my own …

Thanks for investigating!

Metadata Update from @phsmoura:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: medium-gain, medium-trouble, ops

This should all be deployed now...

The updated packages are deployed on the builders now, this issue should be fixed.

Metadata Update from @nphilipp:
- Issue untagged with: medium-gain, medium-trouble, ops
- Issue close_status updated to: Fixed
- Issue priority set to: Needs Review (was: Waiting on Assignee)
- Issue status updated to: Closed (was: Open)

Thanks again!
Metadata
None
None
None
None
Lowest
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.