Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 323819 - net-im/jitsi(-bin) - An audio/video SIP VoIP phone and instant messenger written in Java
Summary: net-im/jitsi(-bin) - An audio/video SIP VoIP phone and instant messenger writ...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement with 23 votes (vote)
Assignee: Default Assignee for New Packages
URL: http://jitsi.org/
Whiteboard:
Keywords: EBUILD
: 473012 574800 (view as bug list)
Depends on: 477780 503754 503756 181877 265827 503758
Blocks:
  Show dependency tree
 
Reported: 2010-06-13 17:49 UTC by mren
Modified: 2023-08-22 08:23 UTC (History)
43 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Initial attempt at writing jitsi ebuild (jitsi-1.0_beta1_pre3486.ebuild,1.55 KB, text/plain)
2011-05-21 01:54 UTC, Orivej Desh
Details
jitsi-1.0_beta1.ebuild (rev 3515) (jitsi-1.0_beta1.ebuild,1.57 KB, text/plain)
2011-06-06 01:59 UTC, Weonbin
Details
ebuild for rev. 3820 (jitsi-1.0_beta1.ebuild,1.65 KB, text/plain)
2012-03-26 22:29 UTC, Sven M.
Details
jitsi 1.0 (jitsi-1.0.ebuild,1.63 KB, text/plain)
2012-05-24 21:28 UTC, Andreas Nyback
Details
Jitsi 1.1RC Ebuild (jitsi-1.1_rc1.ebuild,1.65 KB, text/plain)
2012-08-14 14:13 UTC, Jason Lamb
Details
jitsi-1.1.4271.9982.ebuild (jitsi-1.1.4271.9982.ebuild,1.89 KB, text/plain)
2012-10-18 23:49 UTC, Guillaume Horel
Details
jitsi-1.1.4285.10000.ebuild (jitsi-1.1.4285.10000.ebuild,2.04 KB, text/plain)
2012-10-19 02:45 UTC, Guillaume Horel
Details
Jitsi 2.0 ebuild (jitsi-2.0.ebuild,1.99 KB, text/plain)
2013-03-07 16:07 UTC, Jason Lamb
Details
Jitsi shell script reference in comment #19 (jitsi,980 bytes, text/plain)
2013-03-07 16:08 UTC, Jason Lamb
Details
jitsi-2.0.4506.10553.ebuild (only classpath problem left) (jitsi-2.0.4506.10553.ebuild,2.02 KB, text/plain)
2013-03-07 16:37 UTC, Navid Zamani
Details
jitsi-2.0.4506.10553.ebuild (only native libs problem left) (jitsi-2.0.4506.10553.ebuild,2.06 KB, text/plain)
2013-03-07 21:52 UTC, Navid Zamani
Details
jitsi-2.0.4506.10553.ebuild (only native libs problem left) (jitsi-2.0.4506.10553.ebuild,2.29 KB, text/plain)
2013-03-07 22:40 UTC, Navid Zamani
Details
Error output for script by Jason Lamb (jitsi-fail.log,8.67 KB, text/plain)
2013-03-08 00:23 UTC, Navid Zamani
Details
/usr/bin/jitsi (jitsi,1.22 KB, text/plain)
2013-03-08 01:22 UTC, Navid Zamani
Details
jitsi-2.0.4506.10553.ebuild (jitsi-2.0.4506.10553.ebuild,1.90 KB, text/plain)
2013-03-08 03:03 UTC, Navid Zamani
Details
jitsi-2.2.4603.9615.ebuild (jitsi-2.2.4603.9615.ebuild,2.58 KB, text/plain)
2013-05-31 06:04 UTC, Zac Medico
Details
jitsi-2.2.4603.9615.ebuild (jitsi-2.2.4603.9615.ebuild,2.58 KB, text/plain)
2013-05-31 13:24 UTC, Jason Lamb
Details
jitsi-2.3.4668.9744.ebuild (jitsi-2.3.4668.9744.ebuild,2.58 KB, text/plain)
2013-05-31 13:26 UTC, Jason Lamb
Details
jitsi /usr/bin shell script (jitsi,1.26 KB, application/x-shellscript)
2013-05-31 13:32 UTC, Jason Lamb
Details
jitsi-2.3.4700.9860.ebuild (jitsi-2.3.4700.9860.ebuild,2.55 KB, text/plain)
2013-06-29 13:42 UTC, Jason Lamb
Details
jitsi 2.3 /usr/bin shell script (jitsi,1.22 KB, text/plain)
2013-06-29 13:45 UTC, Jason Lamb
Details
updated jitsi-2.3.4700.9860.ebuild (jitsi-2.3.4700.9860.ebuild,2.53 KB, text/plain)
2013-06-29 22:09 UTC, Jason Lamb
Details
jitsi nightly build ebuild (jitsi-bin-9999.ebuild,1010 bytes, text/plain)
2013-12-12 01:14 UTC, pierigno
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mren 2010-06-13 17:49:09 UTC
Please add an ebuild for sip-communicator.

Reproducible: Always
Comment 1 Marcin Rataj 2011-05-10 09:21:03 UTC
FYI: SIP Communicator is now known as Jitsi: (http://www.jitsi.org)
Ans is much more than a SIP client: http://www.jitsi.org/index.php/Main/Features
Comment 2 Orivej Desh 2011-05-21 01:54:48 UTC
Created attachment 274173 [details]
Initial attempt at writing jitsi ebuild

I made a working ebuild (based on the structure of a debian package from jitsi.org).  It is supposed to work on x86 and amd64.
Comment 3 Kent Hagebrand 2011-05-22 16:47:36 UTC
(In reply to comment #2)
> Created attachment 274173 [details]
> Initial attempt at writing jitsi ebuild
> 
> I made a working ebuild (based on the structure of a debian package from
> jitsi.org).  It is supposed to work on x86 and amd64.

Worked for me. Thanks!
Comment 4 Weonbin 2011-06-06 01:47:05 UTC
I don't know if it's because I modified the ebuild to use the latest version (3515 instead of 3486), but it failed not finding org.apache.tools.ant.taskdefs.optional.Native2Ascii
Adding a dependency to dev-java/ant-nodeps made it compile flawlessly
Comment 5 Weonbin 2011-06-06 01:59:50 UTC
Created attachment 275963 [details]
jitsi-1.0_beta1.ebuild (rev 3515)
Comment 6 darkbasic 2011-12-16 13:56:08 UTC
The ebuild does not work anymore.
Comment 7 darkbasic 2012-02-12 21:12:29 UTC
Nobody has a working ebuild with a more recent version (like 1.0-beta1-build.3820)?
Comment 8 Sven M. 2012-03-26 22:29:55 UTC
Created attachment 306793 [details]
ebuild for rev. 3820

It is a little bit ugly, relies on java 6 but seems to work.
Comment 9 Andreas Nyback 2012-05-24 21:28:13 UTC
Created attachment 312999 [details]
jitsi 1.0

Anyone knows how to get rid of "QA Notice: Package is using java-ant, but doesn't depend on a Java VM" ?

Otherwise worked for me to get 1.0 installed. Hardcoded url for download...

brgds
Andreas
Comment 10 Maik Nijhuis 2012-06-21 09:10:51 UTC
Adreas: I confirm your 1.0 ebuild works fine, on a amd64 stable system. It even works when I change the URL to the latest nightly build, and rename the ebuild to jitsi-1.1_rc1.ebuild

So, gentoo devs, please add this ebuild!
Comment 11 Jason Lamb 2012-08-14 14:13:10 UTC
Created attachment 321320 [details]
Jitsi 1.1RC Ebuild

Thanks for this work.

I was also able to install Jitsi 1.1RC with a modified version of the ebuild from comment #9, included here. However, after installation revdep-rebuild complains about one of the jitsi libs not being owned. A dev suggested that the ebuild should be fixed to install things into the proper location, which should fix this issue. For example, they mentioned the ebuild should use get_libdir, and not use uname in src_install, as two things that should be fixed.

Here's the thread from the Gentoo Forums;

http://forums.gentoo.org/viewtopic-t-933406.html
Comment 12 Guillaume Horel 2012-10-18 23:49:12 UTC
Created attachment 326892 [details]
jitsi-1.1.4271.9982.ebuild

Cleaned up version of the ebuild.
Comment 13 Jason Lamb 2012-10-19 01:49:35 UTC
Thanks for the updated ebuild.

The jitsi-1.1.4271.9982 source nightly build was no longer available so I just renamed the ebuild to the latest nightly version tonight, jitsi-1.1.4285.10000, and I was able to emerge it cleanly. Unfortunately I still have the problem of revdep-rebuild complaining about one jitsi lib being unowned, as described in comment #11.
Comment 14 Guillaume Horel 2012-10-19 02:45:50 UTC
Created attachment 326902 [details]
jitsi-1.1.4285.10000.ebuild

Looks like upstream deletes the nightlies pretty often. I have added an extra line in the ebuild to install a file in /etc/revdep-rebuild which should silence revdep-rebuild for good:)
Comment 15 Jason Lamb 2012-10-19 03:05:49 UTC
Thanks again Guillaume,

The updated ebuild emerges perfectly, and solves the revdep-rebuild issue as well.
Comment 16 Jason Lamb 2013-03-06 16:27:03 UTC
If anyone can look into updating the ebuild, jitsi 2.0 stable, is out now. I tried hacking at the last ebuild but ended up with a broken install.

Thanks..
Comment 17 Navid Zamani 2013-03-06 23:21:31 UTC
Jitsi 2.0 is released now. And it’s really great, and the only actual (as in: XMPP + [multi-]video communication) alternative to Skype.

Unfortunately there’s still no ebuild in Portage.

Can we have that, pretty please? :)

It’s a really great piece of software.

Alternatively, doing all the crazy many features it does in (both) Kopete and Pidgin would of course be an even better option too. But I don’t see that happening anytime soon. (Especially the XMPP video part. XMPP audio apparently already works.)
Comment 18 Vladimir 2013-03-07 09:16:51 UTC
(In reply to comment #17)
> Alternatively, doing all the crazy many features it does in (both) Kopete
> and Pidgin would of course be an even better option too. But I don’t see
> that happening anytime soon. (Especially the XMPP video part. XMPP audio
> apparently already works.)
Gajim supports XMPP video, if anyone is interested.
Comment 19 Jason Lamb 2013-03-07 16:07:37 UTC
Created attachment 341232 [details]
Jitsi 2.0 ebuild

I also really like Jitsi as well and think it would be an awesome alternative to Skype. It's not only open source instant messaging/voice calling/video chat, but there are OSX, Windows, as well as Linux clients available. They even have an Android client in their nightly build section.

So using Guillaume's ebuild from comment #14, I hacked up an ebuild I used to emerge jitsi 2.0 into my system. However, there are several problems with it. The ones I noticed are;

1) A minor issue is that it's downloading the "latest" 2.0 source from the jitsi repository. I don't know if the jitsi stable tarballs are updated regularly, but if they are, then this would mean that using the ebuild two different times could result in two different, albeit minor, versions being installed.

2) The major issue is that the script template for loading jitsi that's included in the tarball, (resources/install/debian/jitsi.sh.tmpl), required more modifications than I knew how to do in the ebuild. So, and I know this is ugly, I ended up manually editing the file, (using the Archlinux jitsi script as a template), and copying it to /usr/bin/jitsi, after the emerge.

3) At this point I was able to get Jitsi up and running but the font it used was blocky and ugly. This is apparently a well known issue with various java implementations, so in order to get Jitsi to use my system font, I added the following hack to the jitsi shell script too;

export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on"

I'm hoping that someone who knows ebuilds can look at the ebuild and jitsi shell script, and determine the necessary edits to the ebuild to produce a clean, complete, emerge of jitsi 2.0. That way until it's in portage, we can have a current ebuild here.

Thanks..
Comment 20 Jason Lamb 2013-03-07 16:08:14 UTC
Created attachment 341234 [details]
Jitsi shell script reference in comment #19
Comment 21 Navid Zamani 2013-03-07 16:37:43 UTC
Created attachment 341238 [details]
jitsi-2.0.4506.10553.ebuild (only classpath problem left)

I also hacked up an ebuild, and it pulls and installs properly (now not pulling from the unstable live snapshots anymore).

I’ve replaced “sip-communicator” by “jitsi” in the bin/jitsi script and the whole ebuild. And I’ve fixed the directory it tried to find the jars in. (/usr/lib64/jitsi instead of /usr/share/jitsi).

It still can’t find a few classes. So it’s a minor problem. Unfortunately I don’t know how to locate files for missing classes with Java. Other than that, it would run properly.

Does anyone know how to do that?
Comment 22 Navid Zamani 2013-03-07 16:43:38 UTC
(In reply to comment #19)
> 3) At this point I was able to get Jitsi up and running but the font it used
> was blocky and ugly.

Ah, so maybe I shouldn’t have replaced *all* instances of “sip-communicator” in the ebuild, if it runs on your system, but fails to find classes on mine… :)

I’m pretty confident, that with a combination of both our ebuilds, we can get this running properly.

Also, I tried the binary installer version from the Jitsi site previously, and could not detect any font problems.
The only problem was, that it used a very lightly colored style, but still the default font colors of my OS theme… which are nearly white too! So it ended up being nearly white-on-white. I hope that’s only a problem with the binary version. Otherwise we’d have to patch the source too. :(

Stupid designers making stupid assumptions about the OS color scheme… I thought this problem was limited to form fields on the web… :/
Comment 23 Navid Zamani 2013-03-07 16:51:32 UTC
(In reply to comment #19)
> 3) At this point I was able to get Jitsi up and running

I just diffed our ebuilds, and: How did you get yours running, considering that you still have SCDIR=/usr/share/… in your …/bin/jitsi script, and all the files are installed into /usr/lib64/…? That didn’t work here.

And apart from that, only your make_desktop_entry line differed. (No point in editing commented-out lines [that …-16.xpm one]. :)

Also SRC_URI shoudln’t link to any “latest” version, but to a specific one. (Mine does that.)

So… could you tell me how you got yours up an running at all? Because your ebuild can’t do that. :/
Comment 24 Navid Zamani 2013-03-07 21:52:38 UTC
Created attachment 341266 [details]
jitsi-2.0.4506.10553.ebuild (only native libs problem left)

Okay, the jitsi.sh.tmpl is definitely outdated any messed up, as there’s no way it can work. The classpaths are all wrong, and the native libraries are not to be found (especially not at /usr/share/).

This ebuild has the proper classpaths for the three wrong libs, so only the native stuff is missing.

With no help from the developers (since the jitsi.sh.tmpl is so completely wrong), it looks like it would be a lot of guesswork, and even when it would start without errors, it could still load a dynamic lib somewhere later on, and crash or miss features.

But at least it starts. (Although without networking, camera/sound support or anything else related to hardware, it’s pretty useless.)
Comment 25 Jason Lamb 2013-03-07 22:04:53 UTC
(In reply to comment #23)
> 
> Also SRC_URI shoudln’t link to any “latest” version, but to a specific one.
> (Mine does that.)

In my opinion, that's not correct. The SRC_URI should link to a stable, specific one. If the jitsi devs update their stable 2.0 tarball to version 2.0.4507.xxxxx, then your ebuild will fail downloading the older tarball until the ebuild is updated, (or renamed). I don't think that's an optimal solution for a "stable" package.

The only stable, specific tarball that I could find, is the "2.0-latest" one. What I was trying to point out by linking to it is that the jitsi folks don't seem to produce a real 2.0 stable tarball. They seem to update their stable tarball releases in some manner similar to their nightly releases. I've not seen that before, but I'm sure that experienced Gentoo devs have, and likely have a workaround solution for it. I was basically pointing it out so that it was obvious it should be addressed somehow in the real ebuild. But as I wrote, that's a minor issue.

> 
> So… could you tell me how you got yours up an running at all? Because your
> ebuild can’t do that. :/

I pointed out why in my comment #19;

> 
> 2) The major issue is that the script template for loading jitsi that's
> included in the tarball, (resources/install/debian/jitsi.sh.tmpl), required
> more modifications than I knew how to do in the ebuild. So, and I know this
> is ugly, I ended up manually editing the file, (using the Archlinux jitsi
> script as a template), and copying it to /usr/bin/jitsi, after the emerge.
> 

So while I am able to successfully install jitsi into my system, (in /usr/lib), using the ebuild, the /usr/bin/jitsi shell script produced by the ebuild needed several edits. So I just manually edited it, using the Gentoo produced script, as well as the Archlinux shell script for jitsi, and I created a working 2.0 jitsi shell script, which I simply copied to /usr/bin/jitsi. It's the shell script attached to comment #20.

So I installed jitsi-2.0 with the ebuild, and then copied over the "emerged" /usr/bin/jitsi shell script with my own edited one. I know it's a ugly hack, but I do have jitsi-2.0 up and running.

Again I thought that an experienced Gentoo dev could look at the ebuild and my working shell script, and be able to produce the necessary ebuild commands to produce the correct working shell script during the emerge process.
Comment 26 Navid Zamani 2013-03-07 22:40:43 UTC
Created attachment 341270 [details]
jitsi-2.0.4506.10553.ebuild (only native libs problem left)

Oops, forgot to add the rest too.

That’s about all I can do. Jitsi starts, but no hardware-dependent functionality, until those libs can get loaded.

I think it’s best if we let the Jitsi guys fix their script first, or at least do it ourselves. These sed replacements are now pretty messy… and still don’t solve everything…
Comment 27 Navid Zamani 2013-03-08 00:23:40 UTC
Created attachment 341272 [details]
Error output for script by Jason Lamb

(In reply to comment #25)
Okay, I need you to completely rephrase at least the first part of your comment, from the start, as you not only misunderstood me to mean the opposite of what I meant, but contradicted yourself, agreed and then disagreed with me on the same point, and even disagreed with yourself in there… After half an hour of looking for what you meant, no consistent sense can be made out for that part, because of that. It physically hurt to parse and untangle it. Honestly. I’m sorry for being so harsh, but this is just too much to stir into any soft cake dough of any size.

I can only make out that you seem to have fundamentally misunderstood, what -latest means.
It’s a *softlink*. (The web server just doesn’t show it as one, but as a file. You still can compare the file sizes in a quick glance though.) It gets updated every time a new version comes out. So if you tell an ebuild to pull it, then wait for 2.0.(x+1) to come out, that new zip file will be added to that directory, the softlink will be changed to point to that, your ebuild will pull it instead, and will fail because stuff changed. That’s it.
“-latest” is the equivalent of -9999: Ever-changing, and the exact opposite of stable. That that is a recipe for disaster, should be obvious. You can’t have jitsi-2.0.ebuild install jitsi-2.0.0001.00001 for some users, and later on, jitsi-2.0.9402.84029 for others, both named jitsi-src-2.0-latest.zip. It would be chaos and zero bug reproducibility. If it would even compile at all. Hence it’s not suited for a ebuild, unless it’s a -9999 ebuild, which is always masked for that exact reason.

Meanwhile jitsi-src-2.0.4506.10553.zip won’t change, and will not be suddenly gone, unless the ebuild should also go away because it’s so outdated. And the ebuild version equals the exact src package version, period.

What you wanted, was apparently a 2.0.999 ebuild. Some kind of stable-version-yet-unstable-build mix. You can make that, if you want. But don’t call it jitsi-2.0.ebuild. Because that’s not what it is, as it may install something else every time.

> What I was trying to point out by linking to it is that the jitsi folks
> don't seem to produce a real 2.0 stable tarball. They seem to update their
> stable tarball releases in some manner similar to their nightly releases.

I think you’re mistaking something here, based on the above misunderstanding. 

Here now about the part which can be parsed:

> > 2) The major issue is that the script template for loading jitsi that's
> > included in the tarball, (resources/install/debian/jitsi.sh.tmpl), required
> > more modifications than I knew how to do in the ebuild. So, and I know this
> > is ugly, I ended up manually editing the file, (using the Archlinux jitsi
> > script as a template), and copying it to /usr/bin/jitsi, after the emerge.

Yes, the script seems to be really outdated and cannot work. Basically, the Jitsi devs would have to write a proper script in the first place. There’s no point in guessing and hacking our way to find how it should work. It will always end in a buggy hack.
But for a custom file, just put it in the net-{im,voip}/jitsi/files/ subfolder, and tell the ebuild to install that file instead. You can look at other packages that have such a subfolder, to see how to do that.
I’d still feel very uncomfortable with a self-hacked-up one. Things may be loaded dynamically later (e.g. camera access or something like headset button support), and then everything comes crashing down. Only the devs really know what needs to be done.

> Again I thought that an experienced Gentoo dev could look at the ebuild and
> my working shell script, and be able to produce the necessary ebuild
> commands to produce the correct working shell script during the emerge
> process.

Here’s the thing: Your shell script does not work. I just tested it here, and the attachment is what I got.
Comment 28 Jason Lamb 2013-03-08 01:12:57 UTC
(In reply to comment #27)
> 
> Here’s the thing: Your shell script does not work. I just tested it here,
> and the attachment is what I got.

As things stand now, using my ebuild and my shell script, jitsi 2.0 runs perfectly well on my system. All components work. All hardware works. I've been testing it all day.

As for everything else, I believe the points I raised are clear and self explanatory. You seem to disagree. On that we will have to agree to disagree. We do not need to discuss it further in a bug report.

On the point that we can really use a good Gentoo dev to look into building a reliable jitsi-2.0 ebuild, (and eventually get into portage), we do both agree. I believe we both have simply been trying to help in that regard.

Good Luck..
Comment 29 Navid Zamani 2013-03-08 01:22:45 UTC
Created attachment 341276 [details]
/usr/bin/jitsi

Okay, I completely reworked the jitsi run script, using all prior solutions.

Now everything works, except for what I think isn’t supposed to work either:

• It fails to initialize the ALSA device with PortAudio, when e.g. PulseAudio already uses it.
• It can’t initialize the system tray, as, as it states: “Desktop API is not supported on the current platform”

Although the second may still be a bug, not sure… I really have no “desktop” so to speak… Others else would have to test if the behavior is as expected for them.
And of course it should just use PulseAudio or whatever, not try to access ALSA directly unless instructed to. Use flags would be the right thing here. I propose… IUSE="alsa pulseaudio …" …?

All of those things however, are ebuild stuff, and outside of the scope of this script.

So I think I can declare it “working 100%” for x86_64 and and ix86 arches, except for what developers know and we cant.

What’s left, is to put it in files, and install it in the ebuild.
Comment 30 Navid Zamani 2013-03-08 01:38:18 UTC
(In reply to comment #28)
> As for everything else, I believe the points I raised are clear and self
> explanatory. You seem to disagree. On that we will have to agree to
> disagree. We do not need to discuss it further in a bug report.

In other words: You cannot actually make better sense of it either (e.g. by showing the basis it builds on that gives it sense), and do not know the rational reason why you you continue to stand behind something you now know is wrong, but you choose to do so anyway. So you propose the age-old cheap cop-out “agree to disagree” as “the only way” (for you), and wish to run away from it.

We do not agree to disagree. You continue to disagree despite a conflicting reality.

Meanwhile, I fixed your apparently non-existing bugs in the script, making that conflicting reality glaringly clear.

But that being said, indeed, now we do not have to discuss this any further.
Comment 31 Navid Zamani 2013-03-08 03:03:09 UTC
Created attachment 341278 [details]
jitsi-2.0.4506.10553.ebuild

I cleaned the ebuild and made it use the attachment 341276 [details] (put in the files dir) as binary.

It could be improved by adding IUSE flags for the various sound systems (e.g. so direct ALSA usage can be disabled) and multimedia things.
And by having a Desktop API on the platform.

Other than that, everything is now fine. (I think…)
Comment 32 Navid Zamani 2013-03-08 03:06:03 UTC
Oh and: @potential maintainers: Could you put this in portage? (The usual process, with a quick glance inside if you want.)
Comment 33 Artem Lypovetskyi 2013-03-09 11:30:35 UTC
Nothing work for me ((((

Jitsi 2.0 ebuild :
When I try ru jitsi
/usr/bin/jitsi: line 26: cd: /usr/share/jitsi: No such file or directory
Error: Could not find or load main class net.java.sip.communicator.launcher.SIPCommunicator

If I fix in /usr/src/jitsi script SCDIR to point to /usr/lib/jitsi
then I have next errors on jitsi start
Exception in thread "main" java.lang.NoClassDefFoundError: net/java/sip/communicator/util/ScStdOut
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
	at java.lang.Class.getMethod0(Class.java:2694)
	at java.lang.Class.getMethod(Class.java:1622)
	at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)
Caused by: java.lang.ClassNotFoundException: net.java.sip.communicator.util.ScStdOut
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	... 6 more

jitsi-2.0.4506.10553.ebuild:
on emerge have next error
BUILD SUCCESSFUL
Total time: 1 minute 21 seconds
>>> Source compiled.
>>> Test phase [not enabled]: net-im/jitsi-2.0.4506.10553

>>> Install jitsi-2.0.4506.10553 into /mnt/sda3/var/tmp/portage/portage/net-im/jitsi-2.0.4506.10553/image/ category net-im
!!! dobin: /usr/local/portage/net-im/jitsi/files/jitsi does not exist
...
 * QA Notice: file does not exist:
 * 
 * 	dobin: /usr/local/portage/net-im/jitsi/files/jitsi does not exist
!!! When you file a bug report, please include the following information:
GENTOO_VM=oracle-jdk-bin-1.7  CLASSPATH="" JAVA_HOME="/opt/oracle-jdk-bin-1.7.0.17"
JAVACFLAGS="-source 1.6 -target 1.6" COMPILER="javac"
and of course, the output of emerge --info
Comment 34 Konstantin (elxa) 2013-03-17 00:04:39 UTC
You have to drop the attachment "/usr/bin/jitsi" (see above or use this url https://bugs.gentoo.org/attachment.cgi?id=341276 ) into your "files" dir.
Comment 35 fgro 2013-03-18 23:11:27 UTC
(In reply to comment #34)
> You have to drop the attachment "/usr/bin/jitsi" (see above or use this url
> https://bugs.gentoo.org/attachment.cgi?id=341276 ) into your "files" dir.

Thank you for this hint. I can confirm that it worked now.
Comment 36 Zac Medico gentoo-dev 2013-05-31 06:04:57 UTC
Created attachment 349712 [details]
jitsi-2.2.4603.9615.ebuild

Version bump to 2.2.4603.9615, with other changes:

 * Use QA_PREBUILT to suppress QA warnings
 * Use patchelf --set-rpath for correct preserve-libs handling
 * Fix incorrect EPREFIX usage from jitsi-2.0.4506.10553.ebuild
 * Add client and xawt subdirectories to rpath since that's where icedtea7 installs libjvm.so and libmawt.so libraries, respectively

The /usr/bin jitsi script LD_LIBRARY_PATH setting also should have the client and xawt subdirectories:

-export LD_LIBRARY_PATH="${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$(java-config -o)/jre/lib/$jarch:/usr/lib/jni:$LIBPATH/native"
+jdir=$(java-config -o)
+export LD_LIBRARY_PATH="${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}${jdir}/jre/lib/${jarch}:${jdir}/jre/lib/${jarch}/client:${jdir}/jre/lib/${jarch}/xawt:$LIBPATH/native"

These settings are redundant, since the ebuild now uses patchelf --set-rpath. However, they may still be needed if the user has switched the active jvm with java-config.
Comment 37 Jason Lamb 2013-05-31 13:24:27 UTC
Created attachment 349724 [details]
jitsi-2.2.4603.9615.ebuild

Thanks Zac,

I edited the ebuild you provided to move the line

rm *mozembed* || die

inside the jarch=i386 loop, because as far as I could tell, those libs are only included in the 32 bit tree, and not the 64 bit tree. (If there's a better way to do that, please feel free to correct this change.)

After doing that your ebuild emerged jitsi-2.2.4603.9615 cleanly.

Jason
Comment 38 Jason Lamb 2013-05-31 13:26:53 UTC
Created attachment 349726 [details]
jitsi-2.3.4668.9744.ebuild

Anyone who wants to emerge a Jitsi 2.3 nightly build can start with this ebuild, and simply rename it to the version you would like to emerge.

Version 2.3.4668.9744 represents the current latest nightly build.

Good Luck..
Comment 39 Jason Lamb 2013-05-31 13:32:41 UTC
Created attachment 349728 [details]
jitsi /usr/bin shell script

Using the latest ebuild and placing this file into the net-im/jitsi/files directory, should provide a fully working jitsi installation.

Shell script edited to include the proper "export LD_LIBRARY_PATH" line as per comment #36.
Comment 40 Jeroen Roovers (RETIRED) gentoo-dev 2013-06-12 14:59:38 UTC
*** Bug 473012 has been marked as a duplicate of this bug. ***
Comment 41 Sander Sweers 2013-06-29 08:59:56 UTC
For version 2.2 rename the ebuild to jitsi-2.2.4603.9615.ebuild

and change line
S="${WORKDIR}/${PN}"
to
S="${WORKDIR}/${PN}-src-${PV}"
Comment 42 Jason Lamb 2013-06-29 13:17:11 UTC
(In reply to Sander Sweers from comment #41)
> For version 2.2 rename the ebuild to jitsi-2.2.4603.9615.ebuild
> 
> and change line
> S="${WORKDIR}/${PN}"
> to
> S="${WORKDIR}/${PN}-src-${PV}"

Zac's ebuild from comment #36, and my edited version from comment #37, already include this change.

Thanks..
Comment 43 Jason Lamb 2013-06-29 13:42:28 UTC
Created attachment 352240 [details]
jitsi-2.3.4700.9860.ebuild

For those who want to try the latest 2.3 nightly build, the latest tarballs no longer include the jdic-all.jar or jdic_stub.jar files. So I edited this ebuild to no longer include installing jdic_stub.jar by removing;

lib/os-specific/linux jar

I also edited the /usr/bin/jitsi shell script for launching jitsi 2.3, to no longer include;

$LIBPATH/jdic_stub.jar:$LIBPATH/jdic-all.jar
Comment 44 Jason Lamb 2013-06-29 13:45:06 UTC
Created attachment 352242 [details]
jitsi 2.3 /usr/bin shell script

This is the edited /usr/bin/jitsi shell script for the new 2.3 nightly builds. Put this into the files directory and 2.3 should emerge correctly.

You wouldn't want to use this shell script for 2.2 jitsi, just the new 2.3 nightly builds.

Good Luck..
Comment 45 Yury Katuar 2013-06-29 21:53:06 UTC
(In reply to Jason Lamb from comment #43)
> Created attachment 352240 [details]
> jitsi-2.3.4700.9860.ebuild

Ebuild fails on ~x86 with the error:
rm: cannot remove ‘*mozembed*’: No such file or directory

Without that line everything seems to be okay, thank you.
Comment 46 Jason Lamb 2013-06-29 22:09:48 UTC
Created attachment 352276 [details]
updated jitsi-2.3.4700.9860.ebuild

Good catch.

Removed unnecessary line;

rm *mozembed* || die

from jarch=i386 loop in ebuild since it's no longer included in the 2.3 tarball.

Thanks..
Comment 47 Sander Sweers 2013-07-15 19:29:51 UTC
(In reply to Jason Lamb from comment #42)
> (In reply to Sander Sweers from comment #41)
> Zac's ebuild from comment #36, and my edited version from comment #37,
> already include this change.

Meh, it is getting confusing and hard to follow. Can someone please push this into sunrise? That will make it much easier to maintain and get :)
Comment 48 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-22 19:20:17 UTC
The ebuild isn't the problem, the bundled libraries are; per policy we can not add the package this way, so, we need to unbundle most if not all of them.

To replicate, here are the steps you need to take:

1. Add JAVA_PKG_STRICT="yes" to /etc/portage/make.conf
2. Rename src_prepare to java_prepare, because we don't permit src_prepare.
3. Add to java_prepare: `find . -name '*.jar' -print -delete || die`

This way, all jar files are listed and deleted and you can see the compile errors that result when the bundled libraries are gone; all these would need to be resolved using proper dependency packages in the Portage tree before we can add this package to the Portage tree.

So, a first one that pops up in the compile errors is org.apache.tools.ant (you can Google this; also, `jar tf` can be done on a jar file to list its contents) is available in ant.jar in dev-java/ant-core.

Thus, we can put a symlink to that jar in place like so:

> pushd lib/installer-exclude > /dev/null
>     java-pkg_jar-from ant-core ant.jar apache-ant-1.7.0.jar
> popd > /dev/null

Now ./lib/installer-exclude/apache-ant-1.7.0.jar points to our system library; that way, we do no longer use the actual bundled library, just its name so we can avoid forking the build.xml unless we really have to.

Great, next dependency we see in the compile errors is org.jitsi.service.resources; oh, that looks like itself. Odd, after some searching though, it appears to be that this is libjitsi; as we don't have this in our package tree we will need to add this.

And so, bug #477780 has born. That package needs fmj; so, bug #477784 was born as well. And if that isn't enough, fmj needs mp3spi and vorbisspi; so, bug #477788 was born as well. And because this we are a few levels deep now; you can estimate the amount of packages we need to add to the Portage tree, in other words there is a lot of work to be done for this package.

Since these need Java, the Java team is happy to assist you; you can read more about Java package development at http://www.gentoo.org/proj/en/java/java-devel.xml and http://overlays.gentoo.org/proj/java/wiki

Why do we need to unbundle those? For multiple reasons, possibly more:

1. When we install bundled libraries for everything, the user ends up having a lot of libraries present multiple times on their system; this is a disadvantage. When we instead unbundle them and add them to the Portage tree; they are only present once, and they are ready to serve possibly future other consumer packages.

2. These are binary, a security concern; it also doesn't allow us to fix them.

3. We can't support bundled libraries; a problem with them, means masking and / or removal of the package.

Sorry to burst your bubble, that's what it takes to add this; unfortunate...

So, happy ebuild writing! :)
Comment 49 andros 2013-08-17 11:11:10 UTC
I have seen today an ebuild in the betagarden overlay:

http://gpo.zugaina.org/net-im/jitsi
Comment 50 Sander Sweers 2013-08-24 16:00:06 UTC
I am a (huge) novice at java ebuild writing but I have started a git repo on github with my attempt on unbundling this. If people are interested it is https://github.com/infirit/jitsi.

Feel free to fork and send pull requests or raise issues :)
Comment 51 pierigno 2013-12-12 01:14:33 UTC
Created attachment 365126 [details]
jitsi nightly build ebuild
Comment 52 Navid Zamani 2014-03-02 21:42:51 UTC
(In reply to Tom Wijsman (TomWij) from comment #48)
Hey, that is a fantastic reply.

I if there ever was a package worth it, it’s Jitsi. I tried *everything*, and this is the ONLY thing that can make fully encrypted video/audio/chat calls over XMPP, SIP, and basically anything. Including all the tunneling, echo/noise canceling, etc, and the extra mile of getting through any NAT situation.

In the current surveillance world, it’s about the only real and acceptable and working communications’ solution there is.

Soooo… If I had *any* money left, I’d even pay somebody to get this working.
Comment 53 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-03-03 23:30:21 UTC
At the moment I'm a bit busy with importing the MATE Desktop Evironment to the Portage tree, which takes a considerable amount of work; I've marked this in my mailing client to ensure I'll eventually get back to reviewing this. Maybe as a side effect of this extra bug mail another Java herd member might get interested?

(Don't misunderstand my removal from CC, I'm listening on the java@g.o alias)
Comment 54 Guillaume Horel 2014-03-07 17:56:25 UTC
I've written ebuilds for most of the dependencies of jitsi in this repo: https://github.com/thrasibule/jitsi, starting from the inial repo of Sander. Some of the ebuilds might require cleanup or might not be useful, because they need to be packaged as osgi bundle for jitsi to use them. But it should be a good start. Let me know if I should add them to the individual bugs.
Comment 55 Johann Schmitz (ercpe) (RETIRED) gentoo-dev 2014-03-07 18:18:32 UTC
To build this packages from source, we need some more packages in the tree. I've added them to the dependency list.

Also we need:

dev-java/joscar from java overlay
dev-java/laf-widget (in betagarden)
jdesktop

We should try to not build the mac potions as they need (at least) 
com.apple.eio
com.apple.eawt
org.growl4j
com.explodingpixels.macwidgets


(In reply to Guillaume Horel from comment #54)
> Some of the ebuilds might require cleanup or might not be useful, because
> they need to be packaged as osgi bundle for jitsi to use them. But it should
> be a good start. Let me know if I should add them to the individual bugs.

That's great! Please either attach the ebuilds to the open dependency bugs or link them in a comment. I will look at them if i find some time.
Before you open new dependency bugs, please check that the packages aren't already in the tree (i've moved spymemcached and httpcomponents-* from last-hope to the tree).

If you are interested to proxy-maintain some of these packages, let me know.
Comment 56 Navid Zamani 2014-03-07 18:21:47 UTC
If anyone here needs somebody else to test a fully working XMPP+OTR+Jingle+ZRTP setup, my e-mail address is also an instant messenger address.

It didn’t work with the current live ebuild, but does work with the 2.3 ebuild, which I’m using. That one doesn’t have an icon though and still many Java errors.

(BTW: Jitsi 3, which supposedly comes out before the summer, will apparently [also support Android and] ditch Java for HTML5. I don’t know which is worse though. But at least Jitsi 2 works at all. ;)
Comment 57 DrSlony 2015-03-28 14:22:42 UTC
Request for jitsi-2.8 ebuild, which was released on 2015-03-19.
https://download.jitsi.org/jitsi/windows/updates/
Comment 58 Patrice Clement gentoo-dev 2015-11-09 09:17:20 UTC
Is there someone still interested in adding this ebuild to Portage?

I've stumbled upon the betagarden overlay whilst looking around the Internetz and someone's already written an ebuild for jisti, apparently.

https://cgit.gentoo.org/proj/betagarden.git/tree/net-im/jitsi

The momentum for this package seems to have let up. If there's no actual interest, I would advise to use the overlay, and close this bug as well as its dependencies.

Please someone comment or I will proceed. Thank you.
Comment 59 darkbasic 2015-11-09 15:04:20 UTC
It would still be interesting to have jitsi 2.8.5426 in portage.
Comment 60 Patrice Clement gentoo-dev 2015-11-09 15:39:38 UTC
Alright. Are you willing to package it, or at least, give it a try?
Comment 61 DrSlony 2015-11-09 16:20:45 UTC
"The momentum for this package seems to have let up"
I don't know where you got this sentiment from.
https://github.com/jitsi/jitsi
Comment 62 Patrice Clement gentoo-dev 2015-11-09 16:38:33 UTC
(In reply to DrSlony from comment #61)
> "The momentum for this package seems to have let up"
> I don't know where you got this sentiment from.
> https://github.com/jitsi/jitsi

This bug has been open for like what, 5 years? IMHO if it hasn't made it into Portage yet, I can guarantee you it never will. We've already closed a wad of bugs like this one because interest in getting the said software into Portage "let up" over the years. Sorry for not expressing myself clearer but that's what I meant.
Comment 63 Sebastian Pipping gentoo-dev 2015-11-09 16:43:14 UTC
Maybe we should distinguish between Jitsi from sources and Jitsi from upstream binaries.  From sources is a lot more work than from binaries.  This ticket seems to be about both in a way, which maybe is a problem.

I'd be happy to help with the whole thing but it needs more hands.
Who of those subscribed to this ticket have (1) written ebuilds before, (2) use Jitsi on a regular basis through other sources on Linux and (3) would be in with developing and ebuild keeping it up to date, in a joined dedicated overlay for a start maybe?
Comment 64 darkbasic 2015-11-09 18:01:58 UTC
I did write several ebuilds, but nothing particularly complex. Unfortunately I switched my main system (the laptop) from Gentoo to Arch and I'm using Gentoo only on the desktop (which I use less), so I'm pretty sure I will not be able to finish/maintain it right now, I'm sorry.
The lack of ebuilds for software like Jitsi is one of the reasons behind my (partial) switch from Gentoo to Arch.
Comment 65 Sebastian Pipping gentoo-dev 2015-11-09 20:39:19 UTC
(In reply to darkbasic from comment #64)
> The lack of ebuilds for software like Jitsi is one of the reasons behind my
> (partial) switch from Gentoo to Arch.

For completeness, I would like to note that we seem to be talking about AUR, not core Arch here: https://aur.archlinux.org/packages/jitsi/
Comment 66 Dennis Schridde 2015-11-09 23:15:22 UTC
(In reply to Patrice Clement from comment #58)
> The momentum for this package seems to have let up. If there's no actual
> interest, I would advise to use the overlay, and close this bug as well as
> its dependencies.
> 
> Please someone comment or I will proceed. Thank you.

I currently have no pressing need for this S/W, but a year ago it was by far the best VOIP S/W around, and I doubt that changed significantly since then.
Comment 67 darkbasic 2015-11-10 09:57:11 UTC
(In reply to Sebastian Pipping from comment #65)
> For completeness, I would like to note that we seem to be talking about AUR,
> not core Arch here: https://aur.archlinux.org/packages/jitsi/

Yes of course, but I've nothing against overlays/aur: simply the Arch community is biggers which turns out to more pkbuils and much quicker updates. For example jitsi is still at 2.2 in betagarden's overlay while in aur you have 2.8.5426 and nearly same-day updates.
Comment 68 Michael 'veremitz' Everitt 2020-03-18 19:09:09 UTC
There is a working version of jitsi-bin in the pentoo overlay, which is being kept up-to-date. Are there any blockers in moving this to main tree?
Tagging @ZeroChaos for thoughts.
Comment 69 Anton Bolshakov 2020-05-14 02:05:55 UTC
FYI, the upstream started to wrap latest releases into an installer, I did not find away to unwrap it, making impossible to use jitsi-bi anymore.

So I wrote a proper ebuild recently compiling it from the source. You can grab it from our Pentoo overlay:
https://github.com/pentoo/pentoo-overlay/tree/master/net-im/jitsi

P.S. I'm not subscribed to this bug, please report any issues at our github issue  track list.
Comment 70 Volkmar W. Pogatzki 2023-08-22 08:23:03 UTC
*** Bug 574800 has been marked as a duplicate of this bug. ***