The cirros image was rebuilt against the 3.13.0-83 kernel, drivers e1000e, igbvf...

[packages/trusty/cirros-testvm.git] / cirros-testvm / src-cirros / buildroot-2015.05 / package / latencytop / Config.in

diff --git a/cirros-testvm/src-cirros/buildroot-2015.05/package/latencytop/Config.in b/cirros-testvm/src-cirros/buildroot-2015.05/package/latencytop/Config.in
new file mode 100644 (file)
index 0000000..b54ef05
--- /dev/null
+++ b/cirros-testvm/src-cirros/buildroot-2015.05/package/latencytop/Config.in
@@ -0,0 +1,26 @@
+config BR2_PACKAGE_LATENCYTOP
+       bool "latencytop"
+       depends on BR2_USE_WCHAR # libglib2
+       depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2
+       depends on BR2_USE_MMU # libglib2
+       select BR2_PACKAGE_NCURSES
+       select BR2_PACKAGE_LIBGLIB2
+       help
+         There are many types and causes of latency. LatencyTOP
+         focuses on the type of latency that causes skips in audio,
+         stutters in your desktop experience or that overloads your
+         server (while you have plenty of CPU power left).
+
+         LatencyTOP focuses on the cases where the applications want
+         to run and execute useful code, but there's some resource
+         that's not currently available (and the kernel then blocks
+         the process). This is done both on a system level and on a
+         per process level, so that you can see what's happening to
+         the system, and which process is suffering and/or causing
+         the delays.
+
+         http://www.latencytop.org
+
+comment "latencytop needs a toolchain w/ wchar, threads"
+       depends on BR2_USE_MMU
+       depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS