lnie <l...@redhat.com> changed:
What |Removed |Added
--- Comment #7 from lnie <l...@redhat.com> ---
I have contacted the upstream maintainer,and here is what he said about the
#!/usr/bin/python and /usr/bin/env python:
There are indeed a number of files that are libraries, and at the same time
provide some level of "script" (aka command-line utilities) capabilities...
I have modified the code as his suggest and sent a PR in upstream
>I notice that you're disabling RPM #! mangling (%global
>__brp_mangle_shebangs_exclude_from)but it's unclear why you're doing that?
The point here is that these scripts will be copied to guest VM instances,
which may be running Operating Systems that can haveeither Python 2 or Python
3, but it's impossible to know for sure at packaging time.
> rpmlint complains that there are C/C++ source files in the package, is there
> a reason for this?
Here is his reply:
The base issue is that some functionality could not be implemented in pure
Python, but still the packaging was kept "noarch" and relying on Avocado-VT's
own handling of source code compilation. Ideally, this
should be done at build time, in either or both setup.py and the spec file.For
instance, virttest/passfd.py has code to compile passfd.c "on the go". This is
for historical reasons, but it should probably be done on setup.py instead.
Also notice that in the specific case of passfd.c, this is only required on
Python 2 (because of a Python 2 limitation).
For other files, such as finish.cpp, I expect that these days it could be
replaced by some Windows script that would not need a previous compilation.
This is probably also an upstream-able issue.
Anyway,I was told that they are used by some special cases which test windows
guest. Those executable files in those folders are installed in windows guest
for some special purpose,
maybe I can remove it in Pagure(I have created a mirror of avocado-vt project
in Pagure) if needed.
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
package-review mailing list -- firstname.lastname@example.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines