gnome-2.4 depends on epiphany epiphany depends on mozilla compiled against gtk2 libs galeon depends on mozilla compiled against gtk1.2 libs _I_ depend on galeon! If I try to run galeon as-is after the upgrade I get: /usr/bin/galeon-bin: error while loading shared libraries: libgtksuperwin.so: cannot open shared object file: No such file or directory Reproducible: Always Steps to Reproduce: 1. emerge galeon Actual Results: # emerge galeon Calculating dependencies ...done! >>> emerge (1 of 1) net-www/galeon-1.2.11 to / >>> md5 src_uri ;-) galeon-1.2.11.tar.gz * * It seems that your Mozilla was not compiled against gtk+-1.2, * but rather gtk+-2.0. As Galeon does not support this setup yet, * you will have to remerge Mozilla with gtk+-1.2 support. This * can be done by taking "gtk2" out of your USE flags: * * # USE=-gtk2 emerge mozilla * !!! ERROR: net-www/galeon-1.2.11 failed. !!! Function pkg_setup, Line 46, Exitcode 0 !!! Need Mozilla compiled with gtk+-1.2!! Expected Results: galeon runs as expected w.o. recompiling, or compiles against mozilla w. gtk2 I'm listing this with a severity of major since galeon is IMHO the best browser available on _any_ platform, and I, and others no doubt, rely heavily on it. Portage 2.0.49-r3 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.20-gentoo-r7) ================================================================= System uname: 2.4.20-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -mcpu=pentium4 -march=pentium4 -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo ftp://gentoo.noved.org/ http://gentoo.noved.org/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo" MAKEOPTS="-j3" 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 avi encode foomaticdb libg++ mikmod xv arts sdl gpm libwww imlib -kde -qt acl acpi alsa apache2 apm berkdb bonobo cdr crypt cups curl doc dvd dvdr esd evo fastcgi flash gdbm gif gnome gps gstreamer gtk gtkhtml imap ipv6 java jikes jpeg ldap mad maildir mcal motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl plotutils png bindist python quicktime readline samba sasl scanner slang slp snmp spell sse ssl svga tcltk tcpd tetex tiff truetype usb X Xaw3d xosd xml xml2 xmms zeo zlib"
use galeon 1.3, 'ACCEPT_KEYWORDS=~x86 emerge galeon' what is the best browser on a or any platform is subjective, galeon is at least not what it's creator intended it to be. If you want to see his vision witness epiphany.
My intention is not to argue the relative merits of epiphany vs. galeon. The issue is that I have a great deal of time and effort put into galeon toolbars and a substantial collection of bookmarks in it which are important to my work. This effort is either lost, or I will have to put a great deal more work in migrating this information to epiphany, plus the time involved in learning another browser. I will take your word for it that ephphany is a fine browser, but support of galeon should not be summarily dropped or left behind for those of us who like it and are accustomed to using it. I use my Linux desktop as my primary professional working platform, both out of choice and out of necessity. I appreciate the fine work the the Gnome and Gentoo developers do, but those of us who are not developers really expect that tools on which we've come to depend _not_ be dropped on the floor. If I had the luxury of time to spend following the creative bleeding edge of developers' latest creations it would be one thing, but I don't. I really don't have any more sympathy with this than I do with Microsoft when they force me to upgrade some piece of Windows trash because they want to make money by selling me their latest and greatest. Could I expect at some point that when epiphany is replaced as the cats-pajamas browser by something else, in the minds of gentoo developers, that support for it will be dropped too? This ain't kosher!
"use galeon 1.3, 'ACCEPT_KEYWORDS=~x86 emerge galeon'" Ah, you did give me an out. I overlooked it at first reading. Ignore my rant! Sorry!!
I need to point out, though, that foser's solution doesn't resolve the bug, nor does it provide a complete workaround. * The bug involves conflicting dependencies (gtk1.2 vs. gtk2) in non-masked packages. It should not be necessary to resort to masked packages to resolve a dependency conflict of this sort, and it needs to be addressed in non-maksed packages in the dependency chain. * The workaround offered requires a substantial number of updates (10 on my system) including an update of mozilla to 1.4-r4. It would be helpful to know whether emerging mozilla-1.4-r4 without USE='gtk2' will satisfy dependencies in epiphany, or whether one still needs gtk2 in mozilla to satisfy epiphany, and if so, if this will make galeon-1.3 happy, or does galeon-1.3 needs to be built explicitly with gtk2 as well. These are pretty long builds, even on a box running at over 12K bogomips so it would be nice to know this stuff in advance.
It depends on profiles and your personal USE flags settings, we can't control them all. No, it isn't ideal as it is, but neither is there a failsafe solution as long as we miss portage support for depending on USE flags. The ebuilds require deps as needed, galeon 1.3 & epiphany need gtk2, galeon 1.2 needs gtk1. None of them can be build with both backends.
Thanks much for your help, fosser. I've got galeon 1.3 up an running nicely. Although it's really not appropriate to carry the thread much further in a bug reporting system, I'd like to add that IMHO, having looked at all the pieces and problems, I'd just as soon dispense with epiphany in gnome2.4, keep mozilla compiled with gtk1.2 and keep galeon at the 1.2.x level until the 1.3.x line has recovered all the features lost in the upgrade to gtk2. There's a lot of little stuff in galeon, such as the Clear Location button, that made my life easier, and it's gone now.
I agree that it is better to keep galeon 1.2.X functioning because it is a far better and more relied-on browser than epiphany. I'd just as soon break epiphany and recompile mozilla with gtk+1.2 so that I can have galeon 1.2.X back. The trouble is that I have done this but galeon is still broken. I cannot get it to start without getting this: GConf Error: Failed to contact configuration server (a likely cause of this is that you have an existing configuration server (gconfd) running, but it isn't reachable from here - if you're logged in from two machines at once, you may need to enable TCP networking for ORBit) ...with a dialog complaining about not being able to find a gconf schema. I take it this has something to do with the gnome-2.4 upgrade? If someone has an answer to this problem it'd be helpful to post it on this bug report.
although it is probably true that galeon 1.2 is more feature complete, 1.3 is deemed stable enough by the maintainers. And since we can't stay with gtk1 forever (it annoys a lot of people if they still have to install gtk1 stuff) we have to move to gtk2, problem is that some profiles already did this and others didn't. I will push for a gentoo wide adaptation of default gtk2 useflag soon.
gtk2 in default profiles & galeon 1.3 is default x86 now, other arches should follow. arches, please test & mark galeon 1.3.10 stable
It should be noted that galeon 1.3.10 still has a number of very annoying bugs. When I noted these in gentoo bugzilla, foser said "1.3.10 is still a development release, so not supposed to be bugfree. I think you would be better off filing these kind of bugs upstream for now. We lack the manpower atm to handle this properly. Please do report back the bugno of the upstream bug so we can track it as well." It's just as well that the ebuild process is smooth, but some of the stuff in galeon 1.3.10 such as the javascript console and bookmarks management is still rather wonky. (Sorry, foser, for not filing on this upstream, as you asked. Not enough round tuits on this end.)
yes we know it's not completely 100% perfect stable (or that it ever will be with the current speed of development), this has all been talked trough (not in the least in this thread in itsself. We really don't have a choice one way or the other if we want consisten behaviour in portage. For normal browsing upstream and we consider it 'good enough'. I'm one of the strongest opponents of having unstable applications in the tree, but in this case it is the best solution i think. The 1.2 ebuilds will stay in the tree and be maintained as long as possible, someone who is unhappy with 1.3 vs. 1.2 performance/featurewise (cause thats mostly the trouble) can stick to 1.2 .
So be it, folks. As long as all the cards are on the table, y'all are doing the best anyone can. Thanks!
Galeon 1.3.10 is working on my G3 (ppc). Somebody else should test it on a G4 and commit the changes for ppc.
