Description: This is a set of scripts to popup a kdialog message about the currently compiling package(s).
ikgenlop.sh is the more advanced one. It uses the inotify API to watch emerge.log and inform you when something new happens.
It can be run from KDE autostart, or xinitrc or whatever, no need for cron.
The simpler one, kgenlop.sh script will just call genlop and pop up a message when it has something to say.
You can run it as a cron job e.g. like this: [indent]*/5 * * * * /home/user/bin/kgenlop.sh 2>/dev/null[/indent]
You need app-portage/genlop and of course kde-base/kdialog installed.
The included Makefile will copy the script to ~/bin and set up a symlink in the KDE autostart folder (~/.kde4/Autostart). Do not run make if you don't want this.Last changelog:
1.6: mostly cosmetic changes, typos etc. changed calls to inotify to only report on rw changes, not only ro so other apps don't cause a storm of popups. 1.5: moved settings to ~/.ikgenloprc, create this file on first run, introduce a PID file and use it to detect multiple instances. 1.4: added a couple of tunables to steer verbosity. Thanks to Krog for testing. 1.3: many more features for iknotify to make it more annoying 1.2: many changes, use a combination if inotify and tail to push status updates to kdialog. Please excuse the brute-force usage of awk and friends. Cleanup will follow later. 1.1: Added inotify based version after suggestion from user Krog. 1.0: first revision
1.5 sometimes crashes with this error:
ikgenlop-1.5.sh: line 232: USER_FREQ * : syntax error: operand expected (error token is "* ")
end.
1.4 seems unaffected
Well I just found out that the install location for the autostart version is wrong.
It should be ~/.kde4/Autostart instead of ~/.kde4/share/autostart.
That should be fixed in the 1.5 version, coming Real Soon Now...
I did'nt tryed the installation, just tuned the script and manually set as autostart in systemsettings.
In the future release there will be other changes/improvements?
I'm always open to suggestions!
Probably the next step should be an ebuild.
But before that it needs to be possible to be installed system-wide (right now I assume everything will be in $HOME) and I still need to figure out where to put stuff for that.
maybe putting the script in /etc/xdg/autostart ? I can't try now but please try it :-)
also looking the script it seems that it will only work in :0 but sometimes I have more than one session active
Now it's amazing!
Thanks for the new version :-)
I like to set FREQ=0.
Now, it could be good to filter what message to show... for example, the uninstall of the old package afer an upgrade is usless to show and adds too much messages.
Again thanks for your job :-)
tested WITH -t ${FREQUENCY}:
many messages from a single package BUT small packages that require just some couple of seconds (i'm on a core i7 cpu!) are emerged without message
tested WITHOUT -t ${FREQUENCY}:
it's compiling, but no messages until now and it compiled 3 packages now...
p.s. one of the two links is not working... the old one
The problem with small packages is that genlop ONLY reports something when the ebuild ist actually compiling.
Dependency computation, configure, merge etc. and packages which don't compile anything are ignored.
I'll play around with it more, maybe I can find a better way.
Ant feedback is appreciated ;)
running in the cron way is less good of my idea because if (example) you emerge something very long (openoffice, for example) you will see many messages telling exactly the same thing. With a tail/grep stuff you get only the new messages.
Try the new ikgenlop.sh maybe you like the behaviour more.
You can set FREQUENCY to a higher value (in seconds) if you want less messages.
If you want just one message per compile you can remove -t ${FREQUENCY} from the inotifywait line.
I find having multiple messages for very long compiles useful because it tells me how long I have to wait - but tastes are different :) ...
Thanks for your feedback.
It's a nice idea.
But maybe it's not good to automatically run this script continuously...
I wonder if it is not possible to make it automatic?
perhaps using "tail -F /var/log/emerge.log|grep emerge" as a source of information...
there was a plasmoid that was showing this information as a box... perhaps merging that thing with the notify system...
of course i'm not a programmer, it's just an idea :-)
You do have a point.
I don't see however how running tail | grep is any less "running continuously" than a cron job is. At least the latter is automatic and tunable.
I will try to cook up an inotify-based solution which avoids the cron thing and only fires a notification wen stuff is really happening.
Ratings & Comments
20 Comments
1.5 sometimes crashes with this error: ikgenlop-1.5.sh: line 232: USER_FREQ * : syntax error: operand expected (error token is "* ") end. 1.4 seems unaffected
Ooops, stupid typo. Try replacing the affected line with this: # back off a bit FREQ=$(( USER_FREQ * FREQ_BACKOFF ))
Well I just found out that the install location for the autostart version is wrong. It should be ~/.kde4/Autostart instead of ~/.kde4/share/autostart. That should be fixed in the 1.5 version, coming Real Soon Now...
I did'nt tryed the installation, just tuned the script and manually set as autostart in systemsettings. In the future release there will be other changes/improvements?
I'm always open to suggestions! Probably the next step should be an ebuild. But before that it needs to be possible to be installed system-wide (right now I assume everything will be in $HOME) and I still need to figure out where to put stuff for that.
maybe putting the script in /etc/xdg/autostart ? I can't try now but please try it :-) also looking the script it seems that it will only work in :0 but sometimes I have more than one session active
thanks to you :-)
Now it's amazing! Thanks for the new version :-) I like to set FREQ=0. Now, it could be good to filter what message to show... for example, the uninstall of the old package afer an upgrade is usless to show and adds too much messages. Again thanks for your job :-)
Glad you like it and thanks for testing. Here's 1.4 where you can configure to your hearts content!
tested WITH -t ${FREQUENCY}: many messages from a single package BUT small packages that require just some couple of seconds (i'm on a core i7 cpu!) are emerged without message tested WITHOUT -t ${FREQUENCY}: it's compiling, but no messages until now and it compiled 3 packages now... p.s. one of the two links is not working... the old one
The problem with small packages is that genlop ONLY reports something when the ebuild ist actually compiling. Dependency computation, configure, merge etc. and packages which don't compile anything are ignored. I'll play around with it more, maybe I can find a better way. Ant feedback is appreciated ;)
Hi, ikgenlop link is not working. The link is empty (http:///). Can you please fix it? Thanks!
Sorry, it's my first submission, I'm no all too familiar with the kde-look.org interface. Removed the dead link, try the tarball.
maybe you can at first add an "if" to the script: if emerge is running do...
running in the cron way is less good of my idea because if (example) you emerge something very long (openoffice, for example) you will see many messages telling exactly the same thing. With a tail/grep stuff you get only the new messages.
Try the new ikgenlop.sh maybe you like the behaviour more. You can set FREQUENCY to a higher value (in seconds) if you want less messages. If you want just one message per compile you can remove -t ${FREQUENCY} from the inotifywait line. I find having multiple messages for very long compiles useful because it tells me how long I have to wait - but tastes are different :) ... Thanks for your feedback.
It's a nice idea. But maybe it's not good to automatically run this script continuously... I wonder if it is not possible to make it automatic? perhaps using "tail -F /var/log/emerge.log|grep emerge" as a source of information... there was a plasmoid that was showing this information as a box... perhaps merging that thing with the notify system... of course i'm not a programmer, it's just an idea :-)
You do have a point. I don't see however how running tail | grep is any less "running continuously" than a cron job is. At least the latter is automatic and tunable. I will try to cook up an inotify-based solution which avoids the cron thing and only fires a notification wen stuff is really happening.
can you post a screenshot please? :-)
Sure. Done!