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). Reproducible: Always 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 inherit "kde-meta".
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, e.bachmann@xebec.de->kde@gentoo.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.