ksysguard is a KDE app for monitoring several aspects of a system, like load,
ram usage, network, hardware sensors etc... It also has support of monitoring
remote computers by running "ksysguardd" there, and communicating with it over
TCP or SSH.
That daemon is quite small and doesn't link against KDE libs but is needed on
each computer you want to monitor. (its a C application, only linking against
libsensors.so if available)
I don't want to emerge most of kde on all of my servers just to monitor their
current workload, so I've been copying the ksysguardd binary arround, which
worked quite fine, but its a hassle to keep up to date, esp. with different or
not existing lm_sensors libraries.
So a seperate ebuild for it would be nice, so one could just emerge the daemon
on a server to use it remotely (maybe even with a premade xinetd config
snippet for it, so you'd just have to enable it).
Steps to Reproduce:
as in "emerge ksysguard"?
that's already in portage.
(In reply to comment #1)
> as in "emerge ksysguard"?
> that's already in portage.
"emerge ksysguard" installs the graphical monitor as well as the monitoring
daemon. (its just a split ebuild for the kde-base package)
So it still needs X11 Libs, QT, kde-libs, ... which I'd like to avoid.
maybe one could modify the ksysguard ebuild to build the daemon only when
started with USE=-X -kde ..., but I'd guess that would make it impossible to
I, too, would love this!
Can anyone suggest how to build just the daemon?
(In reply to comment #3)
> I, too, would love this!
> Can anyone suggest how to build just the daemon?
You need to strip the build scripts from all kde related checks, but still let it create config.h. Personally I'm not interested to sort that out and to maintain an extra set of build scripts, but if someone does commit himself (long term) to do so, splitting the ebuild would be possible.
On the other hand, while having ksysguardd separated is probably nice to monitor a limited amount of boxes, it's neither needed for single workstations, nor suited on a larger scale, so I'd say "copy by hand" is inconvenient, but should suffice.
00:58:31 <+jakub> so objections to marking this UPSTREAM? Bug 100704
00:58:32 <+jeeves> jakub: https://bugs.gentoo.org/100704 enh, P4, All, email@example.com->firstname.lastname@example.org, NEW, pending, Wish:
seperate ksysguardd ebuild
00:58:43 <+jakub> really not our business
00:59:03 <+masterdriverz> jakub: feel free
OK, feel free to reopen once upstream folks have made this a configure option; until then, sorry but we don't have time to hack the build system and maintain such stuff. Thanks.