| Summary: | We still have rpmlint 1.11 while upstream is at 2.5.0 now | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Kristoffer Grundström <lovaren> |
| Component: | RPM Packages | Assignee: | RPM stack maintainers <rpmstack> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | j.alberto.vc, lovaren, marja11, ngompa13, xerxes2 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA8TOO? | ||
| Source RPM: | rpmlint | CVE: | |
| Status comment: | |||
| Attachments: |
Proposal spec file
Regex patch Full build output Updated proposal spec file Updated full build output katnatek version of rpmlint 2.4.0 spec |
||
|
Kristoffer Grundström
2022-05-14 08:32:39 CEST
CC:
(none) =>
lovaren Thanks for spotting this, Kristoffer. I don't know whether our updates policy allows for upgrading rpmlint in stable. It should be done in cauldron first, anyway. Assignee:
bugsquad =>
rpmstack *** Bug 30892 has been marked as a duplicate of this bug. ***
Kristoffer Grundström
2022-12-09 09:48:53 CET
Summary:
We still have rpmlint 1.11 while upstream is at 2.2 now =>
We still have rpmlint 1.11 while upstream is at 2.4.0 now Created attachment 13554 [details]
Proposal spec file
Please note that I had to make some significant changes since I used the spec file from Fedora because our spec file for 1.11 didn't work to build 2.4.0 even with our patches.
Feel free to change it as you please, but it will build successfully.
Created attachment 13555 [details]
Regex patch
Created attachment 13556 [details]
Full build output
I don't know if rpmlint-fedora-license-data brings any use to Mageia, but I built and installed that as well. (In reply to Kristoffer Grundström from comment #7) > I don't know if rpmlint-fedora-license-data brings any use to Mageia, but I > built and installed that as well. We follow Fedora's licensing guidance, so yes, it would make sense here. CC:
(none) =>
ngompa13 No harm meant for asking, but why are we still at 1.11 even after the release of Mageia 9? Rpmlint seems to have no maintainer atm. http://pkgsubmit.mageia.org/data/maintdb.txt Also RPM, DNF and DNF5 are outdated. CC:
(none) =>
xerxes2 Created attachment 14058 [details] katnatek version of rpmlint 2.4.0 spec I import some things from fedora's spec to Kristoffer spec, build well on my system, but fail in my copr :S https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06526702-rpmlint/builder-live.log.gz
Attachment 13600 is obsolete:
0 =>
1
katnatek
2023-10-15 04:07:21 CEST
CC:
(none) =>
j.alberto.vc Disabling the test the build is successful in copr :) https://copr.fedorainfracloud.org/coprs/katnatek/blogdrake/build/6527080/ I test built 2.5.0, feel free to adjust the package accordingly and here's my repo: https://copr.fedorainfracloud.org/coprs/umeaman/rpmlint/build/6562315/ Summary:
We still have rpmlint 1.11 while upstream is at 2.4.0 now =>
We still have rpmlint 1.11 while upstream is at 2.5.0 now Btw, I think I've found a regression from 2009. While using the new rpmlint version on a spec file it gives no-buildroot-tag warning even though this spec file doesn't contain buildroot anywhere. If you read the Fedora page about that issue they state that buildroot should NOT BE USED so this warning should not happen. This problem has been reported in RedHat and closed, here's the link: https://bugzilla.redhat.com/show_bug.cgi?id=516378 |
Description of problem: I noticed that our version of rpmlint is somewhat old. I therefor ask to have it updated. These are the new improvements according to the repo on GitHub: Fixed support for loading .rpmlintrc files Added support for /usr/lib/modules as a valid path for kernel modules in packages Added /usr/share/dbus-1/system.d to D-Bus config folder list Massively reworked the shlib-policy-name-error rules Added support for %autochangelog macro in %changelog section Improved support for detecting whether code is compiled correctly with hardening flags Multiple fixes to library dependency checks Added support for libalternatives as an alternative to alternatives Version-Release number of selected component (if applicable): 2.2