Move package NEVR parsing to builder

[FrostyX]

Fix #2790
Fix #2777

[FrostyX]

Some of the backend tests are failing. That's because we need to add results.json file here
https://github.com/fedora-copr/test-data-copr-backend/tree/main/build_results/00848963-example

{
    "name": "example",
    "epoch": null,
    "version": "1.0.14",
    "release": "1",
    "exclusivearch": [],
    "excludearch": []
}

The problem is, this test directory is for RPM build, not SRPM. We are only abusing it for testing SRPM builds as well. So this will require a bit more changes. But the code itself works fine.

[nikromen]

thanks for the PR!
I just have one question below but apart from that +1

[nikromen]

What happens if specfile parsing fails for some reason (other than no spec file found), would this backup approach fail too? Are we giving up the backup approach and we trust specfile library in every case?

[FrostyX]

I don't know :-).
But we should cover it in tests for sure.

[FrostyX]

@praiskup, as @nikromen pointed out, I completely removed the pkg_name_evr_from_srpm function and rely solely on parsing version and name from the spec file. Do want to go with this? Or should I move the pkg_name_evr_from_srpm function to builder as well and use it if something goes wrong when parsing the spec file?

[praiskup]

That was kind of a safety belt (I still don't trust python-specfile that much, also - newly it will be run on multiple architectures). But I won't argue too much on this :-)

[praiskup]

+1, but these two are worth fixing

Error: PYLINT_WARNING:
copr_backend/background_worker_build.py:634:13: W1514[unspecified-encoding]: BuildBackgroundWorker._get_srpm_build_details: Using open without explicitly specifying an encoding

Error: PYLINT_WARNING:
copr_backend/helpers.py:35: W0611[unused-import]: Unused CoprBackendSrpmError imported from copr_backend.exceptions

[FrostyX]

Fixed linter errors and tests, PTAL

[praiskup]

I submited the issue packit/specfile#255 for this.

[praiskup]

I tested a bit specfile v0.20 on epel8 and wasn't able to make it work. So I don't think there's an easy way to update specfile into EPEL8 (missing setup.py, incompatible (too new) typing, I stopped there...).

The question is - is the python-specfile in epel 8 "new enough" for us (100% working, but slow), or does this actually mean we have to drop the support for EPEL8?

[praiskup]

Getting to EPEL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8a36e6e848 so we can probably drop the %if/%else

[praiskup]

@FrostyX @nikromen can you give +1 to https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8a36e6e848?

[FrostyX]

I added a simple beaker test and the rpm -qip fallback.
Also, CI fails for rawhide but it is not related to this PR. Even main branch fails.