Created attachment 1503274 [details] shell script for repro Description of problem: Version-Release number of selected component (if applicable): 1.7.0, now in rawhide after RHBZ-1632023 How reproducible: Always Steps to Reproduce: 1. Install coccinelle 2. run attached repro.sh 3. se warnings of "missing" files Actual results: $ ./repro.sh warning: Can't find macro file: /usr/bin/../lib/coccinelle/standard.h warning: Can't find default iso file: /usr/bin/../lib/coccinelle/standard.iso HANDLING: foo.c Hello World! Expected results: $ ./repro.sh init_defs_builtins: /usr/lib64/coccinelle/standard.h HANDLING: foo.c Hello World! Additional info: IIUC, upstream planned for spatch binary to live in COCCINELLE_HOME="/usr/lib64/coccinelle/", not in /bin. Instead the script/spatch.sh should be called, which sets COCCINELLE_HOME and then calls the binary which uses the env to find its standard library. I'm trying to get fc29 to have a working-out-of-the-box coccinelle 1.7.0 in fc29, with working python support (thanks to 1632023). It seems to have been broken in one way or another for a long time. Coccinelle is/should be used heavily in the kernel community where it is used to statically find bugs in code, some of which may have security implications. The kernel crows is notoriously curmudgeonly, so it's important to remove as much friction as possible in order to get people to use the tools available. So, please, let's fix this.
Created attachment 1503277 [details] works-for-me spec file - installs spatch bin in /usr/lib64/coccinelle/, and installs wrapper scripts scripts/spatch.sh as /usr/bin/spatch - Fix autotools version mismatch on fc29 (wants 1.15, complains of 1.16 being installed)
It's easier if you supply patches to the spec file. Anyway I have integrated that into the Rawhide spec and built something. https://koji.fedoraproject.org/koji/taskinfo?taskID=30734682
Fine, but what about fc29???
The package now fully works in Rawhide and you've checked that?
I didn't realize that's what you were asking for. You just closed the ticket without a comment. I'm attaching a third fix, as a patch against your most recent version. I built it on f29 and it works (I applied it as part of a local fedpkg clone of your repo). Please accept these changes. If you'd like me to test again once you queue a build, I'm glad to do so, but can only do so on f29 (which is what I run). Then, I would really like to see this pushed f29 updates, which is my goal here.
Created attachment 1503305 [details] Patch spec file, now at 1.0.7-3, cleanups and added python functionality test
To clarify, 1.0.7-2 works as well for me (when built on f29), but because you had to manually merge my spec file, some cleanups were required, hence the new patch , which hopefully involves just a "git am" for you.
OK please try this package which contains a version of your latest specfile patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=30737051 If this works I will backport to F29.
Created attachment 1503326 [details] Add missing env variable for python test to succeed
Getting closer. fedpkg local doesn't isolate the build, so the python test succeeded because I had 1.0.7-3 already installed. Fix attached. Rebuilt with fedpkg mock (on f29), installed and tested files with and without python support. All ok. There's a bunch of warnings during the install phase cpio: buffer.ml: Cannot stat: No such file or directory cpio: bundles/parmap/filename.ml: Cannot stat: No such file or directory cpio: bundles/parmap/list.ml: Cannot stat: No such file or directory cpio: bundles/parmap/printf.ml: Cannot stat: No such file or directory cpio: bundles/pyml/buffer.ml: Cannot stat: No such file or directory cpio: bundles/pyml/bytes.ml: Cannot stat: No such file or directory cpio: bundles/pyml/filename.ml: Cannot stat: No such file or directory cpio: bundles/pyml/hashtbl.ml: Cannot stat: No such file or directory cpio: bundles/pyml/list.ml: Cannot stat: No such file or directory cpio: bundles/pyml/printf.ml: Cannot stat: No such file or directory cpio: bundles/pyml/stdcompat__option.ml: Cannot stat: No such file or directory cpio: bundles/pyml/stdlib.ml: Cannot stat: No such file or directory cpio: bundles/pyml/string.ml: Cannot stat: No such file or directory cpio: bytes.ml: Cannot stat: No such file or directory cpio: filename.ml: Cannot stat: No such file or directory cpio: format.ml: Cannot stat: No such file or directory cpio: hashtbl.ml: Cannot stat: No such file or directory cpio: lexing.ml: Cannot stat: No such file or directory cpio: list.ml: Cannot stat: No such file or directory cpio: map.ml: Cannot stat: No such file or directory cpio: marshal.ml: Cannot stat: No such file or directory cpio: otherlibs/dynlink/natdynlink.ml: Cannot stat: No such file or directory cpio: parmap/parmap.ml: Cannot stat: No such file or directory cpio: parsing_c/lexer_c.ml: Cannot stat: No such file or directory cpio: parsing_cocci/lexer_cli.ml: Cannot stat: No such file or directory cpio: parsing_cocci/lexer_cocci.ml: Cannot stat: No such file or directory cpio: parsing_cocci/lexer_script.ml: Cannot stat: No such file or directory cpio: printf.ml: Cannot stat: No such file or directory cpio: pyml-current/py.ml: Cannot stat: No such file or directory cpio: pyml-current/pyutils.ml: Cannot stat: No such file or directory cpio: random.ml: Cannot stat: No such file or directory cpio: set.ml: Cannot stat: No such file or directory cpio: stdlib.ml: Cannot stat: No such file or directory cpio: str.ml: Cannot stat: No such file or directory cpio: string.ml: Cannot stat: No such file or directory cpio: tools/spgen/source/spgen_lexer.ml: Cannot stat: No such file or directory I think these have been there since forever, it doesn't seem to break anything, in particular rpmbuild doesn't find ant missing files for the %install. So, even unfixed, I think this is fully functional and a net improvement.
Created attachment 1503341 [details] Install log with (benign?) cpio warnings aboout missing files
Yes the cpio warnings are benign. They come from the RPM debuginfo generation step because it doesn't know how to find the source files from the OCaml library path (indeedsome of the sources files don't even exist). In any case it can be ignored. I have updated the PYTHONPATH logic (note I'd already fixed that in the -3) build. If there's nothing else then as far as I know it should work on Fedora 29?
Ah, so you did. Yes, I think we're good to go on fedora 29.
coccinelle-1.0.7-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-15cfaca5d4
coccinelle-1.0.7-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0cac07f63a
great, thanks.
coccinelle-1.0.7-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0cac07f63a
coccinelle-1.0.7-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-15cfaca5d4
bump. This is ready to be pushed from testing to updates.
coccinelle-1.0.7-4.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
coccinelle-1.0.7-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.