Bug 10533 - MythTv, Homebrew PVR project for analog TV cards' ebuild
|
Bug#:
10533
|
Product: Gentoo Linux
|
Version: 1.4_rc1
|
Platform: All
|
|
OS/Version: All
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: seemant@gentoo.org
|
Reported By: javier-ml-gentoo@marcet.info
|
|
Component: Applications
|
|
|
URL:
http://www.mythtv.org
|
|
Summary: MythTv, Homebrew PVR project for analog TV cards' ebuild
|
|
Keywords: EBUILD
|
|
Status Whiteboard:
|
|
Opened: 2002-11-10 11:36 0000
|
New ebuild for MythTV, a very nice suite to watch, record and archive shows
from analog sources.
It's not very well tested, indeed I still have a problem with the MySQL database.
Furthermore, one of the dependencies is xmltv, which I commit on another bug.
Xmltv is a backend to grab programming info in xmltv format for mythtv to use.
I have just finished the ebuild for it, a few things sure need polishing. But most
important is that I can't really test its funcionality since I couldn't find any
provider with Spanish TV listings in xmltv format at the moment.
Any help and testing from people from the US, UK, Germany or any other directly
supported country would be nice :)
I see the name's been lost in the attachment.
It's mythtv-0.7.ebuild
Nice, I was working on a ebuild for 0.6 a few days ago, but didn't finish. You
going to make ones for MythMusic and the others?
I get this when its installing:
make[1]: Entering directory `/var/tmp/portage/mythtv-0.7/work/mythtv-0.7/themes'
cp -f -pR "blue" "/var/tmp/portage/mythtv-0.7/image//usr/share/mythtv/themes/"
strip "/var/tmp/portage/mythtv-0.7/image//usr/share/mythtv/themes/"
strip: /var/tmp/portage/mythtv-0.7/image//usr/share/mythtv/themes/: Is a directory
make[1]: *** [install_themes] Error 1
make[1]: Leaving directory `/var/tmp/portage/mythtv-0.7/work/mythtv-0.7/themes'
It continues on, and the ebuild finished, but it doesn't install the rest of the
themes directory. If I remove lines 122, 124, 126, and 128 from themes/Makefile
it installs properly.
And instead of putting setup in /usr/share/mythtv, would putting it in /usr/bin/
with the rest of the executibles be better? It could be called mythsetup.
Thanks for the ebuild! I haven't tested it yet, but I saw that some
dependancies
were missing when reading the ebuild... You should also depend on:
media-libs/flac
media-libs/libvorbis
media-libs/libcdaudio
media-sound/cdparanoia
media-sound/mad
Please grab the updated and fixed xmltv ebuild, which should fix some problems
within MythTV.
As I said on bug #10536, it seems to work now but I haven't found xmltv info
providers of Spanish TV channels.
Also MythTV works better with a computer for its own, which I do not have now.
I wanted to use as I do with VDR (for DigitalVideoBroadcasting TV), which lets
you use it as a a daemon in the background while you continue to use the
computer. MythTV is also quite slow for that, as some Gentoo users told me by
e-mail.
There's at least one other project going on with which you can use the
dual-head
cappability of at least the Matrox G400, so that you have in the first head
your
desktop, and on the second head, the TV output. It doesn't let you record shows
yet, though, and it's written in python which I don't know if it's somewhat
slow
for the task...
Maybe the best route is finally integrating an analog_TV->PES to integrate in
VDR.
Created an attachment (id=9860) [details]
upgraded and cleaned mythtv ebuild (now with more fiber)
This ebuild is an update to MythTV 0.8. This one also comes with an rc script
for mythbackend (will be posted shortly).
I also made ebuilds for MythGallery, MythMusic, and MythWeather which I'll post
as separate bugs. (I'm still working on MythVideo, MythGame, and MythWeb).
Created an attachment (id=9861) [details]
rc script for mythbackend
Place this in mythtv/files for the ebuild to work (ebuild installs this as
/etc/init.d/mythbackend). This also has an optional conf file which goes into
/etc/conf.d (see below).
man, just when I go and make ebuilds for myth* someone beats me to it by a few
hours. This happened for the last 2 releases too. Oh well...I have a cron
script that I wrote that you can add to you ebuild to update the db, I'll
attach it.
I'd like to help in the bug squashing process but when i do an 'emerge -s myth'
i get nothing. accept keywords are x86. am i doing something wrong?
(yes, i've emerge sycned within the last 5 minutes)
added MythGame bug 18276 and MythVideo bug 18275.
to comment 13: these ebuilds aren't in portage yet, so you have to download the attatchments and put them in your portage dir or portage overlay dir manualy. When they do make it into portage they will probably be ~x86 for a while too.
oh and while I'm thinking about this...perhaps /usr/share isn't the best place
for the config files for myth* since theres no config protection there, and
config files are usualy in /etc. I thought of this cuz all the installing and
reinstalling of the different ebuilds clobbered my configs.
I think mythtv will only look in /usr/share or $home for config files. $home
over rides
the ones is /usr/share. It may be good to run mythbackend as user mythtv and
drop
the config files in the /home/mythtv. This probabley is also more secure.
Thanks for
the help guys, I've been kinda busy lately.
Sorry, haven't checked my email in a few hours, so I'm going to reply to all
the things posted in the meantime...
Regarding the cronjob: I don't know if it is such a hot idea to add the cron
script during the ebuild because if you're installing for the first time, you
don't have a database yet (and may not have one for a while). How about a note
in pkg_postinstall() that tells the user to copy
/usr/share/mythtv/mythfilldatabase to /etc/cron.weekly?
Aside from this, I think the script should look like this:
#!/bin/bash
QTDIR=/usr/qt/3
/usr/bin/mythfilldatabase --quiet
Reguarding running as mythtv user: I'm all for this and actually thought of
this as well. I first wanted to get the new ebuilds done. I'll look to adding
runas support. Thanks for reminding me!
oh ya thats a good point about the cronjob. a pkg_postinstall() would be a
good idea.
Created an attachment (id=9958) [details]
new new ebuild
changes:
1) creates /var/{log,run}/mythtv and set nobody:nobody ownership
2) mythbackend now starts as nobody (may want to make this configurable
in the future
3) comes with a working example mythfilldatabase.cron script and a suggestion
in pkg_postinstall() as to where to copy it it
one note that probably needs to be added somewhere about running mythbackend
as nobody:
*the nobody user needs to be added to the audio and video groups*
Created an attachment (id=10172) [details]
a more flexible backend rc script
ok here's another (and hopefully last) backend rc script with the following
changes:
1) allow the start-as user to be configurable
2) change "need mysql" to "use mysql" so that database can be separated
to a different machine (as I have it now for mythweb -- to be posted
shortly)
Will "need net" affect dialup users? I don't know know much about the "use"
and "need", but you probabley should not force a dial up user to start his
link. The link only needs to be up when the database is being updated.
I think _a_ network connection is pretty much required: what if the database is
on a different machine? what if the backend machine is a standalone master that
frontends need to connect to? Besides, I think with RC_NET_STRICT_CHECKING="no"
being the default in /etc/conf.d/rc any network interface being up will satisfy
this depend. Also, mysql itself has a "need net", so if you have the database
on the same machine, networking will be started for you, otherwise you will
_have_ to have networking enabled to allow the backend connect to the db.
I don't actually all the init dependency checking. I had a flaky dhcp server
which 2 out of 3 times would fail to give me a lease. I had to manually start
all the services once I got the lease. Just my experience no big deal. Maybe
zapping the log everytime it is started could be made optional. Probably you
shouldn't normally zap the log on startup but then in this case there is not a
lot of usefull info logged anyway.
The other thing is an ebuild is meant to run and install. Any setup needs to
be done after installation and not part of the ebuild process. I don't think
we are allowed to do this in and ebuild doexe "${S}/setup/setup"
the problem is that mythbackend puts some really funky permissions on the log
file (i.e.
doesn't make it writeable) when it first creates it. so that the next time you
go to start
it, it fails with "can't open log file" error. this just works around that.
with regards to "doexe ${S}/setup/setup".... I think we're on a different page
with this.
doexe doesn't actually run it -- it installs it and sets proper permissions.
from ebuild(5):
doexe <executable> [list of more executables]
Installs a executable or a list of executable into
EXEDESTTREE. This function uses install(1).
I have had a lot of trouble with the rc-script, it doesn't seem to launch
mythbackend on my machine. After a reboot I manually have to start it. It
thinks it is started since it I try to stop it, it complains with an error
"start-stop-daemon: warning: failed to kill 3357: no such process". Other than
that, ebuild and conf file worked ok.
When nobody was created it wasn't put into groups audio or video, I don't know
if that was a feature or a bug. Could all of the setup be added to the ebuild
as "ebuild mythtv.ebuild config".
The other problem I had and I don't know if this could/should be added
anywhere, I had old permissions lying around that I needed to wipe out before I
could run it, none of the config for mysql would take care of it and I thought
it could be added here to avoid confusion.
If mythbackend seg faults you will get the problem you describe. You can reset
things by doing /etc/init.d/mythbackend zap. rc-update add mythbackend default
should make it start automatically at boot.
There are different ways you can run mythbackend. Some people may not want to
run it as a daemon and in that case there is no need to modify the group file.
Maybe a use flag to indicate you want to run as a daemon and modify the group
file could be a way to go. It can wait anyway, I would rather get some
feedback on whats holding this back from being in portage. I have YAPLPT to
maintain until then.
YALPT=Yet Another Public Local Portage Tree :)
Created an attachment (id=13036) [details]
media-video/mythtv-0.9.ebuild
i will test *thoroughly* before posting ...
i will test *thoroughly* before posting ...
i will test *thoroughly* before posting ...
i will test *thoroughly* before posting ...
... install mysql.txt config file *CORRECTLY*
the currently posted 0.9 ebuild will upgrade just fine if copied to
mythtv-0.9.1.ebuild
therefore, I won't post a new version just yet.
Upgrading mysql database with 0-8-to-0-9.sql probabley needs to be taken care
of now. Maybe done automatically with a local use flag. ie "use=mythtvBackEnd"
emerge mythtv or maybe if the "mysql" flag is present just do it. I guess the
local use flag is better as you need to have "mysql" set even if there is no
mysql on the box to build the qt plugin.
Sorry, but I have to strongly disagree. Aside from all the security
implications, I wouldn't feel comfortable doing (or even allowing someone to
do) a production db upgrade without first reviewing the contents of the upgrade
and not giving a chance to backup the current contents of the db. This also
becomes especially problematic if someone has multiple backend/frontend
machines that point to the same db. Granted one can argue that the local use
flag should be used to prevent the db upgrade from happening more than once,
but that is not sufficient: what if you install the same version more than
once on the same machine? The potential for running amock is far to great.
(I'll stop ranting now -- sorry) :-)
I think a note during pkg_postinst() about how to upgrade the db should
suffice. Or maybe even leaving the note as is because it points the user to
the UPGRADING doc which explains what to do.
Yeah, I know what you mean, but the simple fact is the thing is going to very
broken without the DB upgrade. I guess in a sense it doesn't matter as the
devs haven't put mythtv into portage yet, despite indications that it was next
kid off the block. I am now pretty pissed off with the treatment this project
is getting from devs and will upgrade the local portage tree with some sort of
DB upgrade, maybe as a separate script that can be run if the user desires, he
has too really for the system to continue working correctly.
hi, listen I am sorry for the delays in this. I have hesitated because I can
not test this at all. I am trying to find a dev who is willing to handle this
Jeremy Johnson had an idea (off list) to use pkg_config() as a means of
upgrading the db. This is a nice clean way of handling such a thing. What do
you all think? Basically, it would include a pkg_postinst() message like:
If you need to update your database please run:
ebuild /var/db/pkg/${CATEGORY}/${PF}/${PF}.ebuild config
This can be done for all myth projects that need a db upgrade. Of course
special care has to be given to mythmusic (bug 18254) because it requires a
tweak to the upgrade sql script.
I'm all for the config idea
Technically mysql doesnt need to be a dependancy. MythTv will work as long as
it can access mysql, it doesnt have to be on the same machine. Maybe a local
use flag should be used to control if mysql is to be compiled on the local
machine.
mysql needs to be installed on the machine when you build QT otherwise the
mysql_qt plugin doesn't get built, which is needed. Is there is a way around this let?
Yes, mysql isn't technically needed for mythtv itself, but, like Tony said, it
_is_ needed for QT, so this dependency doesn't really hurt. It can certainly
be removed as well -- I can go either way.
as far as automatic db updating goes...I thought about this some more and I
have to say that I'm leaning more and more toward leaving it as is. There are
just too many questions with too many answers that can potentially break things
far worse then leaving the database un-upgraded:
- is this a new installation or an upgrade?
- if it is an upgrade, what was the previous version?
- if it is new, the proper install script needs to be run which requires
mysql root privileges (to create the db and user/pass)
Aside from this, I saw a change going into mythtv that tag the database with a
version which the binaries check against their own version and if the two
mis-match, the binary will exit with an error. This is enough to prevent
running mythtv with an un-upgraded db and will quickly let the user know that
something needs to be done. I'm pretty sure this feature made it into the 0.9
release (could be wrong though).
Created an attachment (id=13250) [details]
media-video/mythtv-0.9.1.ebuild
from the changelog (will be posted shortly):
Bump to 0.9.1. Drop the sed fix for config file in /etc/mythtv and use
a patch instead which also fixes another file. This allows mythgallery
to show up on the main mythfrontend screen.
The latest ebuild does not work for me. The patch did not work and the build
failed. Both hunks failed on the patching.
could you please post the log epatch produced, your emerge --info output and
the actual error you got from the ebuild? it'll help track this down. thanks.
It worked ok for me. Did you install the patch file in the right place?
/your_portage_local/media-video/mythtv/files
The rc mythbackend script hangs for me.
ewarn "" produces a yellow "*" and then hangs. Removing the line works fine.
Scenairo: mythbackend is configured for user nobody and is in group video.
mythbackend starts fine on boot, and waits to record before accessing
/dev/v4l/*. User logs in with gdm as some other user. gdm chowns /dev/v4l/*
to the user and chmods /dev/v4l/* to 0600.
When mythbackend tries to access the device it fails, because group permissions
are no longer sufficent.
In pariticular, gdm will change /dev/v4l/* ownership to user and chmod to 0600
on login if it is not already owned by the user. On logout, it will change
group to sys. The group should become video.
You should probably disable pam_console support in devfsd.conf so that
permissions of your devices don't change whenever someone logs on. look for
these lines in /etc/devfsd.conf
# Uncomment this to let PAM manage devfs
REGISTER .* CFUNCTION
/lib/security/pam_console_apply_devfsd.so
pam_console_apply_single $devpath
Aside from this, I already have an outstanding bug about the inconsistancies in
default console.perms file (bug #18599). I have yet to post a patch though --
been busy with other things.
Created an attachment (id=13503) [details]
media-tv/mythtv-0.9.1-r2.ebuild
Just a bump with a smaller DEPEND list -- no dev-db/mysql (there might be a
future version of mythtv that is backend independant. i.e. whatever is
supported by QT). Also this moves it to media-tv.
I don't agree with the last change. While it's true it is not dependant on a
running local
version of mysql, it is dependant on mysql running somewhere. It is also
dependant on
having QT built with mysql support. Maybe a use flag to enable/disable it
locally. The
other thing is if your installing from scratch if you don't have mysql
dependant here and
the USE="mysql" isn't set, it won't work AFAIK. What would be nice is if we
could build
the mysql-qt plugin here rather than have to rebuild QT.
detecting mysql support really should be the function of the upstream package
build process, but until that is in place we can try this:
if [ ! -e "${QTDIR}/plugins/sqldrivers/libqsqlmysql.so" ]
during the unpack stage and die out with a note if true. I'm mildly against
this because, as I said, mythtv can potentially be made to work with different
backends. And AFAIK, there's no simple way to build just the mysql plugin.
Opinions?
There is no upstream package that is dependant on mysql, which is the problem
really.
mythtv is dependant on QT being built with mysql support. QT doesn't give a
damm.
We could add an ewarn at the end of the build or do as you suggested, which I
think is
maybe better as they can rebuild QT in the same merge then.
*** Bug 23164 has been marked as a duplicate of this bug. ***
For those interested, I have new cvs ebuilds for the following ready:
mythtv-cvs mythgallery-cvs mythgame-cvs mythmusic-cvs
mythvideo-cvs mythweather-cvs mythweb-cvs
I don't think I want to post all these ebuilds+changelogs to bugzilla, so if you want them get them from my local portage cvs tree. Instructions are located here:
http://marc.theaimsgroup.com/?l=gentoo-dev&m=105648371100634&w=2
Please be aware that these are for *CVS*. Therefore at any given point, things may be broken. Also make sure you update your database accordingly. Have a look at http://www.mythtv.org/docs/mythtv-HOWTO-1.html before proceeding. Also, I haven't really done a great deal of .... what's that called? .... oh yes, *testing* on these. So feedback is greatly appreciated. Thank you.
max,
did some testing of your cvs-ebuilds... two things:
1.) need to add a line that clears contents of /usr/local/include/mythtv/ if they exist in the main mythtv-cvs ebuild (will only affect upgrades) read this thread for info:
http://www.gossamer-threads.com/perl/mailarc/gforum.cgi?post=68878;search_string=;guest=710915&t=search_engine#68878
2.) add a comment at the end of the main myth ebuild to remind people to edit the new files in /etc/conf.d otherwise if they reboot without doing it and have mythbackend already added to the default runlevel then they will hang on boot and have to boot to liveCD to fix it... (learned that one the hard way)
other than those minor things it works great so far...
i of course had to do some sql updates... one would require some prior knowledge of mythtv' motus operandi for releases unless the script did it... but i understand that its difficult to check the current status of the mysql database... although the login info needed could be found in the mysql.txt file... if that is found you could assume a previous version, just not know which one!
Sean.
Hi.
1) I think it would be very inappropriate for an ebuild to touch files other than the ones
it knows about. Since the ebuilds themselves don't put anything in /usr/local, clearing
things from there is something best left to the user.
2) Hmm... I'm not sure that basic troubleshooting tips is also the right place for a
postinst() message. There are many things one can do to prevent such things from
happening -- (i.e. restart mythbackend before rebooting to see if it works). Of course
things like this can happen to the best of us, but going to the livecd is also not the only
way to fix it (what about booting to single-user mode? I've fixed many-a-problems with
a simple -s as a kernel parameter). The real problem is why your mythbackend hung
and why fixing /etc/conf.d would have any effect? If the permissions are wrong, it
shouldn't have been able to start. Could you provide more information on this? This
sounds similar to comment #52 -- can you try what I suggested in comment #53?
As for the database updates between upgrades....Like I said in comment #44, there
are too many questions. I tried to whip up a choice-based update procedure, but
there are still some issues:
- do you show all *.sql files or just *-to-*.sql files?
- if all, then do you prevent user from running cvs.sql or mc.sql?
- if not then why not just stick with a message urging user to upgrade db him/herself?
- how do you take care of the situation in mythmusic where you have to change
the sql file before running it?
- if you allow the user to choose mc.sql, then you have to ask for the mysql root login
and password.
So I think these questions are outside the scope of the ebuild and should be left for
the user to decide what to do. Hopefully the database schema changes will slow
down in mythtv upstream development which will make this whole thing a non-issue.
Hello all. I committed the new mythtv (0.10) and xmltv (0.5.14) ebuilds to my
local tree. There are some rather big changes upstream so be sure to check out
www.mythtv.org for info. There are also some moderately big changes with the
mythtv ebuild. Here's my change log:
Bump version to 0.10. Drop all patches -- just move config to /etc/mythtv and
link to /usr/share/mythtv. Change xmltv depend to >= 0.5.14. Move
/usr/share/mythtv/setup to /usr/bin/mythsetup and add note on pkg_postinst().
Drop permission change of /var/{log,run}/mythtv -- do it as part of the rc
script. Change startup script config file to start mythbackend as root --
will still warn about root not being part of the video group and gives the
user an option to change to a non-root user; helps with hanging mythbackend
on startup as reported on #10533. Add a note about the importance of
upgrading
the database.
also:
Fix up mythbackend start up script: reset permissions on pid and log
directories, change MYTH_NOWARN to MYTH_WARN and reverse the functionality,
other cleanups.
Please let me know if you have any problems.
Hi Max, Can't seem to checkout portage from your cvs.
tony@power cvs $ cvs -d :pserver:cvs@68.6.36.243:/home/cvs login
Logging in to :pserver:cvs@68.6.36.243:2401/home/cvs
CVS password:
tony@power cvs $ cvs co portage
cvs checkout: cannot find module `portage' - ignored
max,
hmm...
ok i agree with you on your second point... that was my fault for forgetting that i had an old script in there and not checking for the new file in conf.d for sure, the hang was caused by the fact that i had not edited the conf.d/mythbackend file...
but i must stick with my guns on the first point. If it impairs my ability to compile the add-ons then it should be tossed, i could care less if the ebuild deletes some files or however you wanna deal with it, its just mythtv ya know... its not my production webserver or whatever. A good portion of the people installing the ebuilds (even in there current "beta" form) will be upgrading from a previous version of mythtv that was installed from regular source and will hit the same wall i did... i assumed (bad move i know) that the ebuilds files would go in the same directories that myth puts em and thus get overwritten and all would be well, but never would have suspected that the add-ons wouldnt compile because of some files left behind.
really im just trying to give you a newbs perspctive and let you know what you may run into with the other newbs out there. i'll leave the "ebuild ethics" up to you ;-)
Sean
btw, thanks for the ebuilds, im grateful someone takes the time to make and post them!
oh and i almost forgot...
about all the questions you were thinking about coding into it.
an interactive install would be really cool but probably a big pain, how about we just write up a README.gentoo and have it referenced in the postinst() ?
then theres just one postinst() message telling me in big letters to check out the new readme file before myth will work and we put a real basic FAQ and the answers to the questions in there, most of it would just be a few myth specific things and the how to on the database entries and the rest is already in myths UPGRADING text. i'd help if you need it. lemme know.
Sean
Tony: your second command doesn't specify a CVSROOT so whatever is in the
environment is probably taking over and you're trying to check out the portage
module from some other server. Try running it as
cvs -d :pserver:cvs@68.6.36.243:/home/cvs co portage
Sean: with regards to the "first point", I really have to disagree. It is
very much against policy for an ebuild to go outside of its scope. What if a
user is testing something and places it in /usr/local? The standard operating
procedure for resolving these kind of problems is to ask on the forums or file
a bug which will quickly lead to an answer -- and after fixing them one time
(i.e. removing the /usr/local stuff out yourself) your problems are fixed for
future installations.
As far as a README.gentoo goes...That's probably a good idea -- we can move
most of postinst() message to that.
Just to clarify the "first point", this whole thing is a non-issue because
there's a global search/replace for /usr/local so this problem shouldn't happen
to others. Sean, you might have gotten my cvs ebuilds before their "final"
version. Just to confirm:
dozer mythtv # emerge mythgallery 2>&1 | grep usr/local
dozer mythtv #
As you can see, usr/local isn't mentioned at all in any of the compile
commands.
Thanks Max, I'm a little neutral on the subject under debate, I think probably
the cvs
ebuilds should automatically update the database as it is pretty easy to miss
the update
otherwise and if you play with cvs then you have to expect that your system
will get
stuffed up sooner or later. :) Thats the main reason why I like to work
directly with cvs so
I can see the changes before blowing the system away.
The other thing I think the ebuild needs is a local use flag for a frontend
only. ie
use="mythtv-frontend" Just installs the frontend stuff
use="mythtv-backend" Installs front and back end but no database stuff.
The is no reason to install all the other stuff with databases and backend.
The default
would be to install the lot. I can have a go at this on the weekend if you
like.
Maybe a variable instead of a use flag. ie MYTHTV_OPTIONS? Thats could be
placed
in make.conf
It would be even more difficult to update the database for cvs ebuilds because
there's
no guarantee that the current database snapshot is compatible with the cvs.sql
file
(as that file changes quite frequently, you may already have part of it
integrated). It is
also assumed that if you're running the cvs builds, you have an understanding
of how
things work and therefore can do the updates yourself. (I've been doing this
with
mythtv-cvs, kopete-cvs, php-cvs, horde-cvs and others -- maintaining
configs/databases).
As far as separating front/backend, wouldn't that just add extra bloat and
maintainability problems? Besides, I believe the standard in Gentoo is to
install most
of the package when it comes to frontends/backends -- think mysql, openssh,
openldap -- (all install client and server). Heck, even rsync installs an
/etc/init.d/rsync
startup script.
I think in this case, at least a frontend only solution, is quite good as it
avoids all the xmltv
dependicies. Things like mozilla allow you to disable a lot of normal
features. ie mail irc
etc, so I don't think there is a Gentoo standard except to build everything by
default.
Maybe Seemant can comment on this?
now incorporated.
Enjoy :)
