This is an ebuild for the icecream monitor that goes with sys-devel/icecream-0.7.3a. Previously this was included with the icecream package but has now been separated out. The ebuild for sys-devel/icecream-0.7.3a is available here: https://bugs.gentoo.org/show_bug.cgi?id=139352
Created attachment 94065 [details] icemon-0.1.ebuild Not sure where the original ebuild went to, but here is an updated one. This should possibly be assigned to cluster@gentoo.org, it is a tiny package and used to be part of the sys-devel/icecream package. It was only separated out for development purposes, and contains very few changes compared to the version that is included in portage already (it was installed with sys-devel/icecream via the kde USE flag).
I'm confused about this. Why is the tarball on your own server? I was expecting something from suse.com again...
(In reply to comment #2) > I'm confused about this. Why is the tarball on your own server? I was expecting > something from suse.com again... > Because the tarballs at ftp://ftp.suse.com/pub/projects/icecream don't have version numbers so we can't see when they change. Current version is 1.0, just rename the ebuild accordingly.
(In reply to comment #3) > (In reply to comment #2) > > I'm confused about this. Why is the tarball on your own server? I was expecting > > something from suse.com again... > > > > Because the tarballs at ftp://ftp.suse.com/pub/projects/icecream don't have > version numbers so we can't see when they change. Could you get in touch with upstream and ask them to version the tarballs? Thanks!
I've just wrote to Stephan Kulow: --------- To: coolo ]AT[ suse ]DOT[ de Hi, I hope, you're the right one to contact concerning icemon development. As mentioned in Gentoo bug#139432 (http://bugs.gentoo.org/show_bug.cgi?id=139432), the icemon tar.bz provided at ftp://ftp.suse.com/pub/projects/icecream/ should have a version number to be able to provide a "clean" ebuild for it, because changing the content of the .tar.bz without changing it's name corrupts Gentoo's checksum which is kept with every ebuild, to see whether the source files are still consistent. Thank you & Regards, Elias P. --------- Let's wait and see what happens....
Answer from Stephan Kulow: ------ I can do that for the next releases Greetings, Stephan ------ /me hopes that the next release is coming soon...
Created attachment 103126 [details] New icemon ebuild Changed the depencies: - icemon doesn't need icecream to be installed. - icemon shouldn't be installed, when icemon is still provided by a older icecream release. As there is still no icemon release that has a version number, this ebuild is just a "reminder" what needs to be done in the final ebuild.
Created attachment 157675 [details] new ebuild
Created attachment 164825 [details] Updated ebuild Changes kde-base/kdelibs dependency to kde-base/kdelibs:3.5. kde-4 does not seem to work, although I might be missing something.
I installed icemon-1.0-r1 (and previously icemon-0.1). It installs fine but does not show any activity at all even though running top shows that icecream is doing work on the remote nodes. This was with icecream-0.8.X and now with the latest.
(In reply to comment #10) > I installed icemon-1.0-r1 (and previously icemon-0.1). It installs fine but > does not show any activity at all even though running top shows that icecream > is doing work on the remote nodes. This was with icecream-0.8.X and now with > the latest. > I just tried icemon (1.0-r1 as well) and had the same problem. I found the following note on SUSE's Icecream page (http://en.opensuse.org/Icecream): "Note that the SuSEfirewall2 on SUSE < 9.1 got some problems configuring broadcast. So you might need the -s option for the daemon in any case there. If the monitor can't find the scheduler, use USE_SCHEDULER=<host> icemon (or send me a patch :)" I figured "why not try it". Voila... it worked!!! I noticed when I ran it, the following lines were printed in the terminal prior to the start of polling, which weren't there before: broadcast <my ethernet device> <my bcast address> scheduler is on <my hostname>:8765 (net ) QSocketNotifier: Invalid socket specified QSocketNotifier: Internal error So yes, something seems wrong with how it detects the scheduler hostname, which is probably a byproduct of the broadcast woes mentioned by SUSE. It also seems to be failing to detect which Icecream network it's running on (note the "(net )" on the second line. Looks like icemon is getting a blank or a null value by mistake.) But is there also a problem with how it uses QSocketNotifier??? Or are these one and the same bug? Too bad I'm not a coder or I'd look into them more. :-(
Thanks that workaround fixed the issue for me exactly how you described. The display works great and I also get this output: ignoring localhost lo broadcast br0 192.168.1.255 scheduler is on 192.168.1.107:8765 (net ) QSocketNotifier: Invalid socket specified QSocketNotifier: Internal error ignoring localhost lo broadcast br0 192.168.1.255 Without USE_SCHEDULER=192.168.1.107 I get no output and the following in the console: ignoring localhost lo broadcast br0 192.168.1.255 scheduler is on 192.168.1.107:8765 (net ICECREAM) ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 scheduler is on 192.168.1.107:8765 (net ICECREAM) ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ignoring localhost lo broadcast br0 192.168.1.255 ...
Hmmm... I think we've gotten a bit off-topic. This bug report was originally created in order to provide the latest ebuild for icemon. Anyway, the current issue seems to be a known bug that needs to be fixed upstream. So should this bug be closed? Sorry... Bugzilla newbie here. I can't figure out how to do that. The only option is "Leave as NEW". -Curtis
(In reply to comment #13) AFAIK, the current upstream version of icemon is for KDE4, which works fine with the portage version of icecream, but for which there is no ebuild (or tarball).
(In reply to comment #11) > (In reply to comment #10) > > I installed icemon-1.0-r1 (and previously icemon-0.1). It installs fine but > > does not show any activity at all even though running top shows that icecream > > is doing work on the remote nodes. This was with icecream-0.8.X and now with > > the latest. patch against old iceream can be found at http://bugs.gentoo.org/show_bug.cgi?id=261429 wich fixes this issue. But would be an working ebuild of current icemon against KDE4
Ups i ment. Better would be an new ebuild against KDE4. Sorry too late that day :-(
if you guys are interested in icemon you can see the build instruction here http://www.linuxintro.org/wiki/Icecream My instruction: svn co https://svn.kde.org/home/kde/trunk/playground/devtools/icemon cd icemon (export CFLAGS, CXXFLAGS) cmake . make && make install If you want CFLAGS then export them to the environment before running cmake. Remember to emerge kdebase-meta first. I think there should be an icemon-9999.ebuild somewhere (overlay) to simplify the build. (sorry I'm not good at writing ebuild)
I added the snapshot from git to cvs as dev-util/icemon. It seems to kinda work when testing on suse nodes so have fun. Note if you have issues rather contact upstream on github so they can track and fix your issues as the pkg is really straight forward.
