The answer to every question is “Read the documentation.” However, for convenience, the most common problem solutions are addressed here.
Read about Exherbo’s features.
If the repository is in unavailable then use cave resolve. For repository x11:
# cave resolve repository/x11 -1xautomatically creates a repository configuration file for x11 and then syncs the newly created repository.
Make sure that you have /etc/paludis/repositories/repository.conf with the following content:
format = repository
config_filename = /etc/paludis/repositories/%{repository_template_name}.conf
config_template = /etc/paludis/repository.templateand /etc/paludis/repository.template with the following:
format = %{repository_template_format}
location = /var/db/paludis/repositories/%{repository_template_name}
sync = %{repository_template_sync}To manually add a repository, create a configuration file /etc/paludis/repositories/<repo_name>.conf containing the following:
format = e
location = ${root}/var/db/paludis/repositories/<repo_name>
sync = https://gitlab.exherbo.org/exherbo/<repo_name>.gitReplace <repo_name> with the name of the repository, and if it’s a third party repository the entire URL specified for sync will differ.
If you always want to sync a branch other than master – such as multilib – specify it in the new configuration file like so:
sync_options = --branch=multilibIf you have not yet configured caching, add the following to /etc/paludis/repository_defaults.conf:
names_cache = ${root}/var/cache/paludis/names
write_cache = ${root}/var/cache/paludis/metadataDon’t forget to prepend x- to the repository name when syncing for the first time, e.g. for repository foo:
# cave sync x-fooFor more detailed information about repository configuration please consult the Paludis documentation on the e repository format.
If you have the source unpacked and you already performed ./configure && make && make install
DESTDIR=/home/user/src/foo-0.3.4/ on it for example, import it as a Paludis-manageable package like so:
# cave import --location /home/user/src/foo-0.3.4/ category/bar 0.3.4 0 --executeTo search for all packages containing “vim” in their names, do:
# cave search --name vimSee man cave-search for other search options.
It may be of use to generate a search index and use it, as it speeds up the search greatly. See man cave-manage-search-index for more information.
If you’re looking for a specific package, it is likely quicker to use cave show to look for the package. cave search vim would look through the entire tree, cave show vim would just look for a package named vim. Pay close attention to cave‘s suggestions as well; cave show vi will suggest you meant vim instead.
There’s also Summer available to use.
# cave show */*::/See Exheres for Smarties.
# eclectic configFor example perl:
# cave resolve --reinstall-dependents-of dev-lang/perl nothingIt is a good idea to carefully read every error message output by Paludis – they are verbose for a reason and easy to understand.
Masked packages cause Paludis to output the error:
* All versions of 'category/package' are masked. Candidates are:followed by a list of packages and reasons for the masking. These reasons are explained below, along with what action is needed to fix the problem.
* dev-perl/XML-Simple-2.18:0::unavailable (in ::perl): Masked by unavailable
(In a repository which is unavailable)Install the perl repository. See: How do I add new repositories?
* net-fs/samba-3.0.32:0::unwritten: Masked by unwritten (Package has not been
written yet)This means the package hasn’t been written. Try cave show samba, then see: How do I add new repositories?
* sys-boot/grub-1.96:0::arbor: Masked by platform (~x86)This means that the package in question has either not been tested on your platform or might not work on your platform. You can bypass this mask by configuring the package for your platform locally:
# echo "sys-boot/grub ~x86" >> /etc/paludis/platforms.confIf the package works on your platform, please submit a patch to Exherbo adding it to PLATFORMS (see Exheres for Smarties and the documentation on contributing.
If you get this error in a chroot:
* When creating pty FDs:
* posix_openpt(3) failed: No such file or directory (paludis::PtyError)the problem is that /dev/pts is missing in the chroot. Perform the following command to bind-mount /dev properly:
# mount -o rbind /dev /mnt/exherbo/dev* Could not generate cache for 'sys-apps/systemd-207-r2::arbor', stdout says '' and stderr says 'seccomp_init failed (errno:22 Invalid argument)This means that your kernel version is too old. In the standard configuration with the seccomp option enabled Sydbox needs a kernel greater than 3.5.0. When following the Install Guide make sure to select SystemRescueCD’s alternative kernel.
The current scm version of Sydbox detects a non-supported kernel and disables seccomp support. So unmasking and updating to this version can help.
Otherwise you might want to disable sydbox via export PALUDIS_DO_NOTHING_SANDBOXY=1 or disable Sydbox’s seccomp option until you have a kernel with a supported version and seccomp support.
Sydbox is a new sandboxing application so it’s quite possible that you may have problems with it. Known problems and solutions are given here.
This is probably because you’re running a kernel version older than 2.6.29 which has a ptrace() bug. To fix the issue either upgrade your kernel to a recent version or apply this patch.
This is because the program you’re running under Sydbox is either creating a very long directory structure or it’s creating lots of simultaneous threads. For the former issue, it usually helps to disable the lstat() wrapper of Sydbox with esandbox nohack_toolong. For the latter issue, you may try decreasing the number of simultaneous threads.
This can happen if your build directory is beneath a symlinked directory or is a symbolic link itself, since mkdir() resolves symbolic links and so does Sydbox.
Copyright 2008, 2009 Jonathan Dahan Copyright 2010 Ali Polatel