Bug 1544204
Summary: | spatch can't run python scripts | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew Cooks <acooks> | ||||||
Component: | coccinelle | Assignee: | Richard W.M. Jones <rjones> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 27 | CC: | g.fhnrunznrqeqf, jfrie, jglisse, marc.c.dionne, rjones | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2018-11-08 08:50:47 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Andrew Cooks
2018-02-11 09:23:28 UTC
Possible duplicate of bug 1416323? I have no idea about this, it may be better to ask on the upstream coccinelle list. Could be a dup. It looks similar to the python version thing, but I reported this as a new bug, because the coccinelle spec file alleges that the python2->python3 conversion has already been done. I'm looking at the spec file changelog at https://koji.fedoraproject.org/koji/buildinfo?buildID=953438 The python libraries are installed for python3, but my default python was still version 2. I tried switching the default system python to python3, as described at https://linuxconfig.org/how-to-switch-between-python-versions-on-fedora-linux with the command: $ sudo alternatives --install /usr/bin/python python /usr/bin/python3.6 2 Now I get: Py.run_command: unable to read the result of 'python --version' Closing this as a dup of bug 1416323. *** This bug has been marked as a duplicate of bug 1416323 *** Created attachment 1433998 [details]
f27 coccinelle python patch
With this patch i am able to use f27 cocinnelle with python inside semantic patch
This is not same bug as bug 1416323. Patch in comment 3 is against fedpkg clone coccinelle on the f27 branch What did upstream think about the patch in comment 3? Unfortunately python2 outputs the version on stderr while python3 outputs it on stdout, so I very much doubt upstream would have accepted such a patch... And that's not even accounting for the fact that something similar to that patch was fixed upstream by this commit[1] in 2016, two weeks after the 1.0.6 release (!) (that commit wouldn't fix the need to set default to python3 though, I'm not sure if this has been fixed elsewhere) There is now an 1.0.7 version out that should work, as far as this bug is concerned, so it should be just a matter of upgrading now... Except that lip6 hasn't made a release tar at the download url of the spec yet (nor on their download page), and I cannot seem to build from their git right now (there's a problem with the pyml bundle?) I don't have the time to dig much further here, but I'd think that's the way to go; I'll keep trying to build this a bit and submit a new specfile patch for the update if nobody else makes it before me. [1] https://github.com/coccinelle/coccinelle/commit/c8025ac6bd9874663f4445288056702c424db8cb Created attachment 1458584 [details]
update spec file to 1.0.7 release
Ok, so it turns out the coccinelle-1.0.6.tgz contains a bootstrapped dllpyml_stubs.so / libpyml_stubs.a lib that is necessary with the build.
As that file is not removed by make clean I assume upstream originally just built it with the module externally available (through e.g. opam) and then never really thought about it... I'm curious how the current version builds on other archs, maybe just having the file present is enough to bootstrap it as it is not used by the first programs that require it?...
I've tried creating an empty object file where it is expected and this appears to work around the issue:
cc -x c -o bundles/pyml/pyml-current/libpyml_stubs.a -c - < /dev/null
Well, that settles it; there were a couple more minor changes needed to the spec but I've attached the diff to the current (coccinelle-1.0.6-20.fc29) spec file.
The tar is not available at the Source url given, instead I checked out the release commit from the git, ran autogen and made a tar of the result as per common practice.
I can confirm that:
- the resulting rpm fixes this bug
- one does not need to change the system python default version either
Now I'm happy with my "workaround" I'll let you do what you want with it :)
thanks,
--
Dominique Martinet
I've hit the same issue, and upgrading to 1.0.7 fixes the problem for me as well. Requested the package be updated to 1.0.7 in BZ-1632023. I believe this can be closed now (BZ1632023), though the install is still broken in other ways (BZ-1647715), and the update is only in rawhide right now. Closing per comment 10. |