How to start gnome? (My experiences)

[Ryan Schmidt]

On Jan 25, 2012, at 21:37, Ollie Oberg wrote:

> I wanted to point out that I'm having pretty much *exactly* the same problems starting gnome as described on the mailing list earlier this month.  For what it's worth, I'm running it on a G5 (PPC) with OSX 10.5.8, with the latest Xcode (3.1.4) installed, and the stock X11 app that comes with Leopard.  Also, I've installed Ubuntu on another machine, and despite a few problems, have managed to run gnome though ssh on that machine from my SnowLeopard machine, indicating to me that my setup is okay.  While I would love help, it seems that none is available at the moment.  Instead, I hope to detail my own adventures in installing gnome and failing to run it.  Perhaps this will help somebody else in the future (or me in the present).  In no particular order, 
> 
> (assume that port here means "sudo port" as it is necessary)
> 
> 1. port install gnome 
> This didn't work without a lot of extra help from me.  It would start fine, but I ended up having to clean, force deactivate, reactivate, etc. a lot of dependancies.  I think a general port clean all should be recommended any time anybody even thinks of recommending installing a large package like this.  For some reason, also, a lot of packages failed to install this way, but installed just fine using port install foo.

I can't explain that, and without further details (logfiles) I can't do anything about it.


> 2. Perl5 hell
> I often got a lot of errors, or simply frozen, results related to perl.  Often time it had to do with staging into destroot.  The solution was to force uninstall perl everything, then let macports install it if needed.   I still needed to manually activate perl5.12 in one case.  

That should not have been needed. There should only be one or two perl module ports left that install files provided by the main perl port, and these would indeed need to be force-activated. The perl5.12 and the other main perl ports, and the vast majority of the perl module ports, should have installed and activated fine. Unless you were upgrading an old MacPorts installation from back when perl5.8 was the default; we did not handle that upgrade well, and it would have resulted in the need to manually upgrade perl5 first, before upgrading the perl5.x ports; if you did not do this, you would have gotten a message that perl5.12 could not be activated, suggesting that you could force the activation, but you should not follow that suggestion. This change was many months ago now though so I thought everyone would have upgraded through this by now.


> 3. Shell errors
> It was a known problem that glib2 has a dependency on gtk-config.  Gtk-config currently has glib2 as a dependency.  Not a good situation for a fresh install.  Even the work-around mentioned in the bug report didn't work for me.  I managed to compile gtk-config on my own, after which I could install glib2, after which I could install gtk-config finally. This was perhaps the biggest headache of them all, with no clear solution.

Did you mean gtk-doc, as in this ticket?

https://trac.macports.org/ticket/32950

If so, recall that the problem here was again perl: gtk-doc only failed because you didn't have a working perl activated. And you wrote in the ticket that once you activated a working perl, you were able to get past the glib2 installation.


> 4. stuck looking for .elc files
> This was particularly annoying, because macports would just freeze at "configuring foo."  I had to try to compile myself, and only later found out that even though emacs was present under /usr/bin/emacs, configure couldn't find it until I did "port install emacs"

Which port is "foo" here? If there is a port that needs a dependency on emacs, let us know so we can fix that.


> 5. gtk-plugins
> I gave up on this one.  None of the gtk-plugins-* installed through macports.  -good complied on it's own manually, -bad and -ugly did not.  I didn't really need totem, I don't think, but it would be nice to know it's not needed (if that's indeed the case) for users who were told "just sudo port install gnome and then run gnome-session."

Need logfiles to be able to investigate these; please file bugs in the issue tracker as usual.


> 6. dbus, quartz-wx, etc
> I'm still not sure what exactly this is.  It seems to be important to running gnome, but (as discussion here has shown) how it relates to gnome is unclear.  similarly, quartz-wx seems to be important, but there's no explanations I could find what it is.  Sometimes it seemed like it's part of X11.app, other times like it's an alternative to X11.app.  Should users be running XQuartz instead of X11.app?

According to "port info", dbus is "A message bus system, a simple way for applications to talk to one another". Many gnome ports require this. In addition to installing dbus, you must start its daemon; MacPorts prints instructions for how to do this when you install it, but if you missed them, you can read them again by typing "port notes dbus".

"port info" also tells us that "quartz-wm is the XQuartz window-manager" but I must admit I'm not really clear on what that means either. Window managers are pretty nebulous to me; I use a Mac instead of Linux so that I don't have to think about that kind of stuff.

XQuartz is simply a newer version of the X11 that came bundled with your OS. You can install XQuartz manually if you like. Or you can install the MacPorts port xorg-server, which is essentially the same software. I do recommend running one of these releases of X11.app instead of the one Apple installed for you in /Applications/Utilities, because both of these releases will be years newer than what you have in Leopard.


> 7. gnome.conf, .xinitrc, .xinitrc.d/90-gnome.conf, com.freedesktop stuff
> There seem to be a number of processes, files, and configurations necessary to run gnome.  Again, I've found a lot of conflicting information here.  
> 
> It's not at all surprising that running a desktop while already in another one would be no cakewalk.  However, it seems to be rife with mis-information.