Coccinelle isn't able to run python scripts. The error message is: "Python error: No module named coccilib.elems" Version-Release number: $ rpm -qa | grep cocci coccinelle-1.0.6-14.fc27.x86_64 $ spatch --version spatch version 1.0.6 compiled with OCaml version 4.05.0 Flags passed to the configure script: --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-release=yes --with-python=/usr/bin/python3 --with-menhir=/usr/bin/menhir Python scripting support: yes Syntax of regular expresssions: PCRE Steps to Reproduce: [acooks@t460s linux]$ cd ~/linux # linux kernel source directory [acooks@t460s linux]$ make coccicheck MODE=report V=1 /bin/sh ./scripts/coccicheck Please check for false positives in the output before submitting a patch. When using "patch" mode, carefully review the patch before submitting it. Processing alloc_cast.cocci with option(s) " --no-includes --include-headers" Message example to submit a patch: Remove casting the values returned by memory allocation functions like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc. The semantic patch that makes this report is available in scripts/coccinelle/api/alloc/alloc_cast.cocci. More information about semantic patching is available at http://coccinelle.lip6.fr/ Semantic patch information: This makes an effort to find cases of casting of values returned by kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc, kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes the casting as it is not required. The result in the patch case may need some reformatting. Running (4 in parallel): /usr/bin/spatch -D report --no-show-diff --very-quiet --cocci-file ./scripts/coccinelle/api/alloc/alloc_cast.cocci --no-includes --include-headers --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi --include ./include/linux/kconfig.h --jobs 4 --chunksize 1 coccicheck failed [acooks@t460s linux]$ /usr/bin/spatch -D report --no-show-diff --very-quiet --cocci-file ./scripts/coccinelle/api/alloc/alloc_cast.cocci --no-includes --include-headers --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi --include ./include/linux/kconfig.h --jobs 4 --chunksize 1 Python error: No module named coccilib.elems [acooks@t460s linux]$ /usr/bin/spatch -D report --no-show-diff --very-quiet --cocci-file ./scripts/coccinelle/api/alloc/alloc_cast.cocci --no-includes --include-headers --dir . -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi --include ./include/linux/kconfig.h --jobs 4 --chunksize 1 --debug init_defs_builtins: /usr/lib64/coccinelle/standard.h ----------------------------------------------------------------------- processing semantic patch file: ./scripts/coccinelle/api/alloc/alloc_cast.cocci with isos from: /usr/lib64/coccinelle/standard.iso ----------------------------------------------------------------------- /// Remove casting the values returned by memory allocation functions /// like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc. /// //# This makes an effort to find cases of casting of values returned by //# kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc, //# kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes //# the casting as it is not required. The result in the patch case may //#need some reformatting. // // Confidence: High // Copyright: 2014, Himangi Saraogi GPLv2. // Comments: // Options: --no-includes --include-headers // virtual context virtual patch virtual org virtual report //---------------------------------------------------------- // For context mode //---------------------------------------------------------- @depends on context@ type T; @@ * (T *) \(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\| kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...) //---------------------------------------------------------- // For patch mode //---------------------------------------------------------- @depends on patch@ type T; @@ - (T *) (\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\| kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...)) //---------------------------------------------------------- // For org and report mode //---------------------------------------------------------- @r depends on org || report@ type T; position p; @@ (T@p *)\(kmalloc\|kzalloc\|kcalloc\|kmem_cache_alloc\|kmem_cache_zalloc\| kmem_cache_alloc_node\|kmalloc_node\|kzalloc_node\)(...) @script:python depends on org@ p << r.p; t << r.T; @@ coccilib.org.print_safe_todo(p[0], t) @script:python depends on report@ p << r.p; t << r.T; @@ msg="WARNING: casting value returned by memory allocation function to (%s *) is useless." % (t) coccilib.report.print_report(p[0], msg) ----------------------------------------------------------------------- script = ----------------------------------------------------------------------- dependencies for script satisfied: binding in = [] Initializing python %! Python error: No module named coccilib.elems
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.