Please add an ebuild for sip-communicator. Reproducible: Always
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
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.
(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!
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
Created attachment 275963 [details] jitsi-1.0_beta1.ebuild (rev 3515)
The ebuild does not work anymore.
Nobody has a working ebuild with a more recent version (like 1.0-beta1-build.3820)?
Created attachment 306793 [details] ebuild for rev. 3820 It is a little bit ugly, relies on java 6 but seems to work.
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
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!
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
Created attachment 326892 [details] jitsi-1.1.4271.9982.ebuild Cleaned up version of the ebuild.
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.
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:)
Thanks again Guillaume, The updated ebuild emerges perfectly, and solves the revdep-rebuild issue as well.
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..
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.)
(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.
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..
Created attachment 341234 [details] Jitsi shell script reference in comment #19
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?
(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… :/
(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. :/
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.)
(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.
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…
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.
(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..
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.
(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.
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…)
Oh and: @potential maintainers: Could you put this in portage? (The usual process, with a quick glance inside if you want.)
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
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.
(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.
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.
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
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..
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.
*** Bug 473012 has been marked as a duplicate of this bug. ***
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}"
(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..
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
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..
(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.
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..
(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 :)
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! :)
I have seen today an ebuild in the betagarden overlay: http://gpo.zugaina.org/net-im/jitsi
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 :)
Created attachment 365126 [details] jitsi nightly build ebuild
(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.
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)
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.
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.
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. ;)
Request for jitsi-2.8 ebuild, which was released on 2015-03-19. https://download.jitsi.org/jitsi/windows/updates/
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.
It would still be interesting to have jitsi 2.8.5426 in portage.
Alright. Are you willing to package it, or at least, give it a try?
"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
(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.
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?
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.
(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/
(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.
(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.
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.
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.
*** Bug 574800 has been marked as a duplicate of this bug. ***
