KernelShark is a front end visualisation for trace-cmd data.
trace-cmd reporting can be extremely verbose making it difficult to analyse. kernelshark visualises the data so that it can be filtered or trimmed.
- Devel package for openSUSE:Factory
-
1
derived packages
- Links to openSUSE:Factory / kernelshark
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout devel:tools/kernelshark && cd $_ - Create Badge
Refresh
Refresh
Source Files
| Filename | Size | Changed |
|---|---|---|
|
0001-kernel-shark-Build-missed_event-as-GUI-plugin |
0000001128 1.1 KB | |
| _link | 0000000124 124 Bytes | |
| _service | 0000000683 683 Bytes | |
| kernelshark-2.1.1.obscpio | 0005406733 5.16 MB | |
| kernelshark.changes | 0000003536 3.45 KB | |
| kernelshark.obsinfo | 0000000100 100 Bytes | |
| kernelshark.spec | 0000003936 3.84 KB |
Revision 10 (latest revision is 18)
Mel Gorman (mgorman)
accepted
request 1003572
from
Daniel Wagner (wagi)
(revision 10)
- Update to latest upstream version (2.1.1) - Drop 0001-trace-cmd-fix-multiple-definition-compiler-errors.patch - Drop cmake-link-glut-libraries.patch - Drop makefile-bash.patch - Drop makefile-lib64.patch - Drop kernelshark-make-fontheight.patch
Comments 4
Running kernelshark-v1.0-2.d_t.1.x86_64, selecting tools/record I get: ERROR: "Record is currently not supported. Install \"pkexec\" and then do:<br> cd build <br> sudo ./cmake_uninstall.sh <br> ./cmake_clean.sh <br> cmake .. <br> make <br> sudo make install"
It seems this upstream bug covers the same issue: https://bugzilla.kernel.org/show_bug.cgi?id=204475
The polkit integration was left out as the record operation requires root privilege gather the trace. There is a non-zero risk that a privilege escalation could be implemented via kernelshark although hard to imagine given local admin access would still be required. Given that kernelshark is a visualisation tool, I suggest gathering the trace with trace-cmd and then loading it with kernelshark.
Am I understanding correctly that using _service in the way it is done here, requires obs-service-set_version on the build platform? And since that appears not to be available, e.g., on SLE15, SLE15SP1, and SLE15SP2, the build does not work there?
While, on the other hand, using a "tar_scm" service, and run it manually for fetching the tarball (which will then be committed to the repository) would work there too?
Yep that would work - and yes you are right obs-service-set_version is the reason for build failure on SLE.