rpmlint-2.4.0: patch-not-applied for %patch -P<n>
juhp opened this issue · comments
rpmlint-2.4.0 seems unaware of %patch -P which is now the preferred way to apply patches in Fedora/EPEL at least.
(Recent rpmbuild gives a warning for %patch<n>.)
I guess rpmlint needs to be taught about the %patch -P<n> options that deprecates %patch<n>.
I think also the newer %patch <n>.
So, it is already fixed upstream?
It should be there, do you have any example package to test? Maybe it's not detecting correctly some cases, so if you know about some package that produces "wrong" errors, let me know and I'll try to create some test case and we can fix it.
Yes, still happening in Fedora Rawhide:
$ fedpkg clone ghc
$ cd ghc
$ rpmlint ghc.spec
============================ rpmlint session starts ============================
rpmlint: 2.4.0
configuration:
/usr/lib/python3.12/site-packages/rpmlint/configdefaults.toml
/etc/xdg/rpmlint/fedora-legacy-licenses.toml
/etc/xdg/rpmlint/fedora-spdx-licenses.toml
/etc/xdg/rpmlint/fedora.toml
/etc/xdg/rpmlint/scoring.toml
/etc/xdg/rpmlint/users-groups.toml
/etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 1
ghc.spec: W: patch-not-applied Patch1: ghc-gen_contents_index-haddock-path.patch
ghc.spec: W: patch-not-applied Patch2: ghc-Cabal-install-PATH-warning.patch
ghc.spec: W: patch-not-applied Patch3: ghc-gen_contents_index-nodocs.patch
ghc.spec: W: patch-not-applied Patch5: https://gitlab.haskell.org/ghc/ghc/-/commit/6e12e3c178fe9ad16131eb3c089bd6578976f5d6.patch
ghc.spec: W: patch-not-applied Patch7: ghc-compiler-enable-build-id.patch
ghc.spec: W: patch-not-applied Patch8: ghc-configure-c99.patch
ghc.spec: W: patch-not-applied Patch9: https://gitlab.haskell.org/ghc/ghc/-/commit/00dc51060881df81258ba3b3bdf447294618a4de.patch
ghc.spec: W: patch-not-applied Patch10: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10922.patch
ghc.spec: W: patch-not-applied Patch11: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10928.patch
ghc.spec: W: patch-not-applied Patch12: ghc-armv7-VFPv3D16--NEON.patch
ghc.spec: W: patch-not-applied Patch13: text2-allow-ghc8-arm.patch
ghc.spec: W: patch-not-applied Patch15: ghc-warnings.mk-CC-Wall.patch
ghc.spec: W: patch-not-applied Patch16: ghc-hadrian-s390x-rts--qg.patch
ghc.spec: W: patch-not-applied Patch24: buildpath-abi-stability.patch
ghc.spec: W: patch-not-applied Patch26: no-missing-haddock-file-warning.patch
ghc.spec: W: patch-not-applied Patch27: haddock-remove-googleapis-fonts.patch
ghc.spec: W: patch-not-applied Patch30: https://src.opensuse.org/rpm/ghc/raw/branch/factory/sphinx7.patch
0 packages and 1 specfiles checked; 0 errors, 17 warnings, 0 badness; has taken 0.3 s Another example is Fedora intltool.spec
I think that the intltool.spec file is not correct, it's failing in this case because it's using %patch 1 -p1 so rpmlint is not detecting that like a correct patch.
The problem with ghc could be some kind of configuration, in my case, running with the latest rpmlint main branch I get this:
$ CONFIG_DISABLE_AUTOLOADING=1 ./lint.py -c configs/Fedora/ test/spec/ghc.spec
============================================ rpmlint session starts ===========================================
rpmlint: 2.4.0
configuration:
/home/danigm/Projects/suse/rpmlint/rpmlint/configdefaults.toml
configs/Fedora/fedora.toml
configs/Fedora/licenses.toml
configs/Fedora/scoring.toml
configs/Fedora/users-groups.toml
configs/Fedora/warn-on-functions.toml
checks: 32, packages: 1
ghc.spec: W: patch-not-applied Patch24: buildpath-abi-stability.patch
ghc.spec: W: %ifarch-applied-patch Patch12: ghc-armv7-VFPv3D16--NEON.patch
ghc.spec: W: %ifarch-applied-patch Patch13: text2-allow-ghc8-arm.patch
ghc.spec: W: %ifarch-applied-patch Patch15: ghc-warnings.mk-CC-Wall.patch
ghc.spec: W: %ifarch-applied-patch Patch16: ghc-hadrian-s390x-rts--qg.patch
======= 0 packages and 1 specfiles checked; 0 errors, 5 warnings, 1 filtered, 0 badness; has taken 0.1 s ======
The Patch24 error here is correct because that line is commented in the spec file, so I'm not getting the same result. I will try to run this in a Fedora container to check if it's because of configuration or something else related to the environment, maybe the python interpreter used or something like that.
Okay, I don't think intltool is strictly incorrect (it works), but maybe less compatible.
I will try to look at ghc and work out what could be happening.
ghc-hledger.spec seems okay indeed.
But something similar happens with gcc.spec and lua.spec for me: maybe it is related with spec file complexity?
Or maybe it is my environment? I am running inside Fedora toolbox.
Okay, I can confirm that this problem is a version issue. The latest release (2.4.0) doesn't do the check correctly. I've not noticed this because SUSE package uses the latest opensuse branch, but fedora uses the release, so we need a new release to fix this.
I'll create a new release (2.4.1) soon, and I think that will fix this issue, at least the problem with ghc. If the usage in the intltool.spec package is correct, we can extend the check to support %patch n, so I can try to do that before the release and we can cover more cases.
New release is done, we can close this as solved. The problem should be fixed in Fedora rawhide as soon as the package rpmlint is updated.