X86, please consider 1.1.1 for the stable keyword. It has been in portage for over a month with no significant issues to report. AMD64, as this was a major version bump your keyword got dropped. Would you consider the ~amd64 seal of approval please? SPARC, same story as amd64. Please consider for ~sparc.
Arch CC contraption likes to pretend it added arches instead of actually doing it.
1) emerges fine 2) passes collision test 3) only compilation test Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 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-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="x86 3dnow 3dnowext X Xaw3d a52 alsa arts artworkextra asf audiofile avi bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evo exif expat fam fat fbcon fdftk ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia ogg opengl pam pcre pdf pdflib perl plotutils pmu png ppds pppd preview-latex print python qt qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU video_cards_radeon video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
x86 stable ^.^;;
This builds and installs on sparc, but I am unable to get it to start cleanly. I don't know if this is Related to Bug 145373 or to something else: when I try to '/etc/init.d/ejabberd start' I get the same [!!] as reported in 145373, but I am not left with anything running. If I start by hand --- HOME=/var/run/jabber ejabberd It drops me into a prompt, thus: Erlang (BEAM) emulator version 5.4.6 [source] [threads:0] Eshell V5.4.6 (abort with ^G) (ejabberd@lacewing)1> and gives a few error messages like this one: ========================= =ERROR REPORT==== 20-Sep-2006::18:23:44 === E(<0.39.0>:gen_mod:47): {undef,[{mod_irc,start,["lacewing",[]]}, {gen_mod,start_module,3}, {lists,foreach,2}, {ejabberd_app,start,2}, {application_master,start_it_old,4}]} ========================= but seems to be running. If I comment mod_irc, mod_muc, and mod_pubsub out of the .cfg file, then starting by hand seems to work, but the /etc/init.d/ejabber script still does not start anything. Since I can't figure out how to start it, I can't keyword it, and so am leaving this to someone who actually uses the package.
I'll note further that if I force chown jabber:jabber /var/run/jabber/.[ek]* then '/etc/init.d/ejabberd start' does actually start as noted in Bug 145373 but it still gives [!!] status. So still no ~sparc until this gets straightened out or explained as OK.
Continuing on sparc with a fresh install of -1.1.1 on a different system after editing the /etc/jabber/ejabberd.cfg to something matching how I would run ejabberd. First, at the end on the install, there is a claim: ============================================ * A script to generate a ssl key has been installed in * /etc/jabber/self-cert.sh . Use it and change the config file to * point to the full path ============================================ This is not true. In this case, the init.d script does seem to start ejabberd, but it still gives [!!] status. I believe everything is probably working, but still am holding off keywording until the init.d script is corrected (and the self-cert.sh note mentioned above is turned into something true). Of course, anyone using -1.1.1 successfully on sparc can keyword it for you, but based on my experiences, I am not going to at this point.
Created attachment 97745 [details] ejabberd crash dump I get the above crash dump after starting ejabberd on amd64
Tony, please readd amd64 once the issue mentioned comment 7 is fixed or when you need more info.
Ferris, both should be fixed in 1.1.1-r1. Simon, as just discussed on IRC I'll put that CC right back on as 1.1.1-r1 was released today which should be a lot nicer on this point.
I have been running ejabberd-1.1.2-r1 on amd64 for two weeks with no problems to this point.
Works fine on amd64.
Please add (stable or unstable) amd64 keyword to current ebuilds. Runs for a long time now on amd64 with no arch-specific problems.
AMD64, please keyword, several people confirm that things work for them.
Keyworded ~amd64. Closing...
