Installation guides

Running Moksha under Sabayon

4 November 2015 HOWTOs, Installation guides, Overviews No comments

Moksha running under Sabayon

Moksha (theme: Moksha Radiance, wallpaper: 1366×768 calculate-dm 15) running under Sabayon

Moksha (pronounced: MOK-sha) is a free fork of Enlightenment 17 (E17), that is the default desktop environment of the lightweight Ubuntu (LTS) derivative, Bodhi Linux (BL). Its development began in 2015, when dissatisfied by the high resource usage and loss of features of the later Enlightenment releases, E18 and E19, Jeff Hoogland, the lead developer of Bodhi Linux, decided to fork E17 for BL.1 E19, for example, uses more RAM than LXDE even though E17 and Moksha use less RAM than LXDE and all other complete desktop environments that I am aware of (see Desktop environments and Sabayon for details). Its first stable release (version 0.1.0) was made on the 7th of August 2015.

While Moksha is pre-installed on later Bodhi Linux releases, it is not yet available as an official binary package, ebuild or PKGBUILD for any other Linux distribution, which means, of course, that if you wish to install it on other distributions you are left with really just one option: to compile it manually from source code and then install it yourself. Although, I have successfully made my own PKGBUILD for e_dbus-1.7.10 and moksha-0.1.0 and they can be found here. I have also (unsuccessfully) attempted to create an ebuild for Moksha, which can be found here, see it keeps giving me access violation errors related to /usr/bin/efreetd trying to create a directory /run/user/1000/.ecore. If you are interested in helping me fix this problem, feel free to start a pull request at GitHub. Fortunately, Jeff Hoogland along with other members of the Bodhi Linux community, are more than willing to help users of other distributions install and then customize Moksha to their liking, they even have their own forum specifically for such questions.

This blog post will walk you through the process of installing Moksha, getting it ready for easy use, getting modules you want and otherwise customizing it to your liking.


The following script should install Moksha for you, simply copy it into a shell script called “” (the name does not really matter, you could alternatively download from my GitHub repository), make it executable (run user $  chmod +x and then run it with ./ This script is specifically designed to install Moksha on a freshly-installed Sabayon Spinbase machine, which is why its dependency-installing lines are so long. It is also worthwhile noting that this script uses the minimum of bandwidth to get the source code, because alternatively, if bandwidth is not a limitation, the wget lines (line #4-5) can be replaced with


of all the steps in this script, the running of ./ --prefix=/usr is probably the most likely to return errors, which are usually related to missing dependencies. If you get an error from this step, please take note of the error and when asking for support be sure to include it, as odds are it will tell you everything you need to know in order to overcome the error.


The settings menu

The settings menu

Several aspects of Moksha can be customized. Most such customization, must be done from graphical user interfaces (GUIs), as opposed to from the command-line or via editing text files. Customization options, accessible via a GUI can be found under the “Settings” section of the menu that appears on click-clicking the desktop or the start gadget.

Application Menus

Click Menu Settings

Select Menu Settings

Go to Settings→All→Input→Menu→Menu Settings to change your application menus.

Select your Menus. See for example I have selected my LXDE application menu

Select your application menu

Desktop Backgrounds

Click Picture

Click Picture to set a picture on your computer as your desktop background.

To change your desktop background go to Settings→Wallpaper, press “Picture” and choose a picture on your computer to be your wallpaper. If you have problems changing your desktop background, I recommend changing the permissions of ~/.e/e/backgrounds with:

user $  chmod 777 -R ~/.e/e/backgrounds

and trying again.

Keyboard Shortcuts

Click Key Bindings

Select “Key Bindings”

Go to Settings→All→Input→Key Bindings and select your key bindings in the window below. To create a new program launcher click “Add”, press what keys you want in the shortcut, then go to Launch→Command and type in what command launches the program. Then press “Apply”. For example, for qBittorrent, I use the Alt+Q keyboard shortcut. The command I use to launch it is qbittorrent %U.

Choose your Key Bindings

Select your key bindings


Click 'Load' to load a module and 'Unload' to unload it.

Choose which modules you load or unload.

There are several modules you can load under Moksha, which all add functionalities to Moksha. To choose which are loaded and which are not go to Settings→Modules, in order to open the window shown above. There are also several modules maintained by Jeff Hoogland that are specifically designed for Moksha. They are found in Hoogland’s moksha-modules-extra GitHub repository. To download them and install them all with the minimum of bandwidth used, I recommend you use this script:


Use this window to add or remove shelves from Moksha

You can add new shelves with this dialogue and delete existing ones. In order to customize existing shelves go to “Contents” or “Settings”.

In order to customize your shelves (which can look like task bars or docks, depending on how they are set up) go to Settings→Shelves.


To set your theme go to Settings->Theme and select your theme from the menu that appears.

To set your theme go to Settings→Theme and select your theme from the menu that appears.

One of the most important customization, in my opinion, is to install the theme you want. To add a new theme, I recommend you add the following to your ~/.bashrc script:
then run:

user $  source ~/.bashrc


user $  theme <THEME>

where <THEME> is the Moksha theme you want. To find a theme you want I advise you go here. After you have installed the theme, you still have to set it as your current theme. The default Moksha theme of Bodhi Linux is Moksha Radiance, to get install it run:

user $  theme MokshaRadiance

. You can also change the GTK+ and icon themes used by programs running under Moksha by going to Settings→All→Look→Application Theme.

External links


Package Management on Sabayon

12 October 2015 HOWTOs, Installation guides, Overviews, System software 2 comments


  • This post contains links to wikis, including the Gentoo and Sabayon Wikis and the English Wikipedia. The information contained on these pages is subject to frequent changes and no one, myself included, can guarantee their accuracy at any given time.
  • Any instruction involving Portage, has the capability to break your system and cause other problems, so if you follow them you and you alone assume any and all responsibility for the consequences!

Often, on this blog, I write posts regarding installing software with Sabayon’s two package managers: Portage which it borrows from Gentoo and Entropy which is wholly original. I felt I would dedicate this post to both package managers, giving you some tips on how to use them safely and most efficiently. Generally speaking when it comes to Sabayon, unless you know what you are doing (for future reference users that “know what they are doing” in this context will be referred to as competent Sabayon users), you are recommended to only use Entropy as your package management system (PMS), as working with Portage is more risky and mixing Entropy with Portage is known to quite easily lead to system breaks. I mix the two, even though I would not call myself a competent Sabayon user, because quite often Entropy does not provide the software I want, while Portage can.

This post will cover some of the basics of using Entropy and Portage and how to use them together, in the safest way possible. It will also cover other related topics like using Layman to add overlays. You will probably notice that the command-line is featured heavily in this article, with little mention (usually all they will get is about a sentence mention each, if they are really notable) of graphical user interface (GUI) front-ends for these programs, this is because I tend to find command-line front-ends for package managers are more stable than their graphical counterparts.

Preliminary Information

Entropy, Layman and Portage are all written in Python. Entropy is maintained by Fabio Erculiani and other developers of Sabayon, while Layman and Portage are both maintained by the Gentoo community. This section will cover some of the preliminary information for each of these programs, including their command-line syntax, so as to make the rest of this post easier to understand.


Screenshot of Porthole running under KDE Plasma 5

Screenshot of Porthole running under KDE Plasma 5

Portage is a package management system that is arguably the most powerful Linux PMS available today. It is written in Python and Bash script, so as to afford users the ability to script with Portage. Portage installs, removes and upgrades software using the instructions contained in ebuild (that is, Bash scripts with the file extension .ebuild) files, which are stored within the “Portage Tree” which is /usr/portage, by default. This tree, only contains ebuilds from the Official Gentoo Overlay (OGO, you can search this overlay online here), ebuilds in overlays added with Layman are added to another location, /var/lib/layman. Normally Portage installs (or “merges“) software from source code, so as to maximize the control users have over the features their software has, but some pre-compiled binary packages exist in the OGO for software that would otherwise take several hours to compile. These packages are in .tbz2 file format and are created by running emerge with the --buildpkg or --buildpkgonly options enabled. Installing software from source code may also improve the performance (minimizing resource usage) of software installed this way.

Portage affords users this extra control via USE flags, which are “keywords that embodies support and dependency-information for a certain concept” (quoted from the Gentoo Handbook), in other words they are keywords that allow users to decide which (if any) optional package features (like language bindings, for example) will be built, when the package itself is built. These USE flags can be enabled or disabled for individual packages (via modifying files in the directory /etc/portage/package.use) or for all packages (via editing the USE="... line in /etc/portage/make.conf. USE flags should not be confused with package keywords (individual package keywords can be found in the directory /etc/portage/package.keywords, editing keywords for all packages can be done by editing the ACCEPT_KEYWORDS="..." line in /etc/portage/make.conf), which are entirely separate keywords, that detail architecture support (x86_64 vs. x86) and a few other features. Likewise packages you do not want Portage to emerge under any circumstances (which can be called masked packages) can be added to files within the directory /etc/portage/package.mask.

Portage is traditionally a command-line package management system (invoked by the command emerge), with no official graphical front-ends available, but a few unofficial graphical front-ends exist in the OGO, of which the most popular is probably the GTK+ based Porthole (app-portage/porthole).

The OGO contains over 18,500 software packages, as of October 2015, and while this may seem like quite a fair number (which it is) there will always be some people that will want to install software that is not in the OGO. To do this it is advisable to search the GPO website, for the package you would like and then add the overlay that contains the package you want with Layman.

Emerge Syntax

According to Portage’s Manpage1, emerge commands have the following format:

root #  emerge [options] [action] [ebuild | tbz2file | file | @set | atom]                                       (1)

This can be confusing to users not familiar with the formatting used by Gentoo’s Manpages (or Linux Manpages in general, for that matter), but I will attempt to explain. Before I do, I need you to get into the mind-frame you had when you first learnt algebra in high school, where variables (like x or y) could be substituted with numbers, letters, other characters or a combination of any, or even all of these. With this mind-frame the above generalized format of emerge commands will make more sense, as all words in that command except for root and emerge can be substituted, depending on what you want to do with Portage.

What is in square-brackets ([...]) are optional parts of the command (that is, they can be omitted) and when you are writing an actual command you omit the square brackets and substitute the word inside with any of a set of possible values it can take on. Some (not all, I do not even understand them all!) possible values options and action can take on are covered in the tables below. Multiple options can be combined with certain actions, often using the shortened notation. For example, to combine the ask and verbose options when emerging GNU Octave, one can run the shortened form root # emerge -av sci-mathematics/octave or the full-lengthed form root # emerge --ask --verbose sci-mathematics/octave. The vertical lines or pipes, as they can also be called, which is |, in (1) means the options separated by it and between the square brackets are mutually-exclusive options (that is, you either pick one or you pick none, depending on what you want to do). To save time, I will call the following part of (1) “input“:

[ebuild | tbz2file | file | @set | atom]

Sets (@set in the “input”) are essentially a useful way of specifying a large group of packages. There are six sets found in a default install of Sabayon, more can be created by users with root access by them editing files in the directory, /etc/portage/sets. Running root #  emerge --list-sets should list all available sets. ebuilds are just the names of packages you want to install. At a bare minimum they should be the package’s name (case-sensitive), without its category (e.g., wordpress for www-apps/wordpress), but sometimes specifying a package’s name without its category leaves some ambiguity (that is, there may be more than one package in the Portage Tree or unofficial overlays added with Layman, that has the name specified), so it is often safer to specify the category also. Some people may want to specify the specific package version they want too, to do this add an equal sign before the category and specify the package version after the package’s name, for example running emerge =sys-apps/portage-2.2.20 should install Portage version 2.2.20. Files are files that have been created by installed packages. tbz2file, as one can probably guess are any binary packages created by emerge itself, in the .tbz2 file format that one wishes to install. Atoms (atom) are essentially the same as ebuilds, only with bounds on their version numbers specified. For example, emerge <dev-lang/python-2.0 should install the latest version of Python available before version 2.0.

Table 1: Options for Emerge
Long Short Meaning
-a Ask before running the action.
–autounmask [y|n]
N/A This option is enabled by default and it basically allows emerge to unmask packages as required and write changes for package.use. Possible forms this option can take on are --autounmask=y, --autounmask=n (which will disable this option and unmasking/package.use changes will not occur) or --autounmask.
–autounmask-write [y|n]
N/A This option is similar to --autounmask, except it can write to package.use and other configuration files directly.
–buildpkg [y|n]
-b By default this option is disabled, but when enabled it causes emerge to install the package(s) and it also creates binary package(s) from the installed package(s) (file format: .tbz2) in PKGDIR (which is specified by /etc/portage/make.conf, by default it is /usr/portage/packages).
-B This option, which is not enabled by default, will only create binary package(s) and not install the package(s) specified to it.
-U Tells emerge to include installed packages where USE flags have changed since installation.
-d Show more detailed debugging information.
-D With this option emerge will look at the entire (or “deep”) dependency tree (not just the immediate dependencies of the package it is emerging, which it does by default) for updates.
-e Reinstalls package and all deep dependencies.
–keep-going [ y | n ]
N/A Continue as much as possible after an error.
-N Reinstall packages that have had their USE flags changed since installation. This option is more comprehensive in the packages it reinstalls than --changed-use.
-O Installs specified packages, without installing any dependencies. This option may cause package breakage.
-n Skips packages that are already installed.
-1 It will emerge the package as normal, but will not add the packages to the world file for later updating.
-o Install the specified package(s) dependencies, only. This is the emerge equivalent to APT’s apt-get build-dep.
-p This option causes emerge to display which packages would have been emerged, had the pretend option not been used.
–quiet [y|n]
-q This option, although results do vary, should minimize the output provided by emerge.
-u Updates packages to the best version available (not necessarily the latest, however).
-v This option causes more details to be given from ask and pretend commands. These details include GNU info errors and (for the pretend command) it will print USE flags.
–with-bdeps [y|n]
N/A During dependency calculations, build time dependencies that are not strictly required will be included. For installation actions this defaults to n, while for depclean actions this defaults to y.
Table 2: Action values for Emerge
Long Short IR? Meaning
None N/A Yes If no action is specified then emerge will merge all packages specified and their dependencies.
N/A Yes Run specific configuring processes that must be done after the package is emerged. The best example for this I can provide are the MariaDB and MySQL packages. Configuring these packages is required in order to set up a database with them.
-c Yes Removes packages not associated with any merged package.
-h No Displays some basic syntactic information, although if you really want some documentation for emerge from the command-line use man emerge.
-P Yes Remove all but the highest installed version of the package specified.
N/A No Causes portage to check and update the dependency cache of all ebuilds in the portage tree.
-r No Resumes the last merge, if said merge was cancelled due to errors.
-s Yes Search for packages who’s name matches with the supplied case-insensitive string.
-S Yes Search the Portage tree for string in package names and descriptions.
N/A No Updates all the ebuilds in the Portage Tree. You should do this once a week, at least. The first time you do it, this will take quite some time (potentially up to a few hours). To save time the first time you do this you may wish to run emerge-webrsync which will download the Portage Tree as a tarball.
-C Yes Unmerges (that is, uninstalls) software packages specified.
WARNING: This command ignores packages that may depend on the unmerged packages. For a more dependency-conscious and hence safer version of this command use the --depclean or --prune options.
-V No Display the version number of emerge.




Wiki Articles


Layman is a command-line tool for managing Portage overlays. It can be installed with Portage (from the OGO) using the command:

root #  emerge -av app-portage/layman

or with Entropy using the command:

root #  equo i -a app-portage/layman

I would recommend installing Layman using Entropy as it is less error-prone and the Layman package it installs was compiled with all the USE flags required to add every type of overlay available (including Bazaar (bzr), Git, Mercurial (hg) and Subversion (svn)). Layman-added overlays (and the ebuilds contained within them) are stored in /var/lib/layman/.

Layman Syntax

The basic syntax for Layman is:

root #  layman [options] [action]

As with emerge, I am not going to cover every option and action available for layman, as that would take too long, plus this is not meant to be a substitute for the manpages of the package managers and other tools covered in this post. Some of the more important/frequently-used actions and options are covered in tables 3 and 4. Please note that all actions when given in long form, if they require input (like --add does) this input must be specified with an equal sign and no spaces. For example to add the “sabayon” overlay you may run:

root #  layman –add=sabayon

or in shortened notation:

root #  layman -a sabayon

It is important to note that while this technique will add the sabayon overlay to one’s machine not all overlays can be added this way, as some overlays are not within Layman’s default list of available overlays (which I will henceforth refer to as the reference list). To view the reference list, run:

root #  layman -L

while to see the list of overlays currently installed, locally, on your machine run:

root #  layman -l

To add a new overlay that is not within the reference list, run:

root #  layman -o <URL of repository XML file> -f -a <overlay name>
Table 3: Options for Layman
Long Short Meaning
-N Remove colour codes from Layman output.
-q Reduce output.
-Q Takes a numerical value between 0 and 4 to determine the amount of output provided. 0 means no output, 4 means full output.
-v Makes Layman give more output details, such as a description of the overlays you download.
Table 4: Actions for Layman
Long Short Meaning
-a Add overlay.
-d Delete overlay. Specify “ALL” to delete all locally installed overlays.
-D Disable overlay. Specify “ALL” to disable all locally-installed overlays.
-i Display all available information about the overlay.
-L List all available overlays. Note that these overlays are not necessarily installed on your system.
-l List all locally-installed overlays.
-r Re-add overlay(s) specified, to re-add all overlays, use the input “ALL”.
-s Synchronize (or in other words, update) overlay(s) specified. To sync them all use the input “ALL” or use the
-S option mentioned below.
-S Update all overlays.



Rigo Application Browser running under KDE Plasma 5

Rigo Application Browser running under KDE Plasma 5

Entropy, is a PMS that was specifically designed for Sabayon by Fabio Erculiani, the original creator of Sabayon. Its first unstable release to be added to Sabayon was in July 2008 when Sabayon 3.5 was released and its first stable release to be added to Sabayon was made in May 2011 with the release of Sabayon 6. Unlike Portage which is primarily designed to install source code packages (although it can also install binary packages), Entropy is designed to work with binary packages only. Binary packages take less time than source code packages to install and requires less user know-how and input. Entropy is also unique in that it has two official front-ends: command-line/textual (Equo) and graphical (Rigo). I personally favour using the command-line for installing packages on Linux distributions, because in my experience graphical installers are more prone to crashes during installation than their command-line/textual counterparts.

Compared to Portage, Entropy is far more simple to use, if you go to the Entropy Store you can see the USE flags used to compile the software packages provided by Entropy, as all packages provided by Entropy had to be compiled with Portage on another machine first (in .tbz2 format). Entropy contains packages from the Portage Tree and packages from Sabayon’s own overlays, which are called sabayon and sabayon-distro, respectively. Entropy is also safer to use and support for using Entropy to install packages is far better than support for Portage-installed packages on the Sabayon forums.

Equo Syntax

The generalized syntax for Entropy’s command-line front-end, Equo, is:

root #  equo [action] [options] [ebuild | atom]

Some (but by no stretch of the imagine all) options and actions for Equo are listed in tables 4 and 5, below. Note some options are only available for certain actions, for details see the man pages for Equo and its various actions (e.g., run man equo install for the equo install manual). One action and another option that are not covered in these tables, that I felt were worthwhile mentioning, are repo and mirrorsort, respectively. The command:

root #  equo repo mirrorsort <REPO>

where <REPO> is the name of an Entropy repository (e.g.,, sabayon-weekly or sabayon-limbo), can be used to optimize the order of preference for the repository’s mirrors, hence, potentially, accelerating the process by which Sabayon downloads software packages.

Table 5: Options for Equo
Option Meaning
-a, --ask Ask before performing actions. For example equo i -a [ebuild] will ask you before it will install the package specified by the ebuild argument.
--deep Reinstall dependencies, even if unnecessary.
-h, --help, help Print help information.
-o If given to the “install” action this option will cause only the package’s dependencies to be installed. This is the equivalent to running apt-get build-dep for APT.
-p, --pretend Show what would be done, had this option not been given.
--purge (for upgrade) it will remove unmaintained packages, if any.
-q, --quiet Quiet (reduce) output.
-v, --verbose Verbose output.
Table 6: Actions for Equo
Long Short Meaning Manpage
cleanup N/A Remove downloaded packages and clean temporary directories. equo-cleanup.1
config N/A Configure installed packages. equo-config.1
deptest dt Look for unsatisfied dependencies. equo-deptest.1
install i Install software. equo-install.1
libtest lt Look for missing libraries required by other packages. equo-libtest.1
mask N/A Mask packages given as input. equo-mask.1
remove rm Remove packages given as input. equo-remove.1
rescue N/A Tools to rescue system equo-rescue.1
search s Search for packages in repositories. equo-search.1
unmask N/A Unmask packages given as input. equo-unmask.1
update up Update repositories. equo-update.1
upgrade u Upgrade packages that have been updated (in the software repositories) since they were installed, or since you last ran this command. equo-upgrade.1


Mixing Entropy with Portage

By default Entropy and Portage act fairly independently of one another. In order for you to use them together, you must tell Entropy that you are also using Portage to install packages by running:

root #  equo rescue spmsync

whenever you emerge, unmerge or update a package. I have this saved in my ~/.bashrc (for root user) as the function spm, so as to make it easier for me to run it when necessary. What this will do is it will cause packages you installed with Portage to be acknowledged by Entropy, as otherwise Entropy has no clue as to their existence. After this you may also wish to mask packages you installed with Portage, so as to prevent Entropy from attempting to upgrade or remove software installed with Portage. To do this run:

root #  equo mask <PACKAGE>

To prevent Entropy from downgrading emerged packages you need to edit


and uncomment (removing the hashtag #) the line

ignore-spm-downgrades = enable

Packages installed with Entropy are almost always safer (less likely to lead to system breaks or have bugs) than their Portage-installed counterparts, so when you install a package with Portage that has several non-installed dependencies I would suggest you install as many of these dependencies as possible with Entropy before you merge the remaining dependencies and the package itself with Portage.

Further Reading

The Algorithm

Occasionally, while browsing the internet, I find a program I would like to install on my Sabayon machine. Here is the algorithm I follow to install it:

    1. I search for whether or not said software is available in the Entropy Store. If it is there I install it with Equo (e.g., via running root #  equo i <PACKAGE>), if not I proceed to the next step.
    2. I search for whether or not said software is available in the main Gentoo Overlay. If it is there I install it with Emerge (e.g., via running root #  emerge -av <PACKAGE>), otherwise I move onto the next step.
    3. I search for whether or not the software is available in any unofficial overlays. If it is, and the version number is acceptable (usually I prefer the latest stable version of a software, but sometimes I will settle for fairly recent stable versions) I may add the containing overlay with
      root #  layman -a <OVERLAY>

      then sync both Portage and Layman with (I also have this added as a function called sync in my ~/.bashrc script)

      root #  emerge –sync && layman -S

      and then emerge the package with

      root #  emerge -av <PACKAGE>

otherwise I proceed to the next step. If the package has several dependencies I try to install as many as possible with Entropy, before I emerge the remaining dependencies and <PACKAGE> itself. Often using pretend instead of ask options (emerge -pv... instead of emerge -av...) will be helpful if you want a list of packages to install with Entropy. Sometimes emerge will say you need to adjust your USE flags (stored in /etc/portage/package.use/), package keywords (stored in /etc/portage/package.keywords), list of accepted software licenses (stored in /etc/portage/make.conf) and alike to install the package you want.

  1. If all else fails I get the source code and try compiling and installing it myself. This step is last, because this step is very error prone if, like me, you do not know an awful lot about compiling software or programming, in general. This step depends on the instructions in any INSTALL or README file included with the source code. If these files do not exist I use my knowledge on common compiling methods to install the software. For example, if the source code is written in C/C++ often there will be an or configure file somewhere in the source code base directory, which I will run (usually by opening up a terminal emulator and running user $  ./<FILE> where FILE is either or configure)) and read the output of. If the output includes an error, concerning some missing dependency, I will try to install said dependency (following the same algorithm outlined here) and re-run the script or if the dependency is on my PC already I will try giving the or configure file a PATH variable pointing to the dependency’s location on my system when I re-execute them. If no errors are encountered when running these scripts, or I manage to fix them with the methods I just mentioned I then run
    user $  make


    user $  sudo make install

    While if the source code is written in Python I look for a file and run

    root #  python install
  2. If errors are encountered at any of these steps (by errors I do not include the absence of available software packages as errors) I also attempt to seek support. For example, if the failure happened with an added unofficial overlay I often find the GitHub repository that houses the overlay and create a new issue for said repository. This process of getting support often occurs quite slowly, taking several days, at least, to get any solution to the problem, so often if failures happen I move onto the next step of this algorithm (if there are any steps left) before I report the failures.




An example of OpenRA running

OpenRA (games-strategy/openra) is a free and open-source futuristic strategy game. For me, it reminds me of one of my favourite Windows games, Outlive. OpenRA is unusual in that it is not available in the Entropy Store, although a few ebuilds for it do exist in the Portage Tree, although it is worthwhile mentioning that these ebuilds are often out of date. For example, as of 12 October 2015 the latest ebuild available in the Portage Tree is for version 20141029 (note how this number represents the date of the release, 29 October 2014), while the latest release is 20150919 (released 19 September 2015). There are unofficial overlays (such as games-overlay) that contain more recent versions of OpenRA, although as of 12 October 2015 they still do not contain the latest release of OpenRA.

To install the latest version available of OpenRA on Sabayon one has four main options:

  1. Emerge the package from the Portage Tree. This will get you release 20141029, at best. I have not tried this due to how old a version this package is. To do this simply run
    root #  emerge games-strategy/openra
  2. Add the games-overlay with Layman and emerge the latest version available from it, 20150614. This option I have not bothered with due to the fact it contains an old version of OpenRA and is an unofficial overlay (which makes it higher risk for system breaks and other issues). To do this run
    root #  layman -a games-overlay
    root #  emerge –sync && layman -S
    root #  emerge games-strategy/openra::games-overlay
  3. Add the dr overlay (not available with Layman) and emerge the latest version, 20150919. This option I have not done, due to the fact it needs freetype unmerged and that would break my system. To do this run:
    root #  layman -o -f -a dr
    root #  emerge –sync && layman -S
    root #  emerge games-strategy/openra::dr
  4. Compile the source code yourself and install OpenRA from that (which will get you the latest version of OpenRA, 20150919). This option I have succeeded in doing and is how OpenRA is currently installed on my system. To do this I ran:
    user $  wget -c
    user $  tar -xzf release-20150919.tar.gz
    user $  cd OpenRA-release-20150919
    user $  make dependencies && make all

    This does not add an executable of OpenRA to /usr/games/bin/ and hence running openra from the command-line will not start the game. So after this I also created a shell script file called /usr/games/bin/openra with nano (that is, I ran

    root #  nano /usr/games/bin/openra

    ) with the line mono --debug /path/to/OpenRA.Game.exe where /path/to is replaced with the path to where you built OpenRA from source code (which for me is /home/fusion809/Programs/OpenRA-release-20150919).

External links


SuperTux 0.3.3

SuperTux 0.3.3

SuperTux (games-arcade/supertux) is a free and open-source (licensed under GNU GPLv3) 2D platform game that was first released in April 2003. Its gameplay is very similar to that of the proprietary game, Super Mario Bros. The initial 2003 release was called “Milestone 1” (or if you would prefer a version number 0.1.3) and is the version of SuperTux available in the Entropy Store and the Official Gentoo Overlay (OGO). I have installed this version with Entropy, using:

root #  equo i games-arcade/supertux

This game is enjoyable, giving several hours of entertainment for me at least. Despite this, due to my preoccupation with using the latest software available, I looked to install the latest version of SuperTux (which are developmental, but still fairly stable, versions of Milestone 2 (or SuperTux 2) which is due to be released in December 2015). I tried installing it using the unofficial yarik-overlay and while this succeeded I found the most stable version provided by it (0.3.4) plagued by bugs. To do this I ran:

root #  layman -a yarik-overlay
root #  emerge –sync && layman -S
root #  emerge -av supertux

So after this, I decided to give manually building and installing it myself, a go. Then I got the latest tarball source code release (tar -xvf supertux-0.3.5a.tar.bz2 should do this from the command-line), decompressed it, changed into the supertux-0.3.5a directory and ran:

user $  mkdir build
user $  cd build
user $  cmake ..
user $  make
user $  sudo make install

this ran without error and the resulting SuperTux 2 installation (which by-the-way I have managed to keep on my system despite never removing my SuperTux 1 Entropy installation) was less buggy, in fact, I do not believe any bugs are left.

External links


  1. Specifically the emerge(1) manpage

VirtualBox and Sabayon

24 September 2015 Emulation software, HOWTOs, Installation guides No comments

Figure 1: Oracle VM VirtualBox Manager 5.0.4

Figure 1: Oracle VM VirtualBox Manager 5.0.4, running under KDE Plasma 5.4.1 on Sabayon

If I had to rank which pieces of application software I like the most, Oracle VM VirtualBox (previously called Sun VirtualBox and Sun xVM VirtualBox, henceforth I will call it simply VirtualBox or VB) would probably be at the number 1 position. This is because I love Linux and through VirtualBox I can try any Linux distribution or BSD derivative I want. In fact, I first tried Sabayon through VirtualBox, so I owe my new love of Sabayon, in part to this piece of software. In this post I will talk about how you can install VirtualBox on Sabayon and how you can install VirtualBox Guest Additions in a Sabayon virtual machine.

Before I proceed I should define some terminology, a guest operating system (OS) is one being run through a virtualization program (such as VirtualBox), while the host OS is the OS on which the virtualization program is being run. VM is an acronym for Virtual Machine, which is the “virtual” computer, created by the virtualization program, in which a guest OS can be run. VDI is an acronym for VirtualBox Disk Image, a type of file format used by VirtualBox, in which the hard drive of a VM is stored.

Sabayon Guest Additions

If VirtualBox is used to run Sabayon then in Sabayon you may wish to install VirtualBox guest additions (VBGA). What VBGA does is it essentially more seamlessly integrates the guest and host OS. This allows for more seamless adjustment of screen resolution within the guest OS and for clipboard integration: that is when your guest OS and host OS use the same clipboard, so if you copy something in your guest OS and want to paste it into your host OS you can.

VBGA can be installed via three major methods, each may be appropriate under different circumstances. Regardless of the method by which you install VBGA you will need to add yourself to the vboxguest user group and reboot before you can use it, namely by running (where, of course, <USERNAME> will need to be replaced with your actual username):

root # gpasswd -a <USERNAME> vboxguest
root # reboot


The most obvious (and also easy) way would be to install the package virtualbox-guest-additions via Entropy, but it is worthwhile noting that this version of VBGA is often out of date. For example, as of 23 September 2015 the version of VBGA in the Entropy store was 4.3.28, while the latest version of VBGA was 5.0.4. Consequently, if you are using a newer version of VirtualBox than 4.3.28 to run your Sabayon VM VBGA installed via Entropy may not work properly. To install VBGA using Entropy run:

root #  equo i virtualbox-guest-additions


Installing VBGA through Portage sounds like the natural alternative, if the version of VBGA provided by Entropy is unsuitable, but in my experience this method often returns errors. To give it a try, run:

root # ver=5.0.4 #replace 5.0.4 with the version of VBGA you want
root # emerge =app-emulation/virtualbox-guest-additions-$ver
root # equo rescue spmsync && equo mask app-emulation/virtualbox-guest-additions

VirtualBox Extension Pack

Figure 1: VirtualBox Preferences window

Figure 2: VirtualBox Preferences Window.
Click the highlighted icon to the right of the Preferences Window to add your VBEP file.

If neither of these methods work or are suitable, get the VirtualBox Extension Pack (VBEP) and install it. To do this go to File→Preferences, within VirtualBox, and click “Extensions” in the left-menu of the Preferences Window. Then click the button highlighted (the one near “Adds new package.” box) in figure 2 and in the file browser that pops up find your VBEP file and add it. Check that at least one blank disk is attached to the VM before you boot it, see figure 3 for assistance on this.

Figure 3: Disks and controllers for a VM

Figure 3: Disks and controllers for a VM
The disk icon (with “Empty” written next to it), that is circled (in red), to the left of the “Storage Tree” area needs to be present in order for you to be able to insert the Guest Additions CD image. The other CD image icon that is circled (in purple) is what you need to click in order to add a empty disk, if you do not have one.

After this, start your VM, go the Devices menu and select “Insert Guest Additions CD image” in this drop-down menu (refer to figure 4). If this is the first time you have inserted the guest additions CD image, you will need to wait for VirtualBox to download the CD image ISO.

Figure 3: Screenshot of a Fedora 23 VM with the "Insert Guest Additions CD Image..." option highlighted

Figure 4: Screenshot of a Fedora 23 VM with the “Insert Guest Additions CD image…” option highlighted.

After this, in your guest machine (that is, the VM), enter root (with su) and run:

root # mkdir /media/VBox
root # mount -r /dev/cdrom /media/VBox
root # cd /media/VBox
root # ./

add your user account to the vboxguest group (with root # gpasswd -a <USERNAME> vboxguest) and reboot.

Sabayon Host

If you would like to run VirtualBox on Sabayon there are two major ways you can install VirtualBox on Sabayon: A.) using Entropy and B.) using Portage. Option A is the easiest, but option B is the way you will have to go if you want the latest version of VirtualBox. See, as previously mentioned, Entropy houses a fairly out-of-date version of VirtualBox and related packages (4.3.28 vs. the latest version of VirtualBox, as of 23 September 2015, 5.0.4), while the main gentoo overlay of Portage contains a frequently-updated and currently up-to-date VirtualBox ebuild. Additionally if you install VirtualBox through Portage you should not have to install the VBEP, afterwards, as this will have been done during the installation of VB. You can also build the documentation for VirtualBox if you install it with Portage, via enabling the doc USE flag (note this USE flag is not available for the binary Portage package). To install VirtualBox with Entropy run:

root # equo i app-emulation/virtualbox

while to install VirtualBox with Portage run:

root # ver=5.0.4 #as before, replace this with the version of VirtualBox you want
root # emerge =app-emulation/virtualbox-$ver
root # equo rescue spmsync && equo mask app-emulation/virtualbox-bin

or, if you would rather a faster install (as you will be installing a binary package and not a source code package), emerge the virtualbox-bin package instead of virtualbox:

root # echo “app-emulation/virtualbox-bin PUEL” >> /etc/portage/package.license
root # ver=5.0.4 #as before, replace this with the version of VirtualBox you want
root # emerge =app-emulation/virtualbox-bin-$ver
root # equo rescue spmsync && equo mask app-emulation/virtualbox-bin

in my experience installing VirtualBox with Portage occurs much more seamlessly than installing VBGA with Portage. Regardless of method you use to install VirtualBox, after installing it you will need to run:

root # gpasswd -a <USERNAME> vboxusers


Running VirtualBox

After you have installed VirtualBox, you will naturally want to use it. The slideshow below covers the process of setting up a VM in VB, in 14 slides.

After starting the VM from the live ISO you can run the installer (if there is any) or otherwise follow the same method to install the guest OS as you would if you had booted from a live USB. Or, if you would prefer, you can just keep running a live session, just remember any changes you make will be lost as soon as you shutdown the VM. Using this method of installation I have managed to install the following OSs:

  • antiX 15
  • Arch Linux
  • Bodhi Linux 3.11
  • CentOS 7
  • Debian 8.0, 8.1 and 8.2
  • elementary OS 0.3 and 0.3.1
  • Fedora 22, 23 alpha/beta and rawhide
  • GhostBSD 10.1
  • Kali Linux 2.0
  • KaOS
  • Korora 21 and 22
  • Linux Mint 17.1 and 17.2
  • Mageia 5
  • MakuluLinux 7.0
  • Manjaro Linux
  • OpenMandriva 2014.2
  • openSUSE 13.2
  • PC-BSD 10.2
  • PCLinuxOS 2014.12
  • Sabayon Linux
  • Trisquel 7
  • Vector Linux 7.1
  • Xubuntu 15.04
  • Zorin OS 9 and 10

Further Reading

Installing SageMath on Sabayon

22 September 2015 Installation guides, Mathematics software No comments

Figure 1: Screenshot showing the SageMath 6.8 Notebook

Figure 1: Screenshot showing the SageMath 6.8 Notebook solving the Lotka-Volterra equations

SageMath is a free and open-source mathematics software written in Python and Cython that integrates several other pieces of free mathematics software in a common command-line/browser-based notebook interface. It can be installed on Sabayon via two major methods: A.) using Portage and B.) compiling from source manually. Of these option A is usually easiest, but it will take some time to do nonetheless. Option B is something I have not tried on Sabayon in recent memory, because I know from trying this on other distributions (such as Fedora and Ubuntu) that it is a nightmare unless you have a photographic memory of all of SageMath’s dependencies and known build issues on Gentoo/Sabayon.

If you need further assistance than this post provides on installing SageMath using Portage, I suggest you ask for it at the Sabayon forums, as I am not experienced enough with Portage to be able to provide much further assistance (in fact you will find most information provided by this post in the answer to a question I asked in the Sabayon forums). Alternatively you can start another issue in the sage-on-gentoo overlay GitHub repository, detailing any errors you have encountered with this build (although you should only add issues there relating to failed builds of the sage package or other packages provided by the sage-on-gentoo overlay).

Installing SageMath using Portage

An up-to-date SageMath ebuild can be found in the sage-on-gentoo overlay. To add this overlay to layman run:

root #  layman -a sage-on-gentoo

Then sync emerge and layman with:

root #  emerge –sync && layman -S

After this what you do is up to you, but I would recommend you run and take note of the output of:

root #  emerge -pv sci-mathematics/sage

try to install as many of the dependencies as possible with root #  equo i <PACKAGE>. Then run:

root #  emerge sci-mathematics/sage
root #  equo rescue spmsync && equo mask sci-mathematics/sage

to emerge the remaining dependencies (should be >20, by the way) and then SageMath itself. You may need to fiddle around with USE flags and masked packages, to get this to work, however. For example, you may need to add the following line in /etc/portage/package.use/gentoo.use:

before emerging sage. By the way, if you have the science overlay added, you may wish to add the following lines to /etc/portage/package.mask/gentoo.mask:

before you emerge sage and its remaining dependencies, as I know from my own personal experience that these packages often give out errors while compiling, although their counterparts in the main Gentoo overlay do not.

Installing RuneScape Unix Client on Sabayon

19 September 2015 Games, Installation guides No comments

The RuneScape Unix Client (RSU) is a RuneScape game client designed specifically for Unix/Unix-like operating systems such as the various distributions of Linux, including Sabayon. It is developed by Hikari Knight (HK) and others in HK’s GitHub rsu-client repository. While RSU is not strictly necessary to play RuneScape on Sabayon, as it can be played in any Java-capable web browser (such as Mozilla Firefox, Sabayon’s default browser, Google Chrome, is not Java-capable, however, as of version 45), it can be useful for reducing system resource usage and hence improving the performance of the game.

It can be difficult to install RSU on Sabayon, due to the fact it is not in the official Entropy repositories, nor is it in any official Portage overlays. There is a GitHub repository with tools for installing RSU on Gentoo Linux and related systems, including a Portage overlay that can be added using it (and a wiki guide to using this overlay to install RSU), but this overlay is often out of date. For example, as of 19 September 2015 the latest version of RSU was 4.3.4 (released 18 September 2015), while the latest release of RSU provided by this overlay was 4.3.0 (which was released 22 January 2015).

Alternatively to get the latest version of RSU one can download the run installer from RSU’s GitHub repository and install it.

Installing the dependencies

To install the dependencies of RSU using Entropy (equo) run:

root # equo i dev-lang/perl dev-perl/Archive-Extract dev-perl/Config-IniFiles dev-perl/IO-stringy dev-perl/wxperl media-libs/alsa-oss app-arch/p7zip media-sound/pulseaudio

I would not recommend installing these dependencies using Portage (emerge), as the version of Perl used by these packages is masked by /etc/portage/package.mask/00-sabayon.package.mask, specifically the line:


Installing RSU using the run installer

To install RSU using the run installer provided by the rsu-client repository, run:

user $ ver=4.3.4 #replace 4.3.4 with the version of RSU you want
user $ wget -c$ver/
user $ unzip
user $ sudo ./

Running WordPress on Sabayon

16 September 2015 Content management systems, Installation guides No comments

WordPress (WP) is a free content management system, used primarily as a blog application, and is used to power numerous websites (including blogs, such as this one). It requires a MySQL backend database (MariaDB is an acceptable alternative), the PHP scripting language and a web server (usually Apache, but nginx is also acceptable). Henceforth I will refer to this software bundle as LAMP (short for Linux, Apache, MariaDB/MySQL and PHP). Setting WP up to run on Sabayon is fairly simple and boils down to three steps, firstly, getting the dependencies set up and ready for WordPress. Secondly, getting the source code and moving it to the appropriate location on your system. Then thirdly, running the installation script of WordPress.

Step 1: Getting the dependencies

LAMP can be installed with a variety of different methods. It may be prudent to enable PHP support for all packages with

root # euse php

before installing LAMP, if you intend to use Portage to install it.

Table 1: Installing LAMP on Sabayon
root # equo i virtual/httpd-php dev-db/mariadb www-servers/apache
root # equo config dev-db/mariadb
root # equo i virtual/httpd-php dev-db/mysql www-servers/apache
root # equo config dev-db/mysql
root # emerge virtual/httpd-php dev-db/mariadb www-servers/apache
root # emerge –config dev-db/mariadb
root # equo rescue spmsync && equo mask virtual/httpd-php dev-db/mariadb www-servers/apache
root # emerge virtual/httpd-php dev-db/mysql www-servers/apache
root # emerge –config dev-db/mysql
root # equo rescue spmsync && equo mask virtual/httpd-php dev-db/mysql www-servers/apache

After installing LAMP the following files will need to be edited: /etc/php/apache2-php5.x/php.ini (where x is dependent on the version of PHP being used, e.g., if using PHP 5.6 then x=6) and /etc/conf.d/apache2. The first of these will need the following lines uncommented (that is, have the semicolon, ;, before them removed):

the final line can be left commented, if using MySQL instead of MariaDB for the backend database.

Likewise /etc/conf.d/apache2 will need -D PHP5 added to the end of the APACHE2_OPTS="..." line (within the quotation marks, however). Likewise you will need to enable and start the apache2 and mysqld daemons.

root #  systemctl enable apache2 && systemctl start apache2
root #  systemctl enable mysqld && systemctl start mysqld

After this you will need to set up a MariaDB/MySQL database for WordPress. To do this run mysql -u root -p, entering your root password for MariaDB/MySQL and then run CREATE DATABASE wordpress; to create a database entitled “wordpress”. It should not make any difference if you choose to call the database something other than wordpress, just make sure you remember this database name as you will need it for the final step.

Step 2: getting the source code

This step can be carried out a number of different ways, each of them equally valid, but for simplicity this section will only mention one such method that can be done from the command-line.

root # cd /var/www/localhost/htdocs/
root # wget -c
root # tar -xzf latest.tar.gz #you may also wish to delete latest.tar.gz after this step
root # mv wordpress wp
root # chmod 777 -R wp
root # chown apache:apache -R wp

Step 3: Running the install script

To do this simply open your favourite web browser to http://localhost/wp and complete the installation wizard. If you are still working at the command-line and would like to start this final step from the command-line you can run:

user $ xdg-open http://localhost/wp

Installing Atom on Sabayon

14 September 2015 Installation guides, Text editors 4 comments

Atom is a new (its first stable release was in June 2015) free cross-platform text editor by GitHub that is licensed under the MIT License. It is my favourite text editor as it is essentially Vim or Emacs for non-techies, that is, it has many of the same features that both Vim and GNU Emacs boast yet is simple enough that even an inexperienced technology user should be able to use it. There are pre-built binary packages available for the 64-bit versions of the more popular Linux distributions (such as Debian, Fedora, Linux Mint, openSUSE and Ubuntu), but for Sabayon Linux there is so far no Atom binaries available in the Entropy store. Consequently, Sabayon users must either install Atom using Portage (several overlays are available that contain Atom, although the main Gentoo overlay does not) or build Atom from source themselves.

Installing Atom from a binary package

I have recently (23 October 2015) set up a GitHub repository that provides information on how to install Atom from pre-compiled binary package(s) I upload to my Dropbox.

Installing Atom with Portage

To install Atom with Portage using the emc overlay (which I have chosen because it contains the greatest number of Atom ebuilds and seems to be frequently updated), run:

root #  layman -a emc
root #  emerge –sync && layman -S
root #  emerge app-editors/atom
root #  equo rescue spmsync && equo mask app-editors/atom

Building Atom Manually

Getting the dependencies

To install the dependencies for Atom, using Entropy, run:

root #  equo i nodejs libgnome-keyring gcc make dev-util/ninja fakeroot media-fonts/inconsolata

Getting the source code

Atom’s source code can be obtained via cloning its git repository or downloading tarball releases of its source code. If one intends to update Atom when new releases become available it is probably advisable to use git to get the source code.

To get the source code using git, run:

user $  cd ~
user $  git clone
user $  cd atom
user $  git remote add upstream
user $  git fetch -p
user $  git checkout $(git describe –tags git rev-list --tags --max-count=1)

To get the source code using wget, run:

user $  ver=1.0.19 #replace 1.0.19 with the version of Atom you are downloading
user $  cd ~
user $  wget -c$ver.tar.gz
user $  tar -xzf v$ver.tar.gz
user $  mv atom-$ver atom

Building Atom

To build Atom after installing the dependencies and getting the source code, run (from ~/atom):

user $  script/build
user $  sudo script/grunt install

The first of these lines may need to be repeated if errors are encountered.

Upgrading Atom

If one got the source code using git, then to upgrade Atom run:

user $  cd ~/atom
user $  git fetch -p
user $  git checkout $(git describe –tags git rev-list --tags --max-count=1)
user $  script/build
user $  sudo script/grunt install

alternatively, if you got the source code with wget, then to upgrade atom run:

user $  sudo rm -r ~/atom
user $  ver=1.0.19 #yet again, replace this with the version of Atom you want
user $  cd ~
user $  wget -c$ver.tar.gz
user $  tar -xzf v$ver.tar.gz
user $  mv atom-$ver atom
user $  cd atom
user $  script/build
user $  sudo script/grunt install

Known issues

I have noticed that upgrading using git, gave me the output:

Node: v0.12.7
npm: v2.13.3
Installing build modules…
Installing apm…
Installing modules ✓
Deduping modules ✓
Running “download-electron” task
Fatal error: Cannot find module ‘binary’

when I was upgrading from v1.0.11 to v1.0.13. I have reported this issue at the Atom GitHub repository. I ended up having to upgrade using the source code tarball method.


As previously mentioned in this post, there currently is no Atom package in the Entropy repositories, but I have posted a request to add Atom to the Sabayon overlay (which is a prerequisite for it to be added to the Entropy repositories).

External Links

Running MediaWiki on Sabayon

30 August 2015 HOWTOs, Installation guides, Wiki applications No comments

MediaWiki (MW) is a free wiki application that powers several notable websites including all the Wikimedia Projects (e.g., Wikimedia Commons and Wikipedia), Wikia sites, Orain Wiki sites, ShoutWiki sites and even the Gentoo and Sabayon Wiki websites. It is written in PHP and also requires a web server (usually Apache) and a backend database (usually MariaDB or MySQL) configured to use it, in order for one to be able to run it. On Sabayon there are a few different ways to run MediaWiki, which mostly just vary by the server or database used to host the Wiki.


This basic method can be boiled down to the following steps:

      1. Add PHP USE flags to all packages using:
        root #  euse php
      2. Run:
        root #  echo “dev-lang/php apache2 xmlreader” >> “/etc/portage/package.use/gentoo.use”
      3. Note: the following step while written for MariaDB, can be easily adjusted to using a MySQL backend database, simply substitute mariadb in these following commands with mysql.Install LAMP and configure MariaDB. To do this with Portage (emerge) run:
        root #  emerge -a dev-db/mariadb virtual/httpd-php www-servers/apache
        root #  emerge –config dev-db/mariadb
        root # equo rescue spmsync && equo mask dev-db/mariadb virtual/httpd-php www-servers/apache

        whereas to do this with Entropy (equo) run:

        root #  equo i dev-db/mariadb virtual/httpd-php www-servers/apache
        root #  equo config dev-db/mariadb

        Optionally one can run, after installing LAMP and configuring MariaDB, the following:

        root #  mysql_secure_installation
      4. Add:

        to /etc/conf.d/apache2.
      5. Edit your php.ini file, which should be somewhere in a subdirectory of /etc/php with apache2 in its name, e.g., /etc/php/apache2-php5.6. Find the following lines and uncomment them (removing the semicolon, ; from before them).

        the last line can be left commented if using a MySQL database.
      6. Enable the apache2 and mysqld daemons and start them.
        root #  systemctl enable apache2 && systemctl start apache2
        root #  systemctl enable mysqld && systemctl start mysqld
      7. Download and extract the source code of the MediaWiki release you want to /var/www/localhost/htdocs/ and change the permissions of the files therein accordingly, for example:
        root #  wget -c
        root #  tar -xzf mediawiki-1.25.2.tar.gz -C /var/www/localhost/htdocs/
        root #  cd /var/www/localhost/htdocs/
        root #  mv mediawiki-1.25.2 w
        root #  chmod 777 -R w
        root #  chown apache:apache -R w

        I am aware of the www-apps/mediawiki package in Gentoo and Sabayon main repositories, but for me they never seem to work.

      8. Open up your browser to http://localhost/w/mw-config and run the set up script. To do this from the command-line, for example (and this will open up your default web browser), run:
        user $  xdg-open http://localhost/w/mw-config

        Then when you are finished, download LocalSettings.php to /var/www/localhost/htdocs/w and open your web browser to http://localhost/w/index.php/Main_Page.

Optional configuration

Short Wiki URL

  • To get your Wiki to use a shorter URL, namely http://localhost/wiki/$1 instead of what it would be using if set up with the aforementioned method, http://localhost/w/index.php/$1, add the following to /etc/apache2/vhosts.d/default_vhost.include:

    and the following to LocalSettings.php:

    External links