This is an innovative program :D msn video webcam java based Reproducible: Always Steps to Reproduce: 1. 2. 3.
they keyword here should be "REQUEST". "EBUILD" is used when a user is submitting an ebuild already ready for portage... just for future reference
I am looking into this. Due to the problems with LAX and NPTL this is going to take some time ( http://www.mercury.to/index.php?page=Wiki&wikipage=Linux_Setup ).
Other problems came up with the ebuild. After talking to the mercury devs i managed to get a .zip file that is much easier to install that using the .bin LAX file. I'm working on this. In a few hours i hope to have a working ebuild.
Created attachment 48464 [details] mercury-bin-1708.ebuild This is the first attempt. Some things need extra work due to the Gentoo Java Policy ( http://gentoo-wiki.com/Gentoo_Java_Policy ). For example altough jdom is polled using the jar from there will not work 100% ok (right now the ebuild will install the one on mercury package).
Created attachment 48465 [details] mercury.sh start up script. Place it in files before emerging this.
tryng ... ebuild /usr/local/portage/net-im/mercury/mercury-bin-1708.ebuild digest !!! aux_get(): ebuild path for 'net-im/mercury-bin-1708' not specified: !!! None !!! aux_get(): ebuild path for 'net-im/mercury-bin-1708' not specified: !!! None doebuild(): aux_get() error; aborting.
Solved the pat have to be mercury-bin not mercury
ryng emerging i've another error: emerge -pv mercury-bin These are the packages that I would merge, in order: Calculating dependencies F !!! Problem in net-im/mercury-bin dependencies. !!! "Specific key requires an operator (dev-java/blackdown-jdk-1.4.2) (try adding an '=')" exceptions
Created attachment 48492 [details] Corrected ebuild It's my first ebuild correction please be carrefully can be dangerous
betelgeuse@pena ~ $ mercury /usr/bin/mercury: line 3: cd: /opt/mercury: No such file or directory Could not find package jmf-bin Could not find package mercury Exception in thread "main" java.lang.NoClassDefFoundError: com/dMSN/Main
Andrea: You just removed the java deps, that is not good :) I corrected that and am testing with java 1.5 In a few minutes i'll upload a corrected startup script and ebuild.
Forget the jmf-bin part. It was come because I used ebuild merge, but the other errors are valid.
Created attachment 48538 [details] mercury-bin-1708.ebuild New version of the ebuild, corrected java dep. Already tested with 1.5 and works 0k.
Created attachment 48539 [details] mercury.sh
Created attachment 48540 [details] icon32.gif
mercury /usr/bin/mercury: line 12: java: command not found
ok exported the java bin directory and it starts well but... if anyone send me an invite: XYZW invited you to see from his/her webcam. Mercury does not support this. (Mercury does support video conference if you have the required files) ok shre but what i've to do to enable this? (For mantainer if it's a problem to write all there you can contact me for mail and send me all the information i'll write the how to for gentoo forums.)
This software is under eavy development. The message you receive is true, you do not have the required files (no one has except the mercury devs). Please dont post info about this in the forums, the last thing we need is 100 newbies coming here saying "does not work for me". This package will probably take some time (weeks) to get into portage, due mainly to the deps. Many of the jar files installed are from other packages, and some of them still do not exist in portage, so they must first be added.
Created attachment 48590 [details] mercury.sh
Created attachment 48591 [details] mercury-bin-1708.ebuild Ok this version should probably work for most people. This version still installs the original .jar files. We need to put a version of jdom in portage that works with this, we need to make an ebuild for http://jdic.dev.java.net/ (at least the tray icon), and a ebuild for xmlpull (the implementation used by mercury).
Created attachment 48678 [details] mercury-bin-1708.ebuild Fixed some errors here. Should work ok now.
Created attachment 48679 [details] mercury.sh This version will spit a non fatal error about jdom and will work with the tray icon (on x86 will other arches no).
Created attachment 48952 [details] mercury-bin-1708.ebuild This version already depends and works with jdictrayapi, i'll commit that one soon and close the bug. We still need jdom 1.0 Beta 6 as mercury has some problems with beta 9
Created attachment 48953 [details] mercury.sh
*** Bug 78563 has been marked as a duplicate of this bug. ***
I added this to portage now. It will be un-hardmasked as soon as all deps are in portage.
Why all the dev java packages dependencies? I got it working only with the JRE and JMF packages, including tray icon in KDE. Why would I need 20 extra useless (for me) packages installed in my system? From my point of view, this is the same as with Azureus, but the devs finally agreed to remove the dependencies there.
Gustavo Michels: http://gentoo-wiki.com/Gentoo_Java_Policy#Bundled_JARs
Gustavo Michels: Can you provide the bug on azureus that backs up your statment?
http://bugs.gentoo.org/show_bug.cgi?id=58389 That's the bug which complainted about the dependencies. Although no dev said anything about the change, azureus no longer has that big list of dependencies.
completely unrelated, since the azureus-bin ebuild violates policy in many ways (there is better one just net-p2p/azurues)
I don't think it's completely unrelated. This ebuild also installs a binary version of Mercury, and net-p2p/azureus compiles and installs the source version (not to mention the fact the azureus ebuild is still on an older version). Anyway, I was just trying to get this ebuild to be more user friendly. Anyone who would like to install mercury and sees that huge list of apparently uneeded dependencies won't continue. If it's a policy, then I won't argue anymore. The simple solution is --oneshot --nodeps.
You don't seem to understand. The mercury zip has jars which come from different projects than mercury itself. We install these external libraries first and use the jars from them. That way we only have to have one copy of a jar installed. Please read the link I already posted. Because of all this --oneshot --nodeps is not going to work with the final mercury ebuild. The packed jars are deleted in src_unpack.
The version 1709.07 (26/02/05 17:48) it's OUT. Can you update the ebuild plz? Thx for all the work :)
Created attachment 52317 [details] Mercury 1709.B7 ebuild That's my modifies on the mercury-bin-1708.ebuild . It works correctly but I think it need the apply of some policies.
Created attachment 60230 [details] Mercury 1709_RC8 Here is the new ebuild for the latest Release Candidate of Mercury 1709. This ebuild supports two new use flags: one is "flash", that you have to enable in order to receive and show Winks, while the other one is the "cam" flag, that you need in order to send webcam streams.
Comment on attachment 60230 [details] Mercury 1709_RC8 ># Copyright 1999-2005 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 ># $Header: > >inherit eutils java-pkg > >MY_PVR=${PVR/rc/RC} > >DESCRIPTION="MSN and Jabber client in Java" >HOMEPAGE="http://www.mercury.to/" > >##Mercury.to does not provided http or ftp links > >LICENSE="mercury" >SLOT="0" >KEYWORDS="~x86" >RESTRICT="fetch nostrip" > >IUSE="cam flash" > >SRC_URI="${MY_PVR}.zip > cam? ( JavaLibs-linux.jar ) > cam? ( VidConf-libs.jar ) > cam? ( NativeLibs-linux.zip )" > >DEPEND="app-arch/unzip > >=virtual/jdk-1.4" >RDEPEND=">=virtual/jre-1.4 > =dev-java/jgoodies-looks-1.3* > dev-java/jmf-bin > dev-java/jdictrayapi > dev-java/xpp3 > ~dev-java/jdom-1.0" > >S=${WORKDIR} > >pkg_nofetch() { > einfo "Goto http://www.mercury.to/ and download ${MY_PVR}" > einfo "It is a torrent download, so you must use a BitTorrent-like client" > einfo "For information about this tecnology, look at Mercury official site" > einfo "You must put the downloaded file in ${DISTDIR}" > if use cam; then > einfo "" > einfo "For cam support You also have to download a directory with" > einfo "some files inside via this torrent:" > einfo "http://www.mercury.to/torrents/VidConf_Files.torrent" > einfo "You have to copy the files inside the directory you downloaded in" > einfo "${DISTDIR}" > einfo "WARNING: you DON'T HAVE TO COPY the directory itself, only the files inside!" > fi >} > > >src_unpack() { > unpack ${MY_PVR}.zip > cd ${S} > rm -f *.dll *.so > > #Clean the dllStuff.jar from things we dont need > cd lib > mkdir dllStuff > cd dllStuff > unzip ../dllStuff.jar > rm -rf ../dllStuff.jar org/jdesktop x10gimli/platform > > cd ${S} > rm lib/XML.jar # jdom > rm lib/looks-*.jar #jgoodies-looks > if use !flash; then > echo "Removing JFlash.jar" > rm lib/JFlash.jar # seems to be trial from http://www.javaapis.com/jflashplayer/ which says its windows only > fi > rm lib/xmlpull.jar # xpp3 >} > >src_install() { > #rebuild the dllStuff.jar > cd ${S}/lib/dllStuff > jar cf ../dllStuff.jar * > cd ${S} > rm -rf lib/dllStuff > > #Start installing stuff > insinto /opt/${PN}/resources > doins -r resources/* > java-pkg_dojar lib/* > > insinto /opt/${PN}/lib > if use cam; then > doins ${DISTDIR}/JavaLibs-linux.jar > doins ${DISTDIR}/VidConf-libs.jar > > insinto $(java-config -o)/lib/i386 > echo "*** Installing needed java libraries into current JRE home $(java-config -o)" > unzip ${DISTDIR}/NativeLibs-linux.zip -d ${D}$(java-config -o)/lib/i386 > fi > > insinto /usr/share/pixmaps > newins ${FILESDIR}/icon32.gif mercury.gif > > exeinto /opt/bin > newexe ${FILESDIR}/mercury.sh mercury > > make_desktop_entry mercury "Mercury MSN client" /usr/share/pixmaps/mercury.gif >}
I'm sorry this is my first ebuild attachment and I have made a little error submitting my replies :-)
Created attachment 60231 [details] mercury-bin-1709_rc8.ebuild
Comment on attachment 60231 [details] mercury-bin-1709_rc8.ebuild Here is the new ebuild for the latest Release Candidate of Mercury 1709. This ebuild supports two new use flags: one is "flash", that you have to enable in order to receive and show Winks, while the other one is the "cam" flag, that you need in order to send webcam streams. Sorry again for the little mess above :)
Created attachment 60232 [details] mercury.sh Startup Script
well i am no java team guru :) But there are some parts of the java instalation that i dont really like. insinto $(java-config -o)/lib/i386 echo "*** Installing needed java libraries into current JRE home $(java-config -o)" unzip ${DISTDIR}/NativeLibs-linux.zip -d ${D}$(java-config -o)/lib/i386 as far as I can tell this is really flawed. What if the person changes jre? Mercury stops working? axxo: Can you give this a look, this should probably be with dojar right?
Created attachment 60280 [details] mercury.sh Startup Script
Created attachment 60281 [details] mercury-bin-1709_rc8.ebuild Gustavo, I have corrected the thing about touching jre folder... You are absolutely right, It was 5 AM when I have finished editing the ebuild so maybe I wasn't too smart :-) Now the location for the *.so files is /opt/mercury-bin... it's the only location where I found there are no problem.. if I put that files in /opt/mercury-bin/lib then Mercury can't find some of that files, I don't know why, maybe because it search for them in jre home or in the current folder, that is /opt/mercury-bin... anyway, this way works.. anyway sorry 4 my bad english ;-)
> > Now the location for the *.so files is /opt/mercury-bin... it's the only > location where I found there are no problem.. if I put that files in > /opt/mercury-bin/lib then Mercury can't find some of that files, I don't know > why, maybe because it search for them in jre home or in the current folder, > that is /opt/mercury-bin... anyway, this way works.. > You are supposed to use java-pkg_doso to install shared libraries. You should also always use java-pkg_dojar when installing jar files. You can use java-pkg_{jar,so}into to change the location where the files are installed.
(In reply to comment #46) > You are supposed to use java-pkg_doso to install shared libraries. You should > also always use java-pkg_dojar when installing jar files. You can use > java-pkg_{jar,so}into to change the location where the files are installed. I tried to correct this section of src_install: insinto /opt/${PN}/lib if use cam; then doins ${DISTDIR}/JavaLibs-linux.jar doins ${DISTDIR}/VidConf-libs.jar insinto /opt/${PN} unzip ${DISTDIR}/NativeLibs-linux.zip -d ${D}/opt/${PN} fperms 755 /opt/${PN}/*.so fi in this way: if use cam; then java-pkg_dojar ${DISTDIR}/JavaLibs-linux.jar java-pkg_dojar ${DISTDIR}/VidConf-libs.jar unpack NativeLibs-linux.zip java-pkg_doso *.so fi It works fine for Jar files, but with the .so files I still have the problem that Mercury can't find one of them, throwing this exception: java.lang.UnsatisfiedLinkError: JMFSecurityManager: java.lang.UnsatisfiedLinkError: /opt/mercury-bin/lib/libjmv4l.so: libjmutil.so: cannot open shared object file: No such file or directory Maybe you can help me.. anyway I'm sorry if I'm making so much mistakes, but I think that the best way to learn something is to try to do it the best way I can :)
I have to correct myself: java-pkg_dojar don't work with JavaLibs-linux.jar and VidConf-libs.jar. So: JavaLibs-linux.jar and VidConf-libs.jar MUST go in /opt/mercury-bin/lib, or they won't be recognized. All the *.so files of NativeLibs-linux.zip MUST to in /opt/mercury-bin, or they will be recognized but using the webcam throws the exception above. I don't know why, but this is the only way to make everything working...
add -Djava.library.path=$(java-config -i mercury) to the wrapper script
(In reply to comment #49) > add -Djava.library.path=$(java-config -i mercury) to the wrapper script Already tried that and all the possible combinations of paths :)... just doesn't work! In mercury there is a panel where you can see if all the necessary libraries for webcam sending are installed. Adding -Djava.library.path with the path of *.so files, makes that panel show that Native Linux Libraries are found, but if you try to use the webcam you get the exception above.
I talked with upstream developer: [20:20:16] <Danny (Mercury)> I know of the problem that native libraries need to be in the mercury root directory [20:20:58] <Danny (Mercury)> I have not found a way to change this, I have about 30 dll files in my Mercury root and I would be more then happy to kick them to some remote directory with a pointer or something to it [20:21:02] <Danny (Mercury)> but I have no idea how [20:21:33] <Danny (Mercury)> same goes for the .so files I guess, they need to be in the mercury root or the jre/lib/i386 directory (I guess) [20:22:06] <Danny (Mercury)> doing the java.library.path change will only fool mercury into believing the files are ok, java doesn't allow it I think axxo: You're de java expert. Any ideas?
The .so files are part of jmf. Probably no need to install them.
(In reply to comment #52) > The .so files are part of jmf. Probably no need to install them. emerging jmf-bin does not install those files...
Created attachment 60297 [details] mercury-bin-1709_rc8.ebuild Corrected a little bug..
have they open sourced it yet? then i can take a look, otherwise ... (and i have exams for the next 3weeks, so not alot of time)
Created attachment 60360 [details] mercury.sh Startup Script Corrected a bug that prevent Mercury from starting on a clean system.
Created attachment 62599 [details] mercury-bin-1709_rc12.ebuild
Mercury Messenger needs linux jmf (includes some binary libs) which is not included in portage not the cross platform jmf
Install Mercury with -flash don't work. In this case, when somebody sends you a wink, the conversation stops and you must disconnect/reconnect to talk again.
although all the *.so files are in the locations as described in comment 48, mercury still throws the same exception as in comment 47 when trying to use the webcam. Any ideas?
(In reply to comment #60) > although all the *.so files are in the locations as described in comment 48, > mercury still throws the same exception as in comment 47 when trying to use the > webcam. Any ideas? as decribed in the mercury wiki http://www.mercury.to/index.php?page=Wiki&wikipage=LinuxLibraryLocations this should be added to the 2nd line of mercury shell script for it to resolve library locations options="-Djava.library.path=/opt/mercury-bin"
Even if the file libjmutil.so is the right, it also needs to be in the main java libraries folder. See here for more explanation of this exception : http://forum.mercury.to/index.php?act=ST&f=40&t=9568&hl=libjmutil&s=5b51c435041dc9187b72c870fec497d6 Anyway, version 1709 is out.
Created attachment 65794 [details] mercury-bin-1709.ebuild (FINAL) This is the ebuild for the final version. I cutted some parts that aren't so useful (and that were buggy), added some info for AMD64 users and corrected the libjmutil.so with an env.d file. Maybe could this be added to portage?
Created attachment 66217 [details] mercury-bin-1709.ebuild (FINAL) mercury doesn't work with jdictrayapi-0.9.1, so I forced version 0.8.7...
(In reply to comment #64) > Created an attachment (id=66217) [edit] > mercury-bin-1709.ebuild (FINAL) > > mercury doesn't work with jdictrayapi-0.9.1, so I forced version 0.8.7... A better solution is to slot jdictrayapi. After I have done this, I will post here.
Now there is a weblink to the mercury files. Could we put that into the ebuild for download? (the link is: http://s16.nextit.nl/mercury/1709_Linux_NoVM.bin)
well, forget the last comment. It seems that web links still does not provide the zip file or anything equally plausible for an ebuild. Zip file is still distributed only as a torrent.
Well, altough this is a very nice rich client the upstream project is a mess. There are ALOT of packages that come with mercury that are not from the author but no credit is given, so even hosting the .zip files is a problem. Contact with upstream devs to find what versions where used is almost impossible. Upstream had talked about open sourcing the project (that would make Gentoo dev's job much easyer and also complience with Gentoo-Java Policies) but nothing has happened in almost a year. So I'm closing this and will be removing mercury-bin from portage very soon. Thanks to everyone that tryed to make this work but it seems impossible to make this possible.
