https://bugzilla.redhat.com/show_bug.cgi?id=1578238 Bug ID: 1578238 Summary: Review Request: python-scan-build - A Clang scan-build reimplementation in Python Product: Fedora Version: rawhide Component: Package Review Assignee: nobody@xxxxxxxxxxxxxxxxx Reporter: evan@xxxxxxxxxxxx QA Contact: extras-qa@xxxxxxxxxxxxxxxxx CC: package-review@xxxxxxxxxxxxxxxxxxxxxxx Spec URL: https://copr-be.cloud.fedoraproject.org/results/eklitzke/python-scan-build/fedora-rawhide-x86_64/00754183-python-scan-build/scan-build.spec SRPM URL: https://copr-be.cloud.fedoraproject.org/results/eklitzke/python-scan-build/fedora-rawhide-x86_64/00754183-python-scan-build/python-scan-build-2.0.13-1.fc29.src.rpm This package is a little weird and I need some help on it. I've broken this down into a few parts below. scan-build binary ~~~~~~~~~~~~~~~~~~~~~~~ Right now there is an official utility called scan-build which is part of LLVM. One of the LLVM developers has been working on a Python reimplementation of scan-build, which also has some extra features. This is likely to become the official scan-build implementation in a future LLVM release. The existing scan-build implementation is packaged in the clang-analyzer package, which includes the following binaries: /usr/bin/scan-build /usr/bin/scan-view My new package includes the following binaries: /usr/bin/analyze-build /usr/bin/analyze-c++ /usr/bin/analyze-cc /usr/bin/intercept-build /usr/bin/intercept-c++ /usr/bin/intercept-cc /usr/bin/scan-build As you can see there are new (and useful!) binaries in this Python implementation. However, I will need to rename the /usr/bin/scan-build to avoid conflicting with clang-analyzer. I'm open to suggestions on how to handle this. License ~~~~~~~~~~~~~~ The license file used by this project is the same as LLVM, which is a custom NCSA-like license. I looked at the llvm source package, and they just declare the license there to be NCSA, so I did the same. The actual license can be found here: https://github.com/rizsotto/scan-build/blob/master/LICENSE.txt noarch ~~~~~~~~~~~~~~ pyp2rpm thought this was a binary package because the setup.py file says it's not zip-safe. Actually it works in kind of a strange way: the package includes a file named ear.c, and the intercept-build binary compiles this on-the-fly when wrapping builds. The ear.c file isn't actually built by setup.py. I changed the spec file to be noarch which I think is correct, but I would like someone to double check this. My FAS username: eklitzke -- 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 -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
