Sure, that's part of what GARNOME is for! By default, it will install to ~/garnome/ and not effect any of your existing GNOME packages. It may affect your configuration files though, so you ought to back them up or use a totally different user to run GARNOME. (Paul Drain)
You could, but you shouldn't! (and we won't support you if you do)
GARNOME isn't a package based setup, it installs from GNOME tarballs with patches. If you install GARNOME into /usr (for example), you will overwrite your system setup with the software we provide.
All of your configuration will be overwritten, all of your settings could vanish, all of the development libraries will be installed and you will destroy any knowledge your packaging software (RPM, dpkg, etc) has about your setup.
That really depends on your system configuration. On a Celeron 666Mhz with 128M of RAM, building the basic GARNOME install takes about 7 hours, whereas the same build only takes 30-45 minutes on a Dual Xeon based Intel System.
On an x86 system, GARNOME 2.12.0 (desktop category and its dependencies) requires 1.75GB as build space (plus an additional 1GB if you are building bootstrap/), however it only occupies around 600MB once installed.
Yes, Open the gar.conf.mk file in the main GARNOME directory and look for the GARCHIVEDIR line -- uncomment it and specify a directory that you have write permissions to.
If you type:
| make garchive |
From your base GARNOME directory (eg. garnome-2.12.0/), the installer will attempt to download all of the packages required to build a complete desktop installation
Open the gar.conf.mk file in the main GARNOME directory and look for the CC, CXX and CFLAGS lines -- uncomment these and specify the flags that you need.
note: the best way to get a set of CFLAGS that will work with your configuration is to use the cpucaps program from the prompt, you should see a line that says:
"Recommended gcc (version) target"
Uncomment and replace the CFLAGS line with the suggestions from that line and restart your GARNOME build.
Yes, you can use ccache to speed up your GARNOME builds, although this procedure requires additional disc space in your GARNOME build directory.
Using ccache is a three step task, first you need to install bootstrap/ccache, then set your cache sizes, then configure your gar.conf.mk file to use the cache.
GARNOME will require a different size cache depending on what parts of it you choose to build. However, for best results -- setting your cache size to 2GB by typing:
| ccache -M 2G |
Will be sufficently large to build all of the standard platform/ and desktop/ garballs.
Once you have installed the software and set your cache size correctly, open the gar.conf.mk file in the main GARNOME directory and uncomment the lines relating to building with ccache.
note: If you are building bootstrap/firefox, we recommend you make your cache size to 3GB -- otherwise, your cache may resize itself during the build, which may evict some of the more important components of your cache, slowing your build down.
Are you using the GNU MD5 tools? Some earlier versions the Sun md5sum tool don't agree with the GARNOME generated checksums.
If you are not using a GNU based system, you can open your gar.conf.mk file and edit the MD5 variable to point to a more appropriate binary.
You may find that some packages will not download for third-party sites (bootstrap/docbook-xml, fifth-toe/bluefish, etc).
These sites are affected by the Explicit Congestion Notification (ECN) code that is present in a number of operating system kernels. The most frequently reported symptom of this issue is that package downloads will time out after 30 attempts and halt your build.
This is not a GARNOME bug, and should not be reported as such.
The easiest workaround to this issue, is to temporarily disable ECN support in your kernel. If you have root priviledges on your machine, you can type:
| echo 0 > /proc/sys/net/ipv4/tcp_ecn |
Then you can resume your GARNOME build and things should proceed normally.
The bootstrap directory stores meta-information for programs you may need to get a current version of GARNOME up and running correctly, including build tools (like the autotools set), libraries, a recommended version of Mozilla and various platform dependant utilities.
Most users will never need to build anything from the bootstrap directory, however you should consult the README file in your GARNOME distribution just to make sure.
If you are not trying to compile GARNOME on an Apple system, and get an error similar to the following:
checking mach-o/dyld.h usability... no checking mach-o/dyld.h presence... no checking for mach-o/dyld.h... no configure: error: No dyld.h found, can not continue make[1]: *** [configure-work/main.d/dlcompat-20030629/configure] Error 1
You are trying to compile bootstrap/dlcompat when you shouldn't be.
See the question regarding the bootstrap directory and it's uses, then restart your compile from the desktop directory, as suggested in the documentation.
If you are trying to compile GARNOME on an Linux or BSD system, and get an error similar to the following:
gconvert.c:47:2: #error GNU libiconv not in use but included iconv.h is from libiconv
You have tried to compile bootstrap/libiconv when you shouldn't have.
To fix this problem, you will either need to:
Then restart your GARNOME build.
See the question regarding the bootstrap directory and it's uses, then restart your compile from the desktop directory, as suggested in the documentation.
If you are trying to compile GARNOME on an Linux or BSD system, and get an error similar to the following:
xsltproc: Content HTTP/1.0 200 OK
Please see the answer to Question 3.2
If you are trying to compile GARNOME on an Linux or BSD system, and get an error similar to the following:
"/home/ubuntu/garnome/lib/libgtk-x11-2.0.so: undefined reference to `g_key_file_get_integer' /home/ubuntu/garnome/lib/libgnomevfs-2.so: undefined reference to `g_key_file_load_from_file' /home/ubuntu/garnome/lib/libgtk-x11-2.0.so: undefined reference to `g_file_set_contents'"
You are trying to compile on a system that includes pesky .la files.
Some distributions install helper files with their development packages (Debian, Ubuntu, Arch Linux, earlier Slackware's) that have hardcoded references to libraries in system directories.
Libtool then may choose to use the information from these files instead of probing your system for the correct location of your files, which can cause some parts of the GNOME build to link against libraries that have been supplied with your system, rather than those that work with GARNOME.
A workaround for this issue has been included with 2.12.0, however -- if you find that the problem still comes up, please report it as a bug to the maintainers of your distribution.
If you are trying to compile GARNOME on an Linux or BSD system, and get an error similar to the following:
"/usr/bin/ld: cannot find -lguile-ltdl collect2: ld returned 1 exit status"
or:
"cscmi.o(.text+0x2b8): In function `add_slot': : undefined reference to `SCM_CHARS' cscmi.o(.text+0x2de): In function `add_slot': : undefined reference to `SCM_CHARS' collect2: ld returned 1 exit status"
You are probably trying to compile gnome-games with either a 1.7.x 'preview release' version of guile, or a version of 1.6.x that has been compiled with the '--disable-depreciated' flag.
As stated by the upstream bug, to fix this, you will either need to obtain a fixed version of guile from your upstream vendor, or download and compile guile from CVS yourself.
Scrollkeeper takes a while to re-index everything in your local directory, it hasn't hung -- it just takes a long time.
Occasionally, a package is released that will not build on some systems, this can be due to a number of factors -- including:
The easiest solution to this problem is to remove the package directory from it's meta-repository, eg:
| rm -rf fifth-toe/rhythmbox |
Would remove the Rhythmbox package from the optional fifth-toe repository
caution: If a package located in the platform/ or desktop/ directory will not compile, please consult the mailing list archives for a possible solution BEFORE removing it -- as this action will probably damage the dependency checking that GARNOME uses to build a working installation.
The first thing you should do, is to kill a redundant gconfd process -- which probably exists if your machine runs an earlier release of GNOME -- so that system-dependant processes, like ORBit, gconf and the GNOME Panel itself can work correctly. To do this, you should find and kill gconf by typing:
| gconftool-2 --shutdown |
The second thing you should do, depends on how you would usually start the GUI on your system:
If you start X using the CLI and have used the .xinitrc session script as documented in the README file, you should be able to type startx from the prompt to begin using your new GARNOME desktop.
If X starts when your machine starts, you should see the threads here or here for some well written documentation on the subject from the GARNOME mailing lists.
You will need to build freetype, xrender and xft from the bootstrap/ directory. Enter each directory and type make install, after these have built successfully, restart your GARNOME session to have fonts displayed correctly.
You need to build hicolor-icon-theme and shared-mime-info from the bootstrap/ directory and add (if it doesn't exist) the XDG_DATA_DIRS line to your GARNOME startup script.
Note: as of GARNOME 2.10, you need to run some additional commands to get this to work as expected -- after adding the required lines, run (from the prompt):
| $GARNOME/bin/update-desktop-database |
and then:
| $GARNOME/bin/update-mime-database $GARNOME/share/mime |
Then restart your GARNOME session to get your icons and associations back on track.
Set the GDK_USE_XFT environment variable by typing:
| export GDK_USE_XFT=1 |
To use the Hardware Abstraction Layer (HAL) on your desktop to detect things like an iPod, a Laptop Battery or a Camera, you will need to make sure that freedesktop/hal and freedesktop/dbus have been installed on your system, then make a script that correctly kills your system HAL daemon (if applicable) and starts the GARNOME version.
An example script is on the documentation page.
You would then run the script from within your GARNOME startup script, preferably before the gnome-session binary starts, to make sure everything starts in the correct order.
Epiphany uses the GNOME default proxies. They can be modified (session wide) by using gnome-network-preferences. The corresponding gconf keys are /system/http_proxy/host, /system/http_proxy/port and /system/http_proxy/use_http_proxy.
As part of the upgrade to Evolution 2.0 or 2.2, the import wizard will copy your Evolution directory to ~/.evolution.
The GARNOME maintainers recommend you keep a copy of your existing ~/evolution directory (if it exists), until you decide that you no longer need it.
You may find that the platform/glib package will not build.
This package is affected because the distributions listed above use the GNU iconv libraries, which need to be manually enabled to be used under GARNOME
Building the libiconv package from the bootstrap directory, then removing the comment in the CONFIGURE_ARGS line in platform/glib is the easiest fix for this issue.
You may find that the desktop/evolution package will not build.
This package is affected because the distributions listed above use the pilot-link 0.12 libraries, while Evolution only supports the 0.11.x versions by default.
GARNOME now includes a patch to update the pilot code in desktop/evolution and related packages. To use these patches, you must manually enable them by opening the Makefile uncommenting the PATCHFILES lines in the desktop/evolution, office/gnome-pilot and office/gnome-pilot-conduits packages before beginning your GARNOME installation.
If you have already started your GARNOME install, you must clean the packages first by using the make clean command in the relevant directories, then you may resume your build by running make install again.
You may find that the geektoys/netapplet package will not build.
This package is affected because the gnome-system-tools package thought your wireless-tools package was too old.
Because the netapplet package is really experimental, it requires a version of wireless-tools greater than 0.27 to work correctly.
Finding and installing a package specifically built for your distribution is the only supported fix for this issue.
You may find that the desktop/gnome-games package will not build.
This package is affected because the esound libraries in your distribution are broken. This is a known bug and has been fixed in the unstable branch.
Simply compiling platform/esound is the easiest fix for this issue.
You may find that the fifth-toe/gaim, desktop/evolution or desktop/ximian-connector packages will not build.
These packages are both affected by Red Hat's packaging of OpenSSL and the Kerberos 5 libraries. According to this post -- Red Hat's opinion seems to be a need to have these packages require pkg-config. Unfortunately, some earlier OpenSSL installations don't have the .pc support for pkg-config niceness, so hacking the GARNOME makefiles to support .pc files _might_ work, but you may need to do post-OpenSSL-buggery if your distribution is RH7.3, 8 or an unpatched version of 9.
The easiest workaround for problems with OpenSSL or Kerberos is edit to edit the affected makefiles and add:
--with-krb5=/usr/kerberos
to the CONFIGURE_ARGS line, then re-run make clean and make install from the prompt.
You may find that the desktop/libxklavier package will not build.
This package is affected because Slackware places their xkb libraries in a non-standard directory.
The easiest workaround for this issue is to edit the Makefile in the desktop/libxlavier directory and add:
--with-xkb-base=/usr/X11/lib/X11/xkb
to the CONFIGURE_ARGS line, then re-run make clean and make install from the prompt.
You may find that the bootstrap/mozilla package will not build.
This package is affected because the SuSE packaging of the heimdal libraries is rather broken. These distributions use an unsupported directory prefix that the Mozilla makefiles do not understand.
There is an unsupported patch for this problem here. Download the patch to your GARNOME directory and type patch -p1 < mozilla-suse9x-heimdal.patch, then re-run make clean and make install from the prompt to restart the build.
You may find that the desktop/nautilus package will not build.
This package is affected because the distributions above ship libexif 0.6 while everyone else, including several third-party repositories ship 0.5.x
There is already a patch included in GARNOME to resolve this issue, but it is not built by default. To use the patch, you should edit the Makefile in the desktop/nautilus directory and uncomment the PATCHFILES line, then re-run make clean and make install from the prompt.
You may find that the platform/pango package will not build.
This package is affected because the distributions listed above seem not to have a pkgconfig that GARNOME can grok correctly.
Building the pkgconfig and associated packages from the bootstrap/ directory is the easiest fix for this issue.
You may find that the platform/vte package will not build.
This package is affected because the distributions listed above lack a fontconfig package with support for recent versions of Pango
Building the fontconfig and associated packages from the bootstrap/ directory is the easiest fix for this issue.
You may find that the bootstrap/firefox package will not build.
This package is affected because the SuSE packaging of the heimdal libraries is rather broken. These distributions use an unsupported directory prefix that the Mozilla makefiles do not understand.
There is an unsupported patch for this problem here. Download the patch to your GARNOME directory and type patch -p1 < firefox-suse9x-heimdal.patch, then re-run make clean and make install from the prompt to restart the build.
You may find that the bootstrap/hal package will not build.
This package is affected because the location of the standard kernel include files on your distribution is not in the standard path for the HAL configure test.
There is an unsupported patch for this problem here. Download the patch to your GARNOME directory and type patch -p1 < hal-slackware-kernel-includes.patch, then re-run make clean and make install from the prompt to restart the build.
You may find that the hacker-tools/ghex package will not build.
This package is affected because the ghex makefiles don't recognize libbfd-2.13.90.0.18.so as a valid linkable library.
Adding a symlink from /usr/lib/libbfd-2.13.90.0.18.so to /usr/lib/libbfd.so is the easiest fix for this issue.