https://bugzilla.redhat.com/show_bug.cgi?id=2369164
--- Comment #5 from Andrew Bauer <[email protected]> --- I am a bit surprised rpmlint didn't flag that misspelling. I'll fix the other requires and buildrequires. At some point long time ago, one did have to explicitly pull in cups as a runtime requirement. Cups package has the frontend to the print system, but I see the dependency is cups-libs-> cups-filesystem -> cups, so were are good. I need to double check this same dependency tree exists in el9. Regarding the package version number, I agree the Fedora packaging documentation does indeed instruct the packager to embed the git commit in the package version. Indeed, that is exactly what I am doing for other packages. However, the packaging documentation assumes upstream is using the upstream github site for version control. In this case, upstream is using github simply as a dropbox and nothing more. I wish they were using dropbox, because that would make the package version a non-issue. Here is the current folder tree: LW4xx Linux -> despite its name this folder contains windows driver in a zip file LW5xx_245 -> these are zipped up windows drivers LW5xx_Linux -> Source files we can use. Has not been modified since it was uploaded to github 2 years ago When upstream has a new "release" they delete one of the these folders and replace it with a new folder. Historically over the years, the only times Dymo has modified the Linux drivers was after new printer models have been released. This is why you see all those patches in the specfile. If they do modify the Linux src, then the version would get bumped in the bundled configure.ac. One can also see that Dymo has not given a single response to any of the issues on their github site. They aren't paying attention to feedback from the community. With this in mind, I don't think it is beneficial to set the version to 2.0.0.0-1.20250513git795a815. The implication in that version string is the package contains modifications to the original 2.0.0.0 release, which in this case it does not. I can do it anyway, just to satisfy our packaging documentation, but I don't think it is helpful. Note that I am not a fan of the autochangelog macro. I absolutely don't want every single commit to automatically show as a new changelog entry. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2369164 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202369164%23c5 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
