Skip to content

Conversation

@dcermak
Copy link
Contributor

@dcermak dcermak commented Jun 15, 2025

These properties are required to convert Fedora to openSUSE style changelogs for packit

TODO:

  • Write new tests or update the old ones to cover new functionality.
  • Update doc-strings where appropriate.
  • [-] Update or write new documentation in packit/packit.dev.

Fixes

Related to

Merge before/after

RELEASE NOTES BEGIN

  • add support to parse the author and timestamp from changelog entries
    RELEASE NOTES END

These properties are required to convert Fedora to openSUSE style changelogs for
packit
@softwarefactory-project-zuul
Copy link
Contributor

@dcermak
Copy link
Contributor Author

dcermak commented Jun 15, 2025

So, it looks like the tests only worked locally for me by accident, because I'm in the CEST timezone and I do have more timezone information available locally. To properly parse the timezone, we'd have to add another dependency. What's your opinion on this? Add a dependency or live with wrong timezones?

@majamassarini majamassarini requested a review from nforro June 16, 2025 09:05
@majamassarini majamassarini moved this from new to in-review in Packit Kanban Board Jun 16, 2025
Copy link
Member

@nforro nforro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To properly parse the timezone, we'd have to add another dependency. What's your opinion on this? Add a dependency or live with wrong timezones?

That's one of the reasons this was never implemented. Wrong timezones are a no-go, if we are going to implement this, let's do it right.

if not self.evr:
return author_and_evr

if (gt_ind := author_and_evr.rfind(">")) > 0:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This assumes the author substring always ends with a specifically formatted e-mail, but that doesn't have to be the case, even though Fedora Packaging Guidelines mandate so. specfile should be able to parse any format supported by RPM, which allows any string after the timestamp (ended by a newline) - and refers to it as name. What about adding a more generic name property and then deriving author and evr from it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have refactored the code a bit, so that it no longer relies on the > character to be present. But I am not sure if we should try to parse such a changelog correctly anyway. Imagine the following entry:

* Mon May 22 2023 $FirstName $LastName

Our evr regex will recognize $LastName as the EVR in this case and given that we allow anything as the evr, there's no way to distinguish it from a last name. At least nothing immediate comes to my mind.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true, but there are lots of spec files with changelog entries like this, for example:
https://src.fedoraproject.org/rpms/gdb/blob/rawhide/f/gdb.spec#_1516
https://src.fedoraproject.org/rpms/rpm-spec-language-server/blob/rawhide/f/rpm-spec-language-server.spec#_72

We could try to recognize these formats, and document that author/EVR parsing is best effort and doesn't have to be accurate:

  • * timestamp author - EVR
  • * timestamp author [EVR]
  • * timestamp author (EVR)
  • * timestamp author

@nforro
Copy link
Member

nforro commented Jun 16, 2025

To properly parse the timezone, we'd have to add another dependency

Perhaps adding another dependency could be avoided by matching the entries to RPM-parsed changelog - self.rpm_spec.sourceHeader[rpm.RPMTAG_CHANGELOGTIME] returns a list of Unix timestamps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: in-review

Development

Successfully merging this pull request may close these issues.

2 participants