Description of problem: When I check debuginfo package I see: sh: /usr/bin/python: No such file or directory Version-Release number of selected component (if applicable): rpmlint-1.10-17.fc29.noarch How reproducible: Always if python-unversioned-command package not installed. Additional info: If package installed then this message not showed. Please correct it. Because rpmlint not depends on python-unversioned-command.
Fixed in rpmlint-1.10-18.fc30.
I am install it in F29 and problem still exist.
I have F30 container, inside I installed rpmlint-1.10-22.fc30.noarch and the problem still occurred Steps to reproduce: 1. podman pull fedora:30 2. podman run -ti <image_id> 3. dnf install fedora-packager 4. fedpkg clone file -a 5. cd file/ 6. rpmlint file.spec Error massage: sh: /usr/bin/python: No such file or directory
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
I suspect this error is coming from a macro somewhere. Nothing in rpmlint calls /usr/bin/python.
But problem still persist.
The problem may persist, but there is no indication that the problem (which isn't really a problem at all) is in rpmlint. rpmlint will call down into rpm and somehow in the various recursive macro expansions result in something trying to expand either %python_sitelib or %python_sitearch, which result in a subshell trying to call /usr/bin/python: 765644 execve("/bin/sh", ["sh", "-c", "/usr/bin/python -Esc \"from distu"...], 0x7ffc7a8bf190 /* 45 vars */ <unfinished ...> But rpmlint isn't doing this directly, so I don't think the bug is here. I don't even see how rpmlint is even trying to expand any macros which might somehow down the chain lead to expanding one of those. I'm playing with the debugger now and if I can figure it out then I'll try to at least indicate what the cause of this is.
First: a simpler way to see this is to uninstall python-unversioned-command, mkdir /tmp/foo; rpmlint /tmp/foo. Anything which causes rpmlint to load the check modules will show it. The issue still isn't rpmlint, it's that rpm will randomly output failures when expanding macros and provides no way to suppress the output. In this case, the initialization code for /usr/share/rpmlint/TagsCheck.py will attempt to expand %python_sitearch to get a path that it can add to private_so_paths, and that may cause rpm itself to emit some bits to stderr. I don't really see the benefit in Fedora patching around this when the output hurts nothing. If the list of macros that TagsCheck.py would use to extract those private paths was configurable then certainly we could override it in our configuration. Alternately rpmlint could redirect stderr around that call to rpm.expandMacro to suppress any errant output. Both of those things would need to be taken up with upstream. I filed https://github.com/rpm-software-management/rpmlint/issues/262.
*** Bug 1746785 has been marked as a duplicate of this bug. ***