GoboLinux 017 Known Issues and Fixes

Live environment

Running Compile

Install UnionFS-Fuse to workaround limitations with the sandbox in the Live environment:

InstallPackage --no-check-certificate https://gobolinux.org/packages/017/Fuse--2.9.7--x86_64.tar.bz2
InstallPackage --no-check-certificate https://gobolinux.org/packages/017/UnionFS-Fuse--2.1--x86_64.tar.bz2

Installed system

Git-related errors when invoking Compile for the first time

Loopback network interface needs to be brought up. As root, run:

ifconfig lo up
echo ifconfig lo up >> /System/Settings/BootScripts/BootUp

InstallPackage searches for packages from GoboLinux 016 rather than 017

Update the search URL used by the Scripts package:

GrepReplace -B "016" "017" /System/Settings/Scripts/GetAvailable.conf

Update of Compile and Scripts tools

Compile and Scripts are always evolving. Make sure to update your copies by running the following commands after you boot into your installed system for the first time:

cd /Programs/Scripts/Current
git pull && UpdateSettings --auto Scripts && make

cd /Programs/Compile/Current
git pull && UpdateSettings --auto Compile

Dependencies files with reference to Ncurses

Ncurses has been replaced by NcursesW, but some packages’ metadata still hold references to the former. The following command fixes that:

GrepReplace -B "^Ncurses " "NcursesW " /Programs/*/*/Resources/Dependencies

Update expired SSL certificates!

The recent Let’s Encrypt fiasko requires our users to update their certificate database on the system. Otherwise tools like git, wget, Compile etc might not work correctly.

The appropriate way to resolve this, is by running:

sudo Compile --no-check-certificate Automake
sudo Compile --no-check-certificate CA-Certificates

and

sudo sh /System/Index/bin/update-ca-certificates

afterwards.

Wrong version of SQLite

The version under /Programs/SQLite/3310100 is actually 3.8.2. Please run the following commands to update to its most recent version:

Compile SQLite
RemoveProgram SQLite 3310100

Outstanding issues

Some problems have been reported by our users and are currently being fixed by our team. They are:

• ContributePackage is not working – use ContributeRecipe instead.
• Copy-and-paste does not work out of the box from a VM. Compiling spice-vdagent and loading its daemon should fix that.
• Sometimes when trying to Compile an already-installed Program, the build process will fail (see Compile bug 51). Sometimes this can be worked around by first manually doing a RemoveProgram <failing program> before re-attempting to Compile it. Note that it is generally a Bad Idea™ to try to RemoveProgram, say, Python3 like this as it will break Compile.

Compile fails stating that some headers or libraries could not be found, when they are there

The installation process used by Compile had a problem in that certain extended attributes used by overlayfs were carried over from the sandbox to the installation directory. Some of those extended attributes tell overlayfs to consider the corresponding files or directories as deleted objects. Since we use overlayfs to sandbox the compilation process, this bug may impact Compile in the sense that existing files may be considered as non-existent.

If you face this problem, please run the following commands on your installed system to remove those attributes:

fname=
xattr_pattern="trusted.overlay."
getfattr -P -R -d -m "$xattr_pattern" --absolute-names /Programs 2> /dev/null | while read i
do
   if echo "$i" | grep -q "^# file:"
   then
      fname="$(echo "$i" | awk {'print $3'})"
   elif echo "$i" | grep -q "^${xattr_pattern}"
   then
      xattr="$(echo "$i" | cut -d= -f1)"
      setfattr --remove "$xattr" "$fname"
   fi
done

Running under GNOME Boxes

GNOME Boxes is a new virtual machine manager and remote desktop manager powered by QEMU, KVM, and libvirt virtualisation technologies. Running Gobolinux under GNOME Boxes is quite easy, even more so than under Virtualbox.

Setup Instructions

1. Create a new Virtual Machine by clicking “New” in the top left corner.
2. Click “Select a file”.
3. Select the Gobolinux LiveCD ISO file.
4. Boxes will be ready to create a virtual machine with 2GB of RAM and 21.5GB of storage. If that is sufficient, click “Create”.
5. Otherwise you can click “Customize” and adjust the sliders for RAM and storage respectively, then click the back arrow.
6. The LiveCD session will then start. Continue normal installation procedures. Remember to eject the LiveCD prior to reboot by going to the top right menu and clicking “Properties” -> “Devices & Shares” and then clicking “Remove” beside the CD/DVD section.

Installing SPICE

Spice allows for integration with the host system including setting native resolutions, file transfers, clipboard support etc.

1. Compile SPICE-VDAgent
2. Run StartTask Spice-VDAgent after login
3. Run spice-vdagent
4. Run xrandr --output Virtual-0 --preferred to update the resolution

Running under VirtualBox

Setting up VirtualBox guest additions

VirtualBox requires its own graphics drivers in order to perform advanced features such as smart mouse sharing and running at a window-dependent full resolution.

These drivers can be built using the “Guest Additions” ISO image included with VirtualBox.

The catch is that we are already using the virtual CD drive from VirtualBox to run the ISO, so we need to add a second one. With the virtual machine shut down, right-click the image, then at the Storage pane, add a second optical drive, and insert the VBoxGuestAdditions.iso file that should be somewhere in your VirtualBox installation:

Then, boot GoboLinux normally in VirtalBox, and do the following:

mount /dev/sr1 /Mount/CD-ROM
cd /Mount/CD-ROM
./VBoxLinuxAdditions.run
udevadm trigger

When you run udevadm trigger the drivers should be loaded, and the console will change resolution immediately. (It will also lose the nice-looking GoboLinux font: to reload it, type setfont lode-2.0-lat1u-16.)

Now, you can start Xorg normally with:

startx

If you want to resize your VirtualBox window, make sure “Auto-resize guest display” is turned on in the VirtualBox “Machine” menu, then, after resizing the VirtualBox window, type in the GoboLinux terminal the following

xrandr --output VGA-0 --preferred

This will resize the desktop to match your window size.

Note that this installation of the VirtualBox guest additions will only last for the current Live-CD session. If you install GoboLinux into a VirtualBox virtual hard drive, you will have to do the same again.

Running under VMWare Workstation Player

When you install GoboLinux 016 on VMWare and boot it for the first time, you will get a black screen after the GRUB boot selection menu. The underlying problem is that the VMWare SCSI hard disk controller driver has been built as a module on the kernel. Because of that, the virtual disk image is not recognized and booting the installed system fails.

Workaround

VMWare saves the virtual machine settings on a file with the .vmx extension. If you have named your virtual machine “GoboLinux 016”, then you will have a file called GoboLinux 016.vmx. Shut down VMWare, open that file with a text editor and replace the lines:

scsi0:1.present = "TRUE"
scsi0:1.fileName = "GoboLinux 016.vmdk"
scsi0:1.redo = ""

with the following:

sata0:1.present = "TRUE"
sata0:1.fileName = "GoboLinux 016.vmdk"
sata0:1.deviceType = "disk"

The fileName may look different on your machine. You will want to keep whatever name your config file presents. Also, make sure that the following lines do exist in the vmx file (again, pciSlotNumber may look different on your vmx file):

sata0.present = "TRUE"
sata0.pciSlotNumber = "37"

Once you are done, save the file and launch VMWare. The system should boot up nicely this time.

Running under HyperV

When running the GoboLinux 016.01 live ISO through Hyper-V, you will notice that startx does not start correctly by default. You can fix this by adding a kernel boot parameter and creating an Xorg configuration file.

Edit /System/Kernel/Boot/grub/grub.cfg and find the kernel boot line. Change video=vesafb:off to video=hyperv_fb:1024x768 and save it. You may wish to try this part in advance first, without saving it; in that case, press e at the Grub menu, make this same edit, and press Ctrl-X to boot once only with the new command line.

Run X -configure. It will generate a file xorg.conf.new. Edit this file, and change vesa to fbdev. Move the file to /etc/X11/xorg.conf.

Reboot. startx will now work normally.

Running GoboLinux under QEMU

We’ll illustrate how to:

• create a disk image
• boot an ISO image of Gobo under QEMU
• install Gobo to a disk image on the host filesystem
• reboot the newly installed guest
• initialize networking
• launch QEMU from a helper script

Create a disk image

This is where we will install our Linux system.

qemu-img create gobo.img 10G

Boot the installer

Here is the full command you can edit and paste into the terminal:

sudo qemu-system-x86_64 \
-cdrom GoboLinux-016.01-alpha-x86_64.iso \
-hda gobo.img \
-boot d \
-m 768 -enable-kvm -show-cursor -cpu host -daemonize \
-vga std -soundhw ac97 -rtc base=utc \
-usb -usbdevice tablet -device usb-mouse -vga std -clock unix

To test boot only the ISO, omit the -hda option.

Boot the disk image

After you’ve finished the installation, shutdown the guest OS and terminate QEMU. Start QEMU again, this time booting from the disk image:

sudo qemu-system-x86_64 \
-hda gobo.img \
-boot c \
-m 768 -enable-kvm -show-cursor -cpu host -daemonize \
-vga std -soundhw ac97 -rtc base=utc \
-usb -usbdevice tablet -device usb-mouse -vga std -clock unix

Networking under QEMU

QEMU provides a networking stack so that the guest OS running on this virtual machine can access the internet, or ssh to the host.

The only extra setup needed is to run Gobo’s DHCP client inside the guest.

dhcpcd

By default QEMU acts as a firewall and does not permit any incoming traffic. It also doesn’t support protocols other than TCP and UDP. This means that ping and other ICMP utilities won’t work.

Details can be found here.

Helper script

Qemust is a perl5 script you can use to start your QEMU processes. With most options defined in the script, the command line becomes much simpler.

To boot from an ISO and install to a disk image:

qemust --iso=GoboLinux-016.01-alpha-x86_64.iso --image=gobo.img

To boot from the disk image

qemust  --image=gobo.img

To test an ISO:

qemust --iso=GoboLinux-016.01-alpha-x86_64.iso

The script has some library dependencies. The most convenient way to install them (and any CPAN modules) is to use cpanminus (cpanm). So install cpanminus, then the dependencies:

cpan App::cpanminus
cpanm Getopt::Long::Descriptive

The script follows below. Edit the QEMU options to your liking, put the script in somewhere in your $PATH, and make it executable with something like chmod a+x ~/bin/qemust.

#!/usr/bin/env perl
use strict;
use warnings;

#   qemust - start QEMU

use 5.012;
use Getopt::Long::Descriptive;
my ($opt, $usage) = describe_options(
   '%c %o',
   [ 'iso=s',  "ISO file to boot" ],
   [ 'image=s',"OS disk image file" ],
   [ 'help',   "print usage message and exit" ],
   [ 'n',      "print QEMU startup command and exit" ],
 );
print($usage->text), exit if $opt->{help} or ! keys %$opt;

my $boot_drive = $opt->{iso} ? 'd' : 'c';

my @cmd = grep{! /^\s*$/} map{s/\s*#.*$//; $_} split "\n",<<"CMD";

sudo                 # run as root
qemu-system-x86_64   # for 64-bit CPUs
-enable-kvm          # faster virtualization
-show-cursor         #
-boot $boot_drive    # boot from DVD/CDROM if present
-m 768               # use memory 768MB
-cpu host            # same CPU model as host
-daemonize           # avoid race conditions when QEMU started by external program
-vga std             # probably -vga vmware would work, too
-soundhw ac97        # typical soundcard, -soundhw hda should also work
-rtc base=utc        # timer related
-usb                 # enable USB driver
-usbdevice tablet    # so QEMU can report mouse position without grabbing mouse
-device usb-mouse    #
-clock unix          #

CMD

push @cmd, "-cdrom $opt->{iso}" if $opt->{iso};
push @cmd, "-hda $opt->{image}" if $opt->{image};
my $cmd = join " \\\n",@cmd;
say $cmd;
system($cmd) unless $opt->{n};
__END__

Installing to external storage devices

GoboLinux 016 comes with two installation modes: UEFI and BIOS-compatibility mode. Depending on how your computer firmware is configured you may need to follow one or another recipe below.

BIOS-compatibility mode

Ensure that your external disk has been configured with a MSDOS partition table. You need to have at least one Linux partition (e.g., ext4), with the BOOT flag set.

You can then proceed with the installation of GoboLinux by selecting that Linux partition as install target and by enabling the installation of the bootloader on the master boot record (MBR) of that disk.

UEFI mode

Ensure that your external disk has been configured with a GPT partition table. You need to have at least one Linux partition (e.g., ext4) and a FAT (32/16/12) partition which is where the UEFI application embedding the GRUB bootloader will be stored. The FAT partition needs to have both the ESP and BOOT flags set. If you are using GParted, that FAT partition will be automatically formatted by the tool. If you are not, then make sure to invoke mkfs.msdos to format it yourself.

Once the partitioning is arranged, you can proceed with the installation of Gobo by selecting the Linux partition as system install target and by selecting the FAT partition (also called EFI System Partition) as bootloader install target.

Troubleshooting

Unable to mount root fs

Both USB-Storage and UAS (USB-Attached-SCSI) drivers are built into the kernel. However, at times the kernel may not have time to discover the partitions on your external disk and may fail to mount the root filesystem. This particular problem can be fixed by adding the rootwait parameter to the kernel command line.

For BIOS-compatibility mode:

1. Mount your system partition using the LiveCD under /Mount/GoboLinux
2. Edit the file at /Mount/GoboLinux/System/Kernel/Boot/grub/grub.cfg. Look for the lines starting with linux /System/Kernel/Boot/kernel-4.8.2-Gobo and append the word rootwait to the very end of those lines
3. Unmount the partition under /Mount/GoboLinux and reboot.

For UEFI mode:

1. Mount your boot partition (the one with a FAT filesystem) using the LiveCD under /Mount/GoboLinux
2. Edit the file at /Mount/GoboLinux/EFI/BOOT/grub-efi.cfg. Look for the lines starting with linux /System/Kernel/Boot/kernel-4.8.2-Gobo and append the word rootwait to the very end of those lines
3. Regenerate the UEFI application. This is a large command, so it’s better to just copy+paste it.

cd /Mount/GoboLinux/EFI/BOOT
grub-mkstandalone-efi -d /lib/grub/x86_64-efi -O x86_64-efi --modules="part_gpt part_msdos iso9660 all_video efi_gop efi_uga video_cirrus gfxterm gettext font" --fonts="unicode" --themes="" -o BOOTx64.EFI --compress=gz "boot/grub/grub.cfg=grub-efi.cfg"

Afterwards, unmount the partition under /Mount/GoboLinux and reboot.

Using binary packages

Binary packages in GoboLinux are precompiled software packages built for the GoboLinux directory tree and made available through the GoboLinux software repository (recipe store). Since these packages are already compiled, you can save the many hours needed to build larger applications. On the other hand, with binary packages you don’t have the ability to set compile flags for optimization or specific architectures.

Installing packages

InstallPackage is the GoboLinux script for installing binary packages. If you want InstallPackage to look for the most recent Gimp package available, you can run

InstallPackage Gimp

The script will check if the package is available in the GoboLinux repositories. (See /System/Settings/GetAvailable.conf for the specific URLs scanned. You may add your own repositories if you desire.)

If you want to select a specific version, you can pass it as the second parameter:

InstallPackage Gimp 2.8.18

If you downloaded the package and want to install it, run:

InstallPackage Gimp--2.8.18--i686.tar.bz2

The script normally runs interactively, asking about each dependency of the requested package before installing it. You can avoid these queries by adding the --batch or -b flag. This is particularly useful with large packages such as Gimp or Xorg, which have many dependencies.

InstallPackage -b Gimp

Dependencies

InstallPackage will warn you if dependencies of a package you are trying to install are unavailable and ask if you want to continue. This is valuable, because some software may still work satisfactorily even if a particular plug-in or other dependency is missing.

Installing packages from the LiveCD

See Installing Packages from the LiveCD.

Removing packages

See Removing programs

Creating packages

Structure

In GoboLinux, all binary packages (as well as all user-compiled software) is installed under /Programs in a “program directory” provided for each version of each application, for example:

/Programs/Gimp/2.8.18

When compiling software under GoboLinux the installation target directories such as bin/, lib/, and etc/ that are required for a typical program are placed inside the program directory.

With this self-contained directory structure, all that is needed to generate a binary package is to make a tarball of the program directory, copy over the Resources/ directory from the Compile recipe, and generate a few additional files, which are also placed under Resources/.

This is accomplished by the CreatePackage command.

Preparation

Before creating a package, be careful to vet the contents of the program’s Settings/ directory to ensure that it does not include personal information.

A package submitted for inclusion in the GoboLinux packages repository must have sensible default settings, honoring the application defaults if possible.

The CreatePackage command

In order to create a package, run the CreatePackage utility with the package name as a parameter. For example,

CreatePackage rxvt

will create a binary package in the current working directory.

Compiling from source

Introduction

With Compile, GoboLinux build utility, software sources can be downloaded, compiled and installed in a single step. An example will follow next.

In order to install irssi, a text-based IRC client from the command line, you would type the following instruction:

Compile irssi

Depending on the speed of your computer, internet connection and what packages you have installed, Irssi should download and install in a few minutes.

Compile manages the build process using GoboLinux recipes. Each recipe contains a list of build directives and supplemental control files for compiling a particular software library.

Finding recipes

Typically, you can just try the name of the recipe you want from the command line. There is also an online recipe viewer, listing the most recently uploaded recipes first.

Command-line options

Compile has a number of command-line options, which are listed here. The following are especially useful.

When using the --batch or -b automatically attempts to process all dependencies of the requested program.

Separating download and compile phases

The next two options are useful when working with intermittent internet access, or if you’d like to run your compiling jobs at night when you’re asleep.

Calling Compile with the --no-build flag downloads sources only.

Later, in the event that you wish to use the --no-web flag, this will direct Compile to search to your system’s own download cache and build the sources found there instead. This commandline switch is obviously very useful if you do not have a working internet connection for the time being.

Writing recipes

Main article: Writing recipes

Getting the latest Compile

• To use the development version of Compile, run

Compile Compile git

• To use the latest stable version, run

InstallPackage Compile

In general it is recommended to always use the latest stable version of Compile. Compile is very important to GoboLinux so if there is any problem in it, it is normally fixed very quickly.

Steps of the compile process

Normally, you shouldn’t need to compile “manually”, i.e., without using the Compile tool. However, it is possible to manually run the same commands that Compile uses.

Overview

Compiling programs in Linux is typically a three-part process: prepare the sources with ./configure, compile them with make, and install the compiled program with make install.

To this process, Gobo adds a source configuration step to target the GoboLinux directory structure, and after the install phase, a step that symlinks the files from the application directory under /Programs to /System/Index. It is this last step that makes programs “visible” to the GoboLinux system.

These are the relevant commands:

• PrepareProgram
• SandboxInstall
• SymlinkProgram

PrepareProgram is a wrapper to the first step described above. SandboxInstall is a wrapper to the third step, ensuring safe execution of make install. SymlinkProgram performs the final operations that integrate the new program into the system.

Setting up the sources: PrepareProgram

The PrepareProgram script does two things. It creates a directory hierarchy for the program under /Programs, and it attempts to prepare the sources for compilation.

The syntax for the PrepareProgram is:.

PrepareProgram <program-name> <version-number> [ -- <additional-options> ]

Passing a program name and version number is mandatory. These names are the ones used in the directories under programs. For example,

PrepareProgram --tree Foo 1.0

(the --tree switch) creates the directories /Programs/Foo/Settings, /Programs/Foo/1.0, /Programs/Foo/1.0/bin and so on.

The second task performed by PrepareProgram is to prepare the sources. Since there isn’t a standardized format for distribution of source-code tarballs in the free software world, there is no way to implement completely automated preparation. Fortunately, the popularization of the GNU AutoTools brings us much closer.

PrepareProgram, in this second step, will detect availability of preparation tools and perform one of the following:

1. If the program includes a configure script generated by GNU autoconf, PrepareProgram will run it, passing the necessary options (mainly --prefix, --sysconfdir) as well as any additional options requested by the user in the command line (as <additional-options>).
2. Some authors develop their own configure scripts, but due to the popularity of GNU autoconf, design a command line interface similar to that used by autoconf. PrepareProgram tries to detect if a non-autoconf configure script accepts at least the --prefix option, and uses it.

In short, PrepareProgram can be considered a wrapper to configure. Instead of running, for example,

cd foo-1.0
./configure --with-shared=yes

you’ll run

cd foo-1.0
PrepareProgram Foo 1.0 -- --with-shared=yes

SandboxInstall

Strictly speaking, if everything were configured correctly you could simply run make and make install, and all files would be installed under the appropriate subdirectory under Programs/.

To ensure this happens is to guarantee the modularity of the software installation.

To prevent any possibility of files being copied elsewhere in the directory tree than the target under /Programs, GoboLinux conducts the install step in a “sandbox” that is isolated from the rest of the filesystem.

SandboxInstall constructs a container for make install. It uses a sandbox provided by the FiboSandbox script, which configures custom permissions for an allowed set of paths to a special user, fibo. On systems with a UnionFS backend (such as FunionFS, UnionFS-FUSE or OverlayFS), the sandbox is provided by the alternative script UnionSandbox. Installation then runs confined to a sandbox, with no permission to write anywhere but the few places SandboxInstall allows it to, such as /Programs/Foo/Current and /Programs/Foo/Settings. Therefore, no files can be installed in “random places”. A typical call to SandboxInstall looks like this:

SandboxInstall Foo 1.0

If necessary, additional options can be passed. Refer to the SandboxInstall reference page for details.

Linking the sources: SymlinkProgram

The final step in the compilation of a program is performed by the SymlinkProgram. This is the script responsible for creating the symbolic links under /System/Index.

The syntax for SymlinkProgram is:

SymlinkProgram program-name [ version-number ]

The second argument is optional. If no version number is specified, the one linked as Current will be used. A commonly used command-line parameter is -c overwrite, which tells it to overwrite any existing symlinks in case of conflicts (the default action is to preserve the existing links in order to not affect previously existing applications). To integrate a program Foo into the /System structure, overwriting any links, you would type:

SymlinkProgram -c overwrite Foo

SymlinkProgram features many command-line switches, to cover more advanced needs. You can refer to the SymlinkProgram reference page for details if necessary.

Removing programs

In GoboLinux, all programs, whether binary packages or user-compiled software, are installed into a single directory under the /Programs hierarchy, such as, for instance, gimp:

/Programs/Gimp/2.8.18

Removing this program can be, in theory, as simple as:

rm -rf Gimp/2.8.18 

But since this leaves behind dangling symlinks, GoboLinux offers the RemoveProgram utility, which removes the program and all links pointing to its files in /System/Index.

RemoveProgram Gimp 2.8.18

Sometimes you may want to “turn off” a program temporarily, without erasing it from your hard disk. In other words, you want to remove program’s executables from the execution path, and remove libraries and headers from the lookup path.

In GoboLinux, this can be accomplished by removing the associated symlinks for /System/Index. The DisableProgram script facilitates this:

DisableProgram gimp 2.1.18

The version parameter given here, in this case 2.1.18, is optional. If it is not provided, the Current link is used to determine the program version to disable. Also note that the program name is case insensitive, but it appears to be simpler to use a downcased variant - easier to type at the least.

To re-enable the program, all you need to do is recreate the symbolic links:

SymlinkProgram gimp 2.1.18

Maintaining symlinks

GoboLinux has a script called RemoveBroken. that removes dangling symlinks from /System/Index tree. It can be useful to run after manipulating directories under /Programs.

RemoveBroken takes a list of files, and removes those that are dangling symlinks. If no arguments are provided, the script takes filenames from standard input (typically through a pipe).

The usual procedure to clean up dangling links, is

cd /System/Index
find | RemoveBroken

Understanding and Maintaining system indices

The two main parts of GoboLinux are /Programs and /System. If you stick to using InstallPackage and Compile, these two parts will be implicitly kept in sync by SymlinkProgram. But a lot of power lies in the fact that you can tune how these two worlds interact.

Program entries under /Programs feature a Current symlink pointing to a specific version that is “active” in the system. This Current version is taken as the default version when you don’t specify a version in scripts, and the link is updated when you install a new version with InstallPackage or Compile.

That doesn’t mean that you can only have one version linked into the system: you can have files of multiple versions show up in /Programs. In fact, when you install a new version with InstallPackage but keep the old version in /Programs, files for which there’s no version with the same name in the new package are still linked – this is especially useful for libraries.

For example, say program Foo 1.0 looks like this:

/Programs/Foo/1.0/bin/foo
/Programs/Foo/1.0/include/foo.h
/Programs/Foo/1.0/lib/libfoo.so.1
/Programs/Foo/1.0/lib/libfoo.so -> libfoo.so.1

Now, say, you install a new version, 2.0, which looks like this:

/Programs/Foo/2.0/bin/foo
/Programs/Foo/2.0/include/foo.h
/Programs/Foo/2.0/lib/libfoo.so.2
/Programs/Foo/2.0/lib/libfoo.so -> libfoo.so.2

The default behavior of SymlinkProgram is to replace symlinks under /Programs that belong to a different version of the same program. So, now, we’ll have the following links related to Foo under system:

/System/Index/bin/foo -> /Programs/Foo/2.0/bin/foo
/System/Index/include/foo.h -> /Programs/Foo/2.0/include/foo.h
/System/Index/lib/libfoo.so.2 -> /Programs/Foo/2.0/lib/libfoo.so.2
/System/Index/lib/libfoo.so -> /Programs/Foo/2.0/lib/libfoo.so.2
/System/Index/lib/libfoo.so.1 -> /Programs/Foo/1.0/lib/libfoo.so.1

So, now, when you run foo, it will fetch version 2.0 of the program through your system $PATH (which looks at /System/Index/bin). But, as you can see, libfoo.so.1 is still there. This way, if you have other programs installed in the system that are linked specifically to version 1 of the libfoo library will continue working.

This means you won’t have the old problem “I upgraded package Foo and now my other apps are broken”. Of course, you can still break things when you remove a version which other programs depend in (or if buggy programs link to a version independent name of a library (libfoo.so) but depend on features of a specific version).

Besides SymlinkProgram (see section “Compiling manually” and its reference entry for details on it), there are other scripts that give you more control over what is linked in the system and what is not.

With DisableProgram, you can remove from /System all links that refer to a specific version of a program, effectively “turning it off” – it is as if it were not present in the system.

With RemoveProgram, you can remove a program from /Programs and its references from /System in a single step.

See Removing programs for more details.

Updating packages

Overview

Use the UpdateRecipes command to refresh your local cache of the GoboLinux recipe store.

You can query available updates using the utilities SuggestUpdates and SuggestDuplicates. The output of each of these commands is suitable for piping into commands.

The FindPackage and GetAvailable commands may also be useful.

Example Update Process

Keep in mind that most operations that change the file-system state in Gobo require super user privileges:

Ensure that Scripts are up to date

cd /Programs/Scripts/Current
sudo git pull && sudo UpdateSettings --auto Scripts && sudo make

Ensure that Compile is up to date

cd /Programs/Compile/Current
sudo git pull && sudo UpdateSettings --auto Compile

UpdateRecipes - Update local copy of recipe store

cd /Data/Compile/Recipes
sudo UpdateRecipes

SuggestUpdates - List packages with an update available

cd /Data/Compile/Recipes
SuggestUpdates

Install updates

Currently, there is no way to update packages automatically. This used to be done with the Freshen script, which is currently not in working order.

Updates thus need to be installed manually via InstallPackage or Compile as appropriate.

Dependencies blacklist

Configuring Dependencies

Today there are many programs implementing a given feature in different ways. One such example is the OpenGL API, with implementations floating in packages such as Xorg, MesaLib and Nvidia. However, not every user owns a Nvidia card, and here comes a problem: how should one mask Nvidia from the automated Dependencies list generated after creating a recipe? This problem is now fixed with a configurable file called /Programs/Scripts/Settings/Scripts/Dependencies.blacklist.

Dependencies.blacklist

This file allows one to specify packages that should not appear in the Dependencies file after creating a new recipe. Its format is pretty simple: one package per line, without the need to specify its version.

A Dependencies.blacklist example

The following example blacklists the packages Glibc and Nvidia. Comments and blank lines are ignored by the parser, so it’s ok to include them.

# Dependencies.blacklist is documented in detail at
#  http://wiki.gobolinux.org/Dependencies

Glibc
Nvidia

Note: presently blacklisting specific versions is not supported, but the same behaviour can be achieved by creating an empty directory in the /Programs directory. For example, to blacklist GCC version 4.1.2 you may:

mkdir /Programs/GCC/4.1.2

Guidlines for script authors

This section documents the coding style used in GoboLinux shell scripts.

It’s important to note that not all scripts follow these guidelines, because of historical baggage (some of the scripts are older than GoboLinux itself). Patches to correct the non-conformities are welcome.

Indentation and block organization

A few rules of thumb:

• Three spaces for indentation. Avoid joining do and then in the same line with ;, instead put it on a line by itself, aligned with for, while or if.
• Prefer using if rather than idioms like && { }, but apply your common sense.
• Be generous in you use of quotes whenever referring or defining variables, and the ${x} syntax when merging variables inside strings.
• Bear in mind that esac is ridiculous.
• When doing weird stuff such as functional-like programming with eval, hide it in a pretty function to pretend it is a bit more readable. Eventually we might make a Functional module. By now, Map() is defined in the Array module.

It’s hard to believe, but the only shell module containing GoboLinux-specific stuff is the one aptly called GoboLinux. Keep that in mind when submitting functions for inclusion in one of the modules.

Names

The idea in the naming convention is to orthogonally describe scope and purpose of each name. We define “local scope” as names that are specific to a given script, and “library scope” as names defined in Scripts modules such as GoboPath, ScriptFunctions or one of the imported function modules.

These are the guidelines:

• Function names have underscores between words

Example: local_function, Library_Function

• Variable names do not, they’re just connected

Example: localvariable, LibraryVariable

• Library names (for functions and variables) have capital letters

Example: Library_Function, LibraryVariable

• Local names (for functions and variables) are in all-lowercase

Example: local_function, localvariable

• All-uppercase variables are reserved for standard Unix usage

Example: PATH, LD_LIBRARY_PATH

• Configuration variables used in .conf files start with the script name in lowercase, resulting in a case style similar to that used in Java variables

Example: compileRecipeDirs, editKeymapLayout

Awesome

Overview

Awesome is the current desktop manager for Gobolinux.

Several modules have been created for Awesome for use by Gobolinux:

• General Utilities
• GoboNet
• Alt-Tab
• Battery
• Light
• Sound

Links

• Homepage: https://awesomewm.org/

Enlightenment

Overview

Enlightenment was the previous default DE used by Gobolinux. Its current compile status is unknown

Links

• Homepage - https://www.enlightenment.org/

LXDE

Overview

LXDE is a lightweight desktop environment.

Installation

• Compile lxde by typing Compile LXDE in a commandline. Download all dependencies when prompted.
• Add Exec lxsession to .xinitrc.
• LXDE can then be run by calling startx after logging in.

TODO

• Add LXDM to LXDE recipes
• Add option to set LXDM as default display manager