Opera, Inc. has released the first 9.50 alpha to the public this Tuesday, and I have made some massive changes to the ebuild to make www-client/opera-9.50_alpha1567 work for x86. For instance, I needed to make several changes to the ebuild to accomodate changes in the upstream tarball. Notably, Opera produced double the usual number of intel-linux tarballs. Other than that, this version of Opera is the first to have: 1) a native x86_64 version[1] which needs thorough testing; 2) improvements in *BSD compatibility which might make the ebuild fail or which might make some of the x86-fbsd hacks redundant. 3) some funky new variants for x86 - we used to have a 5 and a 6 in [2], but now a 9 and a 10 version have been added. ad 1) Both of these need testing. amd64 needs to check whether the new version can do away with the 32-bit compat dependencies. I assume they aren't needed anymore so I have adjusted the "use amd64" bits in the ebuild accordingly, except for where it really comes down to setting *DEPEND. Someone with the appropriate hardware will need to check whether Opera links properly with the following: media-libs/libexif app-text/aspell =x11-libs/qt-3* ad 2) There are several changes for BSD users: - There's a new amd64-freebsd variant[3] (but there is no applicable Gentoo arch yet?). - The intel-freebsd variant might have some changes that need to be reflected in the ebuild. I cannot even begin to predict whether the current ebuild still works for x86-fbsd. So please unmask and emerge for your arch and let me know how Opera 9.50 is doing. [1] http://snapshot.opera.com/unix/9.50-Alpha-1/x86_64-linux/ [2] http://snapshot.opera.com/unix/9.50-Alpha-1/intel-linux/ [3] http://snapshot.opera.com/unix/9.50-Alpha-1/amd64-freebsd/
The .9 works fine on x86, so we are out of here...or is there more to do? Just readd. It is still very alpha though...
--- ~amd64 --- www-client/opera-9.50_alpha1567 - USE: -qt-static -spell gnome 1: emerges 2: passes collision-protect, (multilib-)strict, test 3: works (short browsing test) Portage 2.1.3.7 (default-linux/amd64/2007.0/desktop, gcc-4.2.0, glibc-2.6.1-r0, 2.6.22-gentoo-r3 x86_64) ================================================================= System uname: 2.6.22-gentoo-r3 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ Gentoo Base System release baselayout-2.0.0_rc4 Timestamp of tree: Unknown distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.5.1-r2 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 2.0.0_rc4 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18 sys-devel/gcc-config: 1.4.0-r2 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -ggdb -march=athlon64 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/gentoo-release /etc/init.d /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -ggdb -march=athlon64 -pipe -msse3" DISTDIR="/var/portage/distdir" FEATURES="buildpkg ccache collision-protect distlocks fixpackages installsources metadata-transfer multilib-strict parallel-fetch sandbox sfperms splitdebug strict unmerge-orphans usepkg userfetch" GENTOO_MIRRORS="http://ds.thn.htu.se/linux/gentoo http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mirror.switch.ch/mirror/gentoo/ http://trumpetti.atm.tut.fi/gentoo/" LANG="en_US.utf-8" LINGUAS="en sv" MAKEOPTS="-j4" PKGDIR="/var/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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/kde /usr/portage/local/private" SYNC="rsync://dx/gentoo-portage" USE="3dnow 3dnowext X a52 aac acpi aiglx alsa amd64 arts asf avi bash-completion berkdb bitmap-fonts branding browserplugin cairo ccache cdr cli cpudetection cracklib crypt cscope css cups cvs dbus divx divx4linux dlloader dri dvd dvdr dvdread eds emboss encode esd evo fam ffmpeg firefox flac foomaticdb freetype gdbm geoip gif gimp gmedia gnokii gnome gpm gstreamer gtk hal http iconv ieee1394 imap imlib ipv6 isdnlog java javascript jfs jpeg kde kdeenablefinal kdehiddenvisibility kdepim kerberos logitech-mouse mad madwifi maildir midi mikmod mmx mmx2 mmxext mono mozbranding moznopango mozsvg mp3 mpeg mplayer msn mudflap ncurses nls nptl nptlonly nsplugin ntfs nvidia obex ogg oggvorbis opengl openmp oss pam pcre pdf pdflib perl png ppds pppd python qt qt3 qt3support qt4 quicktime readline realmedia reflection reiserfs samba scanner sdl session smp spell spl sse sse2 ssl subversion svg symlink tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb v4l v4l2 vim-syntax vim-with-x visualization vorbis wifi wmf wmp wxwindows xcomposite xface xfs xine xinerama xml xorg xosd xpm xprint xv xvid zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="mouse keyboard evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en sv" USERLAND="GNU" VIDEO_CARDS="nv nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
This isn't a keyword request. :)
two things I noticed: 1. it doesn't depend on exif, aspell and jpeg on amd64 and doesn't depend on qt on any arch except x86 2. is there anything known wrt qt-static on amd64? else we'd have to mask that USE flag also the operapluginwrapper seems to be extremely segfault happy together with nspluginwrapper and flash, but I guess we can't do anything about that, also works fine with real 64bit plugins (mplayerplug-in for example)
(In reply to comment #4) > two things I noticed: > 1. it doesn't depend on exif, aspell and jpeg on amd64 and doesn't depend on qt on any arch except x86 Indeed. You might want to apply the patch below, then emerge with USE="-qt-static spell" JPEGs / JPEG file information is displayed properly, and if spell checking works (in the mail message editor). > 2. is there anything known wrt qt-static on amd64? else we'd have to mask > that USE flag Bug #176085 dealt with that to some extent. The amd64 team didn't then choose to set either -qt-static or qt-static. However: gentoo/cvs/gentoo-x86/profiles/default-linux/amd64 # grep qt-static * package.use.force:net-im/skype qt-static > also the operapluginwrapper seems to be extremely segfault happy together > with nspluginwrapper and flash, but I guess we can't do anything about that, > also works fine with real 64bit plugins (mplayerplug-in for example) That's good to know. Even the new =net-www/netscape-flash-9.0.60.0_beta082207 only supports x86 as of right now. Maybe I should reintroduce amd64? ( qt-static? ( app-emulation/emul-linux-x86-xlibs ) !qt-static? ( app-emulation/emul-linux-x86-qtlibs ) ) and provide a compat USE flag so that amd64 users can choose to use the 32-bit variant until netscape-flash has been updated? Let me know if that's desirable (or better yet - provide a well-tested patch, as I have no amd64 system to test with myself). Index: opera-9.50_alpha1567.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/www-client/opera/opera-9.50_alpha1567.ebuild,v retrieving revision 1.1 diff -u -B -r1.1 opera-9.50_alpha1567.ebuild --- opera-9.50_alpha1567.ebuild 5 Sep 2007 03:40:26 -0000 1.1 +++ opera-9.50_alpha1567.ebuild 6 Sep 2007 15:26:50 -0000 @@ -48,12 +48,11 @@ x11-libs/libSM x11-libs/libICE >=media-libs/fontconfig-2.1.94-r1 - !amd64? ( media-libs/libexif - spell? ( app-text/aspell ) - x86? ( !qt-static? ( =x11-libs/qt-3* ) ) - media-libs/jpeg ) - x86-fbsd? ( =virtual/libstdc++-3* - !qt-static? ( =x11-libs/qt-3* ) )" + !qt-static? ( =x11-libs/qt-3* ) + media-libs/libexif + spell? ( app-text/aspell ) + media-libs/jpeg + x86-fbsd? ( =virtual/libstdc++-3* )" S=${WORKDIR}/${A/.tar.bz2/}
on g/fbsd the patch opera-9.50-pluginpath.patch fails: >>> Emerging (1 of 1) www-client/opera-9.50_alpha1567 to / * opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 MD5 ;-) ... [ ok ] * opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 RMD160 ;-) ... [ ok ] * opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 SHA1 ;-) ... [ ok ] * opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 SHA256 ;-) ... [ ok ] * opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking opera-9.50-20070903.4-shared-qt.i386.freebsd-1567.tar.bz2 to /var/tmp/portage/www-client/opera-9.50_alpha1567/work * Applying opera-9.00-install.patch ... [ ok ] * Applying opera-9.50-pluginpath.patch ... * Failed Patch: opera-9.50-pluginpath.patch ! * ( /usr/portage/www-client/opera/files/opera-9.50-pluginpath.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/www-client/opera-9.50_alpha1567/temp/opera-9.50-pluginpath.patch-23495.out * * ERROR: www-client/opera-9.50_alpha1567 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_unpack * ebuild.sh, line 768: Called qa_call 'src_unpack' * ebuild.sh, line 44: Called src_unpack * opera-9.50_alpha1567.ebuild, line 65: Called epatch '/usr/portage/www-client/opera/files/opera-9.50-pluginpath.patch' * eutils.eclass, line 304: Called die * * Failed Patch: opera-9.50-pluginpath.patch! * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/www-client/opera-9.50_alpha1567/temp/build.log'. this happen because the file "usr/share/opera/ini/pluginpath.ini" do not exists into the opera-freebsd tarball: ls -la /var/tmp/portage/www-client/opera-9.50_alpha1567/work/opera-9.50-20070903.4-shared-qt.i386.freebsd-1567/usr/share/ total 20 drwxr-xr-x 5 portage portage 512 Sep 3 21:07 . drwxr-xr-x 5 portage portage 512 Sep 3 21:07 .. drwxr-xr-x 3 portage portage 512 Sep 3 21:07 doc drwxr-xr-x 3 portage portage 512 Sep 3 21:07 icons drwxr-xr-x 2 portage portage 512 Sep 3 21:07 pixmaps attached there is an ebuild patch that temporarely fix the issue letting almost install and use the package (for testing purposes). as AT for x86-fbsd i have tested the package (with the provided patch) and the browser seem to work correctly. the only problem that i have found is with the M2 (email client) that is not able to import SSL cerficates from MTA (but it's an alpha so i think it's ok).
Created attachment 130171 [details, diff] opera-9.50_alpha1567.ebuild.patch NOTE: this patch fix also some wrong usage of "use x86-fbsd" where elibc_FreeBSD is more preferable.
I think you misunderstood my line about qt-static, there's currently no qt-static version of opera for amd64, you seem to be aware of that since the lines for that are commented in the ebuild, but the big question is if it'll come back or if amd64 has to live without it. To that compat thingy, I'm not quite sure about that. It may be a nice idea to have a way to get 32bit opera, I'd say ask the community, for example through a vote on the forums. I'll give you a patch as soon as I find the time to actually do and test it, if you didn't do it before then and if it's wanted.
(In reply to comment #7) > Created an attachment (id=130171) [edit] > opera-9.50_alpha1567.ebuild.patch The pluginpath.ini for fbsd doesn't even mention /opt/netscape/plugins so I couldn't even rewrite the patch for fbsd. The patch fixes bug #, though, so if needed, please look into providing an alternative path to the default plugins directory. I have applied the suggested patches from both comment #5 and comment #6. So please cvs up gentoo-x86/www-client/opera/opera-9.50_alpha1567.ebuild and retry.
(In reply to comment #8) > I think you misunderstood my line about qt-static, there's currently no > qt-static version of opera for amd64, you seem to be aware of that since the > lines for that are commented in the ebuild Of course - I wasn't able to download it in the first place. Silly me. 8-) I don't think you will need to mask the qt-static USE flag as the ebuild doesn't use it for amd64 otherwise. I have removed the amd64? ( !qt-static? .. ) check in revision 1.3 of the ebuild. > but the big question is if it'll come back or if amd64 has to live without it. That depends on Opera, Inc. releasing future x86_64-linux tarballs. Note that for the build under discussion here, no sparc builds have been released either. > To that compat thingy, I'm not quite sure about that. It may be a nice idea to > have a way to get 32bit opera, I'd say ask the community, for example through a > vote on the forums. I'll give you a patch as soon as I find the time to > actually do and test it, if you didn't do it before then and if it's wanted. > Your comment #4 seems to imply that nspluginwrapper does the job of 64-bit to 32-bit emulation for netscape style plugins. I am almost certain that Opera's pluginwrapper will improve over time. It also depends on whether Adobe releases a 64-bit netscape-flash any time soon, I guess.
Comment on attachment 130171 [details, diff] opera-9.50_alpha1567.ebuild.patch Merged with one slight adaptation for legibility.
(In reply to comment #11) > (From update of attachment 130171 [details, diff] [edit]) > Merged with one slight adaptation for legibility. i have found the mistake for pluginpath.ini on freebsd: the file is located at /usr/local/share/opera/ini/ but the patch file "files/opera-9.50-pluginpath.patch" search it at /usr/share/opera/ini/ so the patching process fails. @jer: attached there is a new "files/opera-9.50-pluginpath-fbsd.patch" to correct the problem (it can be applied in the same manner of the bug #181300).
Created attachment 130183 [details, diff] files/opera-9.50-pluginpath-fbsd.patch
Created attachment 130189 [details, diff] opera/opera-9.50_alpha1567.ebuild.patch
(In reply to comment #14) > Created an attachment (id=130189) [edit] > opera/opera-9.50_alpha1567.ebuild.patch Applied.
I think all initial issues are solved now. *** Please open a new bug (perhaps using the Clone This Bug link) for any new issues. ***
