09:07:17 #startmeeting Fully Automated Static Analysis of Fedora Packages 09:07:17 Meeting started Sat Aug 9 09:07:17 2014 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:07:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 09:07:22 #topic Fully Automated Static Analysis of Fedora Packages 09:07:40 talker: Kamil Dudka 09:08:12 currently available tools: gcc, cppcheck, clang, sparse, farma-c 09:09:09 static analysis means "analysis of software without executing it" 09:10:19 gcc taken seriously by upstream developers 09:10:30 but ignored by fedora maintainers 09:10:46 enforcing -Werror is a good way to fix it 09:11:18 gcc warnings difficult to proceed in automatic way 09:11:32 cppcheck is based on pattern matching 09:12:02 cppcheck can be run on sources 09:12:25 and also can be run per compilation unit 09:13:05 in the first case cppcheck reports issues in unused code (#ifdef WIN32) 09:13:26 in the later case cppcheck it is not easy to automate 09:13:41 clang is built on top of llvm 09:14:06 perl script scan-build runs clang during build transparently 09:14:52 html or plist format for the results 09:15:13 clang fails when analyzing some packages 09:15:43 summing up: we have tools 09:15:53 but no common format or interface 09:17:12 comment from audience: it should be run as a service + wall of shame 09:17:36 Q: is it good enough yet? 09:18:02 A: it is not yet, tools are actively developed and new versions bring better results 09:19:57 fully automated static analysis of SRPMs is implemented in Fedora by tool 'csmock' 09:23:29 it produces various errors from various tools (clang, cppcheck) 09:23:55 Q: would TAP output will be supported in order to integrate with Taskotron? 09:24:05 A: taskotron integration is on the plan 09:25:03 csmock can capture gcc warnings, change gcc warning level 09:25:22 it can check only downstream patches (--diff-patches) 09:25:40 or analyze upstream tarballs only 09:26:31 timeout can be set to get results in predictable time 09:26:51 there is also plugins support 09:27:14 csmock uses mock, so the environment is close to production 09:27:46 csmock also uses cswrap (compiler wrapper) 09:28:48 cswrap besides others translates relative path to absolute 09:29:06 results are proceeded by csdiff, csgrep or cshtml 09:29:27 csdiff can be used to match defects introduced by an update 09:29:44 csgrep can filter the list of defects by various criteria 09:29:51 cshtml produces html format 09:31:00 Q: how to detect moved code using csdiff? 09:31:17 A: we do not check line numbers, but only significant diagnostic messages 09:32:27 A: this heuristic is proven to work quite well right now 09:33:08 future plans are plugins, support more languages (python, java), and run csmock as a service 09:34:11 Q: are all SRPMs scanned? 09:34:51 A: the whole Fedora is scanned time to time but bugs not reported since it would be too much and people would ignore it 09:35:31 Q: would it be possible to integrate csdiff in bodhi? 09:35:52 A: yes, probably using taskotron 09:37:23 comment from audience: static analysis need quite a lot of resources, it will be challenge for taskotron 09:38:10 Q: filtering false possitives -- is it language specific? 09:38:20 A: no, it should work for every plugin 09:50:48 #endmeeting