The ebuild section if use amd64 ; then cd ${S} unpack swt-3.0-linux-gtk-amd64.zip cd ${WORKDIR} fi should be removed. If emerging on a system where a previous version has been installed (and swt-3.0... has not been removed from $DISTFILES) it causes the older SWT bindings to overwrite some files which are contained in the main azureus tar.bz2 file. This can cause subtle breakage. If an older version has not been installed the ebuild simply fails because it cannot find swt-3.0-___.zip (and doesn't attempt to download since it's no longer a dependency). Cheers,
after removing that section, azureus hangs after completing the wizard with the following exception: DEBUG::Fri Nov 05 23:53:24 EST 2004 java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:489) at java.lang.Integer.parseInt(Integer.java:518) at org.gudy.azureus2.ui.swt.config.wizard.NatPanel$2.handleEvent(NatPanel.java:156) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:973) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:997) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:978) at org.eclipse.swt.widgets.Text.gtk_changed(Text.java:915) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1190) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3160) at org.eclipse.swt.internal.gtk.OS.g_signal_emit_by_name(Native Method) at org.eclipse.swt.widgets.Text.gtk_commit(Text.java:936) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1218) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3166) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(Native Method) at org.eclipse.swt.widgets.Display.eventProc(Display.java:902) at org.eclipse.swt.internal.gtk.OS.gtk_main_iteration(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2361) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.<init>(SWTThread.java:70) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:45) at org.gudy.azureus2.ui.swt.mainwindow.Initializer.<init>(Initializer.java:181) at org.gudy.azureus2.ui.swt.Main.<init>(Main.java:71) at org.gudy.azureus2.ui.swt.Main.main(Main.java:115)
That hang should probably just be reported upstream; the current changelog for the future 2.2.0.1 contains this: BUGFIX: UI | Old language files in user dir causing !missing! item texts BUGFIX: UI | Fix for window state not being remembered between sessions BUGFIX: UI | Fix for messages window being closed while animated BUBFIX: UI | Fix for BUG 1059432 : Download bars spawning multiple times when set to auto open Nothing in there appears to relate directly to the hang you're seeing, so it's a good bet the maintainers haven't noticed it yet. I'm guessing that there are other reasons that the maintainers chose to include SWT build 3106 instead of the older 3.0 version, so I *don't* think going back to swt-3.0.___.zip is a good idea (i.e. I still think the section should be removed and the dependencies kept as they are).
could you try if motif version runs on amd64 see bug #71348
I have no idea about the Motif version, but the SWT/GTK version works fine for me. The ebuild still needs to have the aforementioned section removed, though. The swt-3.0-linux-gtk-amd64.zip file is (correctly) no longer listed in the SRC_URI. There are two distinct situations: 1) swt-3.0-...zip has been downloaded before and is in /usr/portage/distfiles: This causes subtle breakage because the old SWT bindings from the zip file overwrite the ones bundled with the newer azureus version. 2) swt-3.0-...zip has NOT been downloaded before: This causes the ebuild to fail with an error message stating that swt-3.0-...zip cannot be unpacked. In short: Please remove the offending section from the ebuild, it causes the ebuild to fail. (This is still relevant for the 2.2.0.2 ebuild)
Created attachment 46512 [details] working azureus-bin ebuild removed the lines specified at the start of the bug
Why not add swt-3.0-linux-gtk-amd64.zip to the SRC_URI definition for amd64 so that the file is retrieved prior to building? After manually downloading the file, azureus-bin builds and runs fine for me.
bug #76882 is a dup of this and has a patch to add swt to the SRC_URI. I used this patch and it installed and runs fine so far. Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.2, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r9 x86_64) ================================================================= System uname: 2.6.9-gentoo-r9 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 7 2005, 19:25:08)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.6.3, 1.4_p6, 1.7.9-r1, 1.8.5-r3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1, 2.15.90.0.1.1-r3, 2.15.92.0.2-r2 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O -fPIC" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O -fPIC" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ http://mirrors.tds.net/gentoo ftp://mirrors.tds.net/gentoo" LANG="en_US" LC_ALL="en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 16bit 3ds X X509 Xaw3d a52 aac aalib acpi aim alsa amd apache2 arts artswrappersuid audiofile bash-completion beepmp berkdb bigger-fonts bitmap-fonts bluetooth bmp bonobo bootsplash bzlib cddb cdparanoia cdr cgi chroot codecs crypt cscope css cups dillo directfb divx4linux doc dvd dvdr dvdread emacs encode esd ethereal evo f77 fam fbcon flac font-server fortran freetype gb gd ggi gif gimpprint gnome gpm gstreamer gtk idea imagemagick imlib ipv6 java javascript jp2 jpeg junit kde libwww lirc lzw lzw-tiff mad maildir matroska mbox mikmod motif mozcalendar mozilla mp3 mpeg mpeg4 mplayer multilib multislot mysql mythtv nas ncurses nls nvidia offensive oggvorbis opengl oss pam parse-clocks pdflib perl php plotutils png ppds python qt readline rtc samba sdl slang snmp sqlite ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales winbind xanim xine xml xml2 xmms xosd xpm xrandr xv xvid xvmc zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, PORTDIR_OVERLAY
I'm not sure I understand why some of you are having problems with the SWT included with azureus itself. The only problems I've had with the azureus GUI stopping responding have been related to having too little heap reserved for the JVM (you can check your ~/.xsession-errors to see if this might be the case for you). Lots of exceptions from the azureus core may cause the GUI to become unresponsive and it shouldn't be assumed that the SWT version is the problem... Of course, it still might be... On that note... maybe the 'official' /usr/bin/azureus script should be changed? Mine currently says java -Xmx250m -cp $CLASSPATH -Djava.library.path="${AZDIR}" ... but the ideal solution would be if one (as an ordinary user) could have a setting in ~/.Azureus/gentoo.config to change it. Maybe just add a variable JAVA_OPTIONS or something like that? I've previously had problems with the default value with lots of active torrents, but have not had any problems with 250M.
The ebuild misses an SRC_URI entry for swt-3.0-linux-gtk-amd64.zip. This file can, for instance, be found at http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.0-200406251208/swt-3.0-linux-gtk-amd64.zip.
1) ebuild azureus-bin-2.2.0.2.ebuild test returns the following: ---------------- : command not foundn/ebuild.sh: line 4: .eclass: No such file or directoryne 1458: /usr/portage/eclass/eutils !!! ERROR: net-p2p/azureus-bin-2.2.0.2 failed. !!! Function inherit, Line 1459, Exitcode 1 .eclass in inherit()sr/portage/eclass/eutils !!! If you need support, post the topmost build error, NOT this status message. aux_get(): (0) Error in net-p2p/azureus-bin-2.2.0.2 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug) : command not foundn/ebuild.sh: line 4: .eclass: No such file or directoryne 1458: /usr/portage/eclass/eutils !!! ERROR: net-p2p/azureus-bin-2.2.0.2 failed. !!! Function inherit, Line 1459, Exitcode 1 .eclass in inherit()sr/portage/eclass/eutils !!! If you need support, post the topmost build error, NOT this status message. aux_get(): (0) Error in net-p2p/azureus-bin-2.2.0.2 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug) doebuild(): aux_get() error reading net-p2p/azureus-bin-2.2.0.2; aborting. ---------------- 2) gvim marks everything red after line 36 (PROGRAM_DIR="/usr/lib/${MY_PN}" ) 3) my emerge info: ---------------- Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.20041102-r1, 2.6.11 i686) ================================================================= System uname: 2.6.11 i686 AMD Athlon(tm) XP Processor Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 8 2005, 00:23:05)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.inode.at" 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="x86 3dnow X alsa apm avi berkdb bitmap-fonts bonobo cdr crypt cups curl divx4linux emboss encode esd exif fam flac font-server foomaticdb fortran ftp gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jpeg junit libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline real samba sdl spell sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS ----------------
I can confirm comment #10. Commenting out the following lines in the existing ebuild works for me: # if use amd64 ; then # cd ${S} # unpack swt-3.0-linux-gtk-amd64.zip # cd ${WORKDIR} # fi
Created attachment 55754 [details, diff] patch to remove the amd64 offending lines minimal patch for azureus-bin-2.2.0.2.ebuild removes the offending lines, seems to fix the problem, multiples times confirmed, also tested on Bug #76882, suggest to commit in portage ?
Fixed in portage, thanks for help.
