This is the ebuild for the latest version of ejabberd. It is based on Karl-Johan Karlssons ebuild, and har just been modified slightly. The problem with this ebuild (or rather ejabberds installer) is that during the make of the binaries the installer goes out and installs files outside of the sandbox (erlang files) and this causes an access_wr error when emerging. I have not found a way to circumvent this problem other than emerging without the sandbox. So if you are going to test this ebuild (I use it on my server, no problem) then you will have to install with "FEATURES="-sandbox" emerge ejabberd". If anyone can modifiy the script so that this works I would be really happy! :) (also I still use the initd and confd from the 0.7.5 Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 65393 [details] initial 0.8.9 ebuild. Alert: Will not work in sandbox, emerge with: FEATURES="-sandbox" emerge ejabberd
Created attachment 65394 [details] initd startup script
Created attachment 65395 [details] inetrc, make ejabberd use srv records
Created attachment 65396 [details] confd
Created attachment 65397 [details] ejabberd (ejabberd internal start script)
Created attachment 65398 [details] ejabberdctl
Sandbox problems seem to be fixed from sandbox 1.2.12 and on. See also bug #101433.
Created attachment 67683 [details] New ebuild, include dep for sandbox 1.2.12 I added the check for sandbox 1.2.12 or later into the script so the sandbox problem goes away. Could someone please submit to portage since this works now?
trying to test this I have the following issue: # pwd /usr/local/portage/net-im/ejabberd # ebuild ejabberd-0.9.8.ebuild digest !!! aux_get(): ebuild path for 'net-im/ejabberd-0.9.8' not specified: !!! None !!! aux_get(): ebuild path for 'net-im/ejabberd-0.9.8' not specified: !!! None doebuild(): aux_get() error reading net-im/ejabberd-0.9.8; aborting. Kind Regards
I cannot reproduce this error here. Does it download the tar file to /usr/portage/distfiles? Any other error? What did you do exactly when you copied it in?
user error. please ignore. Sorry about that. make.conf has PORT_OVERLAY rather then PORTDIR_OVERLAY, and hence this ebuild wasn't within a portage ebuild tree thing.
Good :) Please report if further tweaks are needed to get it to run. I know that some has had problems if they start ejabberd without using the init script cuz then the spool dir gets owned by root. :)
I tried this but I just can't seem to get it to start with the init script. If I manually run /usr/bin/ejabberd with sudo and a modified /usr/bin/ejabberd to set directory and HOME it does work but I would like to run it with the init script instead. I have the same problem on two different computers, with all available versions of ejabberd. Both computers use ~x86 as their KEYWORD. The initscript writes [ !! ] every time it is executed. If I downgrade baselayout to 1.11.13-r1 it writes [ OK ] instead, but that is a lie as ejabberd dies right after start. I manually verify the owner and group of files when changning between the different versions and it seems to be ok. I did not have this problem when I installed 0.7.5 the first time and then I upgraded baselayout (and most other packages) to new versions for a few months without restarting the computer or ejabberd.
(In reply to comment #13) I can confirm that, on baselayout 1.12.0_pre8-r2 And that's definetly not local to you. I have exaclty the same problem. Permissions are all OK. I tried to find the cause but failed miserably. After starting /etc/init.t/ejabberd the only ejabberd-related thing running is epmd. But it get's weirdier. After second init.d run (without killing the epmd), the ejabberd started. I telneted on 5223, wrote nothing, then killed telnet. ejabberd died. Next time I tested ejabberd by connecting with Gossip, then reconnected - it works just fine ;) Still, the init.d script claims that it has failed, probably the return codes from erl are unusual in some way.
Created attachment 68175 [details] ebuild with some additions I've added odbc flag to support ejabberd odbc backend, changed install part so now it creates dirs at emerge, and places ejabberd binary files to erlangs lib dir i.e. in /usr/lib/erlang/lib/<module-version>. So -pa option in ejabberd and ejabberdctl can be removed
Created attachment 68176 [details] new ejabberd startup script
Created attachment 68177 [details] new ejabberdctl script
I have reinstalled the box I used as jabber server. The earlier configuration was using keyword ~x86 but this time I go with "x86". I installed the ejabberd from this bug with the modification to /usr/bin/ejabberd to use cd $HOME before erl. After some database problems that made me purge all files and have ejabberd recreate them I managed to get the init script to work. That is, it both says it starts the daemon and it does work. Well, atleast so far. Baselayout is 1.11.13-r1 but what I believe is more important is that I now use erlang-1.20.0. Alot of my configuration has changed from the non-working setup to this, but if I had a spare euro cent I would bet it on erlang. 1.20.0 is marked ~x86 and 1.20.5 is stable, but I did not want Tk (because it has X dependencies) so I went with the earlier version anyway. I believe I had 1.20.0 when I first installed ejabberd-0.7.5 and as far as I remember that worked out of the box. I don't know if I want to ask anyone to downgrade erlang to an earlier version, but if you have problems and have 1.12.5 it might be worth a shot to test it.
Why this ebuild don't add on official tree?..
I guess this is not official because it depends on bug #98452. Also the next release (currently beta upstreams) will depend on that bug. Converting this to follow jabber-base now would probably speed up the addition of next upstream version to Portage.
Also there will be a new version coming out very soon, I think when this comes out I will do some more testing and we will see if it will be accepted. I myself have no access to submit to portage, but maybe someone can take the job?
Created attachment 73368 [details] worked ebiuld It's worked ebuild. Im yusing it's on my jabber server :)
That ebuild seems very similar to the 0.7.5 ebuild and to the 0.9.8 ebuild posted previous but it does not solve the problem with jabber-base compliance.
Seems like version 1.0.0 is out now.
Created attachment 74865 [details] ejabberd 1.0.0 ebuild I just renamed Max's ebuild to the new version and upgraded my two servers without a hitch. Please report back about new installs if these works as they should. Can anyone point out more informasjon about the jabber-base compliance? I have not found any specifications about this. If there is such a thing I would like to customize the ebuild to support these specifications.
Info on jabber-base is in the ebuild: /usr/portage/net-im/jabber-base/jabber-base-0.00.ebuild Untill this is fixed to be jabber-base friendly i cannot add it to portage.
(In reply to comment #26) > Info on jabber-base is in the ebuild: > /usr/portage/net-im/jabber-base/jabber-base-0.00.ebuild > > Untill this is fixed to be jabber-base friendly i cannot add it to portage. You want the ejabberd ebuild to depend on jabber-base and then use the dirs and settings that you specify in the ebuild. Do I understand you correctly then?
You can also read bug #98542 for information about the directories. The pymsn-t ebuild in portage depends on jabber-base, but the earlier versions did not. You can compare the ebuilds in bug #88597 to the one in portage for some hints on what has to change atleast. Also, can someone please update the summary to reflect the most recent version?
I will try to look at this over the weekend, if anyone want to contribute feel free :)
i disagree to share access rights with other jabber components to be secure as we can. There is authentication mechanizm between jabber components and no need to share access rights to filesystem. And why the hell I need rw access to my configs, even from the jabber server/component account?
previous post was about jabber-base if it is not clear
Created attachment 75310 [details] ejabberd-1.0.0.ebuild alt This is my ebuild for ejabberd. Some use-flags was added and changed (a-la jabberd). May be usefull for you.
Created attachment 77499 [details] ejabberd-1.0.0.ebuild (jabber-base compliant)
Created attachment 77500 [details] files/ejabberd-1.0.0.initd (jabber-base compliant)
The new ebuild works fine (thanks Octavio!), not very happy about the spool and run dir. Fine that they are accessed by the jabber user, but should they not continue to be named ejabberd? If we have the same spool dir there will be problems if we unmerge ejabberd and then emerge jabberd later, right? Anyone agree or disagree? For info, if you would like to test the newest ebuilds and have used the old ones before then you have to rename all dirs referenced in /usr/bin/ejabberd from ejabberd to jabber, and change owner of the files to jabber:jabber. Can be a little tricky but it seems to work fine here at least.
(In reply to comment #35) > The new ebuild works fine (thanks Octavio!) :) > not very happy about the spool and run dir. Fine that they are accessed by the jabber user, but should they not continue to be named ejabberd? What about /var/run/jabber/ejabberd (${JABBER_RUN}/${PN}) and /var/spooljabber/ejabberd (${JABBER_SPOOL}/${PN}) > If we have the same spool dir there will be > problems if we unmerge ejabberd and then emerge jabberd later, right? HUmmm.. yes, i think problems will happend. So, tell me where do you think is the best place? > > Anyone agree or disagree? I can't, it's my first time using jabber daemonds but I have experience making ebuilds, so discuss it here and I will do my best until some dev take it. > For info, if you would like to test the newest ebuilds and have used the old > ones before then you have to rename all dirs referenced in /usr/bin/ejabberd > from ejabberd to jabber, and change owner of the files to jabber:jabber. Can be a little tricky but it seems to work fine here at least. Thanks for pointing that (I did'nt thinked about it) but, well that 'trick' is just for alpha-beta-bugzilla-ebuild-testers, in the tree we just have the 0.7.5 so we need to think just in the migration from that to ejabberd-1.0.0. How is done? I don't know. At least to put someinfo about that in pkg_postinst.
> > not very happy about the spool and run dir. Fine that they are accessed by the jabber user, but should they not continue to be named ejabberd? > > What about /var/run/jabber/ejabberd (${JABBER_RUN}/${PN}) and > /var/spooljabber/ejabberd (${JABBER_SPOOL}/${PN}) I do not think that we should use PN cause the spool and run dirs will be automatically updated on upgrades. I think we should use /var/run/jabber/ejabberd and /var/spool/jabber/ejabberd. Alternatively leave them at /var/run/ejabberd and /var/spoool/ejabberd like before. > Thanks for pointing that (I did'nt thinked about it) but, well that 'trick' is > just for alpha-beta-bugzilla-ebuild-testers, in the tree we just have the 0.7.5 > so we need to think just in the migration from that to ejabberd-1.0.0. Yes, the migration from 0.7.5 to 1.0.0 will be a tricy one aswell. I might be able to reproduce this if you want help in making the upgrade happen. We will need to move the spool and run (.erlang.cookie is important!) to the new dirs, change the permissions. Then it ought to work. Maybe if we decide on a dir, and start to make an upgrade for 0.7.5 I can set up a test server and the we try to upgrade it. Do you want me to patch your script or do you want to rewrite it youreself?
What's the hold up on this bug? Are we waiting for some sort of finalization on jabber-base? Or is it just a matter of fixing some problems with the attached ebuild? If the latter... what still needs to be fixed?
Created attachment 80601 [details] ejabberd-1.0.0.ebuild - jabber-base compliant rev 2 This is my edit of Octavios ebuild that was great! I just changed the spool so this will not conflict later (to /var/spool/jabber/ejabberd), I changed the ssl pem generating to only occur if the is no pem from before, also I added some warnings about use flags, and I also inserted a warning if it seemed the user was upgrading from 0.7.5 or one of the bugzilla ebuilds. This should now be working 100%, from what I can gather. It starts and works fine here on my test machine, it is jabber-base compliant and should now be added to portage under ~ is my reccomendation, pretty please? The initd is not changed so use Octavios, but I added a confd, just renamed cus the old one was fine.
Created attachment 80602 [details] files\ejabberd-1.0.0.confd
I'm really looking forward to this "bug" being resolved. ^_^ In the meanwhile -- what about incorporating the patch for MUC HTML logging (assign some local USE flag for this?) http://www.jabber.ru/bugzilla/show_bug.cgi?id=10 Just an idea. Keep the hard work. ^_^
Yes this is a great idea, the patch does not apply cleanly for 1.0.0 now so I will talk to badlop to get this sorted and then I will add this. But I think maybe the patch should just be default, and not with use flag. Also I think we should add mod_statsdx, I use this myselft and it is very stable, and maybe we should add a use flag for the mysql patch. I will talk to badlop and see, if this ebuild comes into portage in the meantime we can make a new -r1 or something. :)
Created attachment 80892 [details] net-im/ejabberd - revision 3, with muc_log and stats patches New ebuild which adds support for mod_muc_log, statsdx and stats2file. The cfg.example has also been updated with this information.
Created attachment 80893 [details, diff] files/ejabberd_cfg.patch This patch updates the ejabberd.cfg.example with information for MUC logging, statdx and stats2file.
Created attachment 80894 [details, diff] files/ejabberd_web_admin.erl.statsdx.patch This patch adds the statsdx menu to the web admin of ejabberd.
Created attachment 80895 [details, diff] files/muc_log_1.0.0_eightrev.patch This patch adds logging capabilities to the muc module.
Created attachment 80896 [details] files\mod_statsdx.erl This is the statsdx module.
Created attachment 80897 [details] files/mod_stats2file.erl This is the stats2file module.
This bug is a real mess with files and files. Can please someone send me a mail with a tar.gz of the portage files that they know work and maybe some fast notes on setting up ejabberd so that i can test/commit this?
Here is a tar.bz2 for all to test! :) http://www.jabber.no/ejabberd-1.0.0.tar.bz2
* Service ejabberd starting [ !! ] * ERROR: ejabberd failed to start It actually started but reported as fail
You must provide more information. The thing with ejabberd is that it uses ejabberdctl to start and stop en server. You need to try and kill the process and then start it again. The problem I often see is that you try and start the server as root and then the .erlang.cookie gets r for only root, and then you get a bad error from ejabberdctl. chowning jabber:jabber /var/run/jabber/.erlang.cookie is a good thing to try. Please also try to run the start script from /usr/bin/ejabberd to see what the output is. Also do this as the jabber user.
I did once made the mistake causing erlang.cookie owned by root. But at the moment erlang.cookie is owned by jabber:jabber (600). What do you want me to run from jabber account? Running ejabberd without any parameter gives me an erlang shell. Don't know what to do from that.
By the way, i had installed jabberd-2.0 before installing ejabberd, so jabber:jabber was created by jabberd not ejabberd
Created attachment 81458 [details] ejabberd-1.0.0-r1.ebuild Added fix for SRV-DNS (zeroconf), some QA issues, etc.
Created attachment 81459 [details] ejabberd-1.0.0-r1.confd
Created attachment 81460 [details] ejabberd-1.0.0-r1.initd
Sorry for the noise, saw to late, that there are sensible ebuilds now.
PostgreSQL support is currently BROKEN with the way the ebuild is now. We need postgresql module from http://jungerl.sf.net Unfortunately, it's apparently CVS-only code. See http://www.pgmillard.com/blog/?p=74
Created attachment 81533 [details] dev-erl/pgsql-cvs-9999
Doesn't one of ebuild above work somewhere ? I tried all and all build 50 % of things : - No ejabberd, ejabberdctl installed - No init.d/conf.d files Very strange.
Ignore previous message ;) Too tired. Sorry
1.1.0 came out today, shall we bump this bug to say "1.1.0" or start a new one?
May be commit 1.0.0 to portage tree?
Yeah, what's keeping 1.0.0 from being committed? Is there still something wrong with the ebuild (etc) attached, or are we just waiting on something with jabber-base?
Created attachment 85639 [details] ejabberd-1.1.0 ebuild This is the ebuild from BMG that I have just renamed and tested. It works fine for me on two servers without problems. Now ejabberd has muc logging integrated too, so the only patches not included are the stats patches, this could be added if anyone wants them.
Created attachment 85640 [details] files\ejabberd-1.1.0.confd
Created attachment 85641 [details] files\ejabberd-1.10.initd
Yes, please commit, the ebuilds are now jabber-base compliant and everything. At least 1.0.0 to stable and 1.1.0 to arch :)
Yes, but before that, please test native postgresql support and do something with dev-erl/pgsql-cvs-9999 (I couldn't make it work on AMD64 a while back) or remove posgresql support completely. http://www.pgmillard.com/blog/?p=74 Someone could also try native mysql support in 1.1.0. http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver There could also be warning in pkg_postinst, that some features like shared roster work (AFAIK) only with the built-in Mnesia database.
There is 1.1.1 bugfix release already. (Shall we place bets on when ejabberd is updated in Portage? I think some time around 2.5.1...)
If it's not already apparent, the ebuild for 1.1.0 works for 1.1.1 without any trickery.
Created attachment 85749 [details] ejabberd-1.1.1.ebuild I think this ebuild got a better chance of installing files in the proper locations. Fixes comments, duplicate line and escaped \ in /etc/bin/ejabberd, /etc/jabber/inetrc and uses use_enable where possible. I do not use ldap or postgres so I have no idea wether those parts, including depends, are reasonable.
For USE=postgres, a native PostgreSQL-driver for erlang is needed. Will update an ebuild soon, also I'd managed to get native mysql up and running. So you can wait for some days to give me time for cleanups and loving. After all, we will have some 1.1 ebuilds which fits Gentoo's QA-targets much better than the current one.
ejabberd-1.1.1.ebuild: fowners jabber:jabber /etc/ejabberd/ssl.pem Should be: fowners jabber:jabber ${JABBER_ETC}/ssl.pem Still can't get S2S SSL encryption working, though. Also I don't know why, but all my Jabber dirs (/var/spool/jabber, /var/run/jabber) had root:root permissions (clean install, first time jabber-base & erlang on this system). Also ejabberdctl doesn't work for me. spike411@itsuki ~ $ sudo ejabberdctl {"init terminating in do_boot",{badarg,[{ets,match_object,[ejabberd_ctl_cmds,'_']},{ets,tab2list,1},{ejabberd_ctl,print_usage,0},{ejabberd_ctl,start,0},{init,start_it,1},{init,start_em,1}]}} Crash dump was written to: erl_crash.dump init terminating in do_boot () See this http://ejabberd.jabber.ru/node/143 My ejabberdctl (generated by the ebuild) looks like this: itsuki spike411 # cat /usr/bin/ejabberdctl #!/bin/sh exec env HOME=/var/run/jabber \ erl -pa /usr/lib/erlang/lib/ejabberd-1.1.1/ebin \ -noinput \ -sname ejabberdctl \ -s ejabberd_ctl \ -extra $@
(In reply to comment #75) > Also ejabberdctl doesn't work for me. > spike411@itsuki ~ $ sudo ejabberdctl > {"init terminating in > do_boot",{badarg,[{ets,match_object,[ejabberd_ctl_cmds,'_']},{ets,tab2list,1},{ejabberd_ctl,print_usage,0},{ejabberd_ctl,start,0},{init,start_it,1},{init,start_em,1}]}} > > Crash dump was written to: erl_crash.dump > init terminating in do_boot () You have to provide the node to ejabberdctl. Try: ejabberdctl ejabberd@`hostname`
(In reply to comment #76) > (In reply to comment #75) > > Also ejabberdctl doesn't work for me. > > spike411@itsuki ~ $ sudo ejabberdctl > > {"init terminating in > > do_boot",{badarg,[{ets,match_object,[ejabberd_ctl_cmds,'_']},{ets,tab2list,1},{ejabberd_ctl,print_usage,0},{ejabberd_ctl,start,0},{init,start_it,1},{init,start_em,1}]}} > > > > Crash dump was written to: erl_crash.dump > > init terminating in do_boot () > > You have to provide the node to ejabberdctl. Try: > ejabberdctl ejabberd@`hostname` > You're right. But the error message in this case should be something useful, not erlang dump. :/ Probably upstream problem?
As I promised, there are some working and QA'd ebuilds for Gentoo. I'm unwilling to upload all the files, because they are a part of BreakMyGentoo. You need the following parts: Ejabberd: http://svn.breakmygentoo.net/bmg-main/net-im/ejabberd/ New native MySQL-backend (USE-flag mysql): http://svn.breakmygentoo.net/bmg-main/dev-erl/mysql/ A bit elder native PostgreSQL-backend (USE-flag postgres): http://svn.breakmygentoo.net/bmg-main/dev-erl/mysql/ If you want to use MySQL as backend, create a database with the scheme from /usr/share/doc/ejabberd-1.1.1/mysql.sql, and add the following line to your config: {auth_method, odbc}. {odbc_server, {mysql, Server, Database, Username, Password}}. Also it seems to be, ejabberd does *not* use ODBC there, they are using the native MySQL-driver. Way to use PostgreSQL is similiar.
> A bit elder native PostgreSQL-backend (USE-flag postgres): > http://svn.breakmygentoo.net/bmg-main/dev-erl/mysql/ I get that feeling that this is a typo.
Sorry, you're right. URL is: http://svn.breakmygentoo.net/bmg-main/dev-erl/pgsql-cvs/
Created attachment 86364 [details, diff] connection encoding setting for mysql And here is the patch that makes database content more determinated.(because on mysql5 there was double conversion to utf8 without it)
Patch should be applied dependant on the installed MySQL-version or what do you think?
(In reply to comment #78) > As I promised, there are some working and QA'd ebuilds for Gentoo. I'm > unwilling to upload all the files, because they are a part of BreakMyGentoo. > You need the following parts: # Create /usr/sbin/ejabberd cat <<EOF > ${T}/ejabberd # Create /usr/ejabberdctl cat <<EOF > ${T}/ejabberdctl dobin ${T}/ejabberdctl dobin ${T}/ejabberd Even though these are just comments, I feel they should be corrected to reduce confusion. Any reason use_enable should not be used?
No, use_enable is a good idea ;-)
Included the fix by Albert Holm, when MySQL-version >=4.1, did some rework with use_enable.
Forgot the link, sorry: http://svn.breakmygentoo.net/bmg-main/net-im/ejabberd/
(In reply to comment #86) This seems to be the wrong way around or should odbc be disabled if one of these use flags is used? if use mysql || use postgres || use odbc; then myconf="--disable-odbc" fi Both ejabberdctl and ejabberd are installed into /usr/bin/, even though the comments in the creation of the files claims they aren't. # Create /usr/sbin/ejabberd # Create /usr/bin/ejabberdctl dobin ${T}/ejabberdctl dobin ${T}/ejabberd
You're damn right. It's fixed.
(In reply to comment #82) > Patch should be applied dependant on the installed MySQL-version or what do > you think? > You can check it on 4.1 :), but as followed from MySQL manual it should work. btw, why not just use --enable-odbc instead of disabling it and running make manually instead of using main Makefile?
Good hint. --enable-odbc is used from now on.
I'm getting this error when I try to compile v 1.1.1 with mysql patch: openssl found in /usr/local/ssl configure: creating ./config.status config.status: creating Makefile config.status: creating mod_muc/Makefile config.status: creating mod_pubsub/Makefile config.status: creating web/Makefile config.status: creating stringprep/Makefile config.status: creating tls/Makefile config.status: creating odbc/Makefile config.status: creating ejabberd_zlib/Makefile make: unrecognized option `--enable-odbc' emerge info Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.6-r3, 2.6.13-gentoo-r5 x86_64) ================================================================= System uname: 2.6.13-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.14 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -ftracer -frename-registers -fweb -maccumulate-outgoing-args" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe -ftracer -frename-registers -fweb -maccumulate-outgoing-args" DISTDIR="/users/tnt/ftp/gentoo/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://mirror.etf.bg.ac.yu/gentoo/" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 aalib acpi apache2 avi berkdb bitmap-fonts bzip2 cli crypt cups curl dri dts dvb eds emboss encode exif expat extensions ffmpeg fortran freetype gd geoip gif gmp gpm gstreamer gtk2 httpd idn imagemagick imap imlib iproute2 isdnlog jabber jpeg libwww lm_sensors logrotate lzo lzw lzw-tiff maildir mhash mod mp3 mpeg mysql ncurses nptl nptlonly odbc ogg oggvorbis pam pam-mysql pcre pdflib perl php png pppd python quicktime readline reflection rrdtool samba sasl sdl session slang snmp spell spl ssl stream tcpd theora threads tiff transcode truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis wmf xml2 xorg xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Please use the version from BreakMyGentoo's SVN. My last ebuild there is broken and not up-to-date. By the way: what's on with it, can we get http://svn.breakmygentoo.net/bmg-main/net-im/ejabberd/ejabberd-1.1.1.ebuild to portage?
(In reply to comment #92) > Please use the version from BreakMyGentoo's SVN. My last ebuild there is > broken and not up-to-date. > By the way: what's on with it, can we get > http://svn.breakmygentoo.net/bmg-main/net-im/ejabberd/ejabberd-1.1.1.ebuild to > portage? if ! use mysql && ! use postgres && ! use odbc; then myconf="--disable-odbc" else myconf="--enable-odbc" I feel this is expressed in a more complicated way than expected. If the shorthand notation "( use mysql || use postgres || use odbc ) && myconf="--enable-odbc" || myconf="--disable-odbc"" is not readable, then I think it should be rewritten to remove negations. From ChangeLog: 07 May 2006; Lars Strojny <lars@strojny.net> ejabberd-1.1.1.ebuild: Added fix by Albert Holm <albert+gentoo-bugzilla@cdr.se> for "SET NAMES 'utf8'" during MySQL-connect. Did some cleaning. I think you mean Max Loparyev.
--enable-roster-gateway-workaround This must not be enabled to get an XMPP compliant installation. As far as I can find out from discussions with ejabberd experts only JIT will benefit from enabling this. Maybe some local use for JIT to enable this?
Do you have some references to read things about? Having this option is a "tribute" to the current ebuild in portage.
is it possible to add the statsdx-patch to the ejabberd-1.1.1 (svn) ebuild from breakmygentoo.net? Their ebuild works perfectly for me.
I will take a look at it. Good idea.
I will be attaching a cumulative ebuild shortly. Please note that the copyright header has been changed to meet policy. If any contributors do not agree to the copyright change, please speak up. (In that case, the ebuild will not be used and I will have to write a new one from scratch) Note that both database engines that have been suggested can not be merged in their current form. PostgreSQL is CVS code which will have to be snapshotted. Please submit a separate bug to get this merged. The MySQL backend code makes reference to a COPYING file, which is missing. A tarball will have to be created with the relevant files and the license, which can be uploaded to the Gentoo mirrors. Please address the licensing issue and submit a separate bug to get this merged once ejabberd makes it to the tree. I apologize for the radio silence that you have experienced, and appreciate the fact that the initial feedback may not be as positive as you hoped for. I am attempting to acquire maintainership of this package and hope that we can get 1.1.1 in the tree as soon as possible.
Created attachment 88427 [details] ejabberd-1.1.1.ebuild (policy compliant; DB engines removed) Ebuild as discussed. Obsoleting some older attachments in an attempt to keep everything readable.
Changing the copyright is completely ok. You can take a look at http://svn.breakmygentoo.net/bmg-main/dev-erl/ and merge this ebuilds also.
I would like to report that the current ebuild does not result in a working install. It appears that some chown'ing is required before the program will actually start & log properly. Lars, as mentioned the current dev-erl ebuilds are not acceptable for inclusion. I suggest that we leave these until later, and that you file separate bugs for them once 1.1.1 is merged.
Permission problem is not down to this package. Reported as bug #135764. Could anyone please explain what the stats patches do and what their license is? Testing is appreciated, please be sure that you have jabber-base-0.01
While testing, please note that the ebuild *incorrectly* depends on version 0.00 of jabber-base. Change =net-im/jabber-base-0.00 to >=net-im/jabber-base-0.01 This will be addressed in an updated ebuild to which I hope to add the stats patches that are still relevant. Awaiting clarification of functionality & license.
Why are DB engines removed? So I can't use MySQL anymore?
(In reply to comment #104) > Why are DB engines removed? > So I can't use MySQL anymore? > You can use any database for wich you can get odbc drivers.
(In reply to comment #104) > Why are DB engines removed? As previously mentioned in comment #98: Note that both database engines that have been suggested can not be merged in their current form. PostgreSQL is CVS code which will have to be snapshotted. Please submit a separate bug to get this merged. The MySQL backend code makes reference to a COPYING file, which is missing. A tarball will have to be created with the relevant files and the license, which can be uploaded to the Gentoo mirrors. Please address the licensing issue and submit a separate bug to get this merged once ejabberd makes it to the tree. It is possible for you to address the MySQL issue. All you have to do is provide me with the tarball.
(In reply to comment #103) > This will be addressed in an updated ebuild to which I hope to add the stats > patches that are still relevant. Awaiting clarification of functionality & > license. Please note that I am planning to roll a new ebuild and merge fairly soon. As such, a separate bug will have to be filed for the stats patches unless their functionality and license are detailed as asked.
Sufficient notice has been given and no clarification of the patches has been provided. As such they will not be on the initial ebuild. Do feel free to open a separate bug for: - additional patches - MySQL integration - Postgres integration However, please do address the issues raised here (clarification of functionality & license) before doing so. A thank you to all contributors for their efforts, and I apologize again for the delay in getting this merged.
I can't help on the licensing questions, but I'd like to note that, using the BMG ebuild (modified to use jabber-base-0.01), epmd doesn't shut down on "ejabberd stop". The beam processes go away, but epmd sticks around. I'm using an external auth program, if that's related.
epmd belongs to erlang rather than ejabberd itself. I'm not sure what effect killing it might have, supposing there were some other erlang process running.
