neulab/tldr huggingface dataset:
Before using "tlmgr" in user mode, you have to set up the user tree with the "init-usertree" action.  This creates usertree"/web2c" and usertree"/tlpkg/tlpobj", and a minimal usertree"/tlpkg/texlive.tlpdb". At that point, you can tell "tlmgr" to do the (supported) actions by adding the "--usermode" command line option.
In user mode the file usertree"/tlpkg/texlive.tlpdb" contains only the packages that have been installed into the user tree using "tlmgr", plus additional options from the ``virtual'' package "00texlive.installation" (similar to the main installation's "texlive.tlpdb").
All actions on packages in user mode can only be carried out on packages that are known as "relocatable".  This excludes all packages containing executables and a few other core packages.  Of the 2500 or so packages currently in TeX Live the vast majority are relocatable and can be installed into a user tree.
Description of changes of actions in user mode:
User mode install In user mode, the "install" action checks that the package and all dependencies are all either relocated or already installed in the system installation.  If this is the case, it unpacks all containers to be installed into the user tree (to repeat, that's either "TEXMFHOME" or the value of "--usertree") and add the respective packages to the user tree's "texlive.tlpdb" (creating it if need be).
Currently installing a collection in user mode installs all dependent packages, but in contrast to normal mode, does not install dependent collections.  For example, in normal mode "tlmgr install collection-context" would install "collection-basic" and other collections, while in user mode, only the packages mentioned in "collection-context" are installed.
If a package shipping map files is installed in user mode, a backup of the user's "updmap.cfg" in "USERTREE/web2c/" is made, and then this file regenerated from the list of installed packages.
User mode backup, restore, remove, update In user mode, these actions check that all packages to be acted on are installed in the user tree before proceeding; otherwise, they behave just as in normal mode.
User mode generate, option, paper In user mode, these actions operate only on the user tree's configuration files and/or "texlive.tlpdb".  creates configuration files in user tree
The main TeX Live repository contains a vast array of packages. Nevertheless, additional local repositories can be useful to provide locally-installed resources, such as proprietary fonts and house styles. Also, alternative package repositories distribute packages that cannot or should not be included in TeX Live, for whatever reason.
The simplest and most reliable method is to temporarily set the installation source to any repository (with the "-repository" or "option repository" command line options), and perform your operations.
When you are using multiple repositories over a sustained length of time, however, explicitly switching between them becomes inconvenient.  Thus, it's possible to tell "tlmgr" about additional repositories you want to use.  The basic command is "tlmgr repository add".  The rest of this section explains further.
When using multiple repositories, one of them has to be set as the main repository, which distributes most of the installed packages.  When you switch from a single repository installation to a multiple repository installation, the previous sole repository will be set as the main repository.
By default, even if multiple repositories are configured, packages are still only installed from the main repository.  Thus, simply adding a second repository does not actually enable installation of anything from there.  You also have to specify which packages should be taken from the new repository, by specifying so-called ``pinning'' rules, described next.
Pinning When a package "foo" is pinned to a repository, a package "foo" in any other repository, even if it has a higher revision number, will not be considered an installable candidate.
As mentioned above, by default everything is pinned to the main repository.  Let's now go through an example of setting up a second repository and enabling updates of a package from it.
First, check that we have support for multiple repositories, and have only one enabled (as is the case by default):
$ tlmgr repository list List of repositories (with tags if set): /var/www/norbert/tlnet
Ok.  Let's add the "tlcontrib" repository (this is a real repository hosted at <http://contrib.texlive.info>) with the tag "tlcontrib":
$ tlmgr repository add http://contrib.texlive.info/current tlcontrib
Check the repository list again:
$ tlmgr repository list List of repositories (with tags if set): http://contrib.texlive.info/current (tlcontrib) /var/www/norbert/tlnet (main)
Now we specify a pinning entry to get the package "classico" from "tlcontrib":
$ tlmgr pinning add tlcontrib classico
Check that we can find "classico":
$ tlmgr show classico package:     classico ... shortdesc:   URW Classico fonts ...
- install "classico":
$ tlmgr install classico tlmgr: package repositories: ... [1/1,  ??:??/??:??] install: classico @tlcontrib [737k]
In the output here you can see that the "classico" package has been installed from the "tlcontrib" repository (@tlcontrib).
Finally, "tlmgr pinning" also supports removing certain or all packages from a given repository:
$ tlmgr pinning remove tlcontrib classico # remove just classico $ tlmgr pinning remove tlcontrib --all    # take nothing from tlcontrib
A summary of the "tlmgr pinning" actions is given above.
The graphical user interface for "tlmgr" requires Perl/Tk <https://search.cpan.org/search?query=perl%2Ftk>.  For Windows the necessary modules are shipped within TeX Live, for all other (i.e., Unix- based) systems Perl/Tk (as well as Perl of course) has to be installed outside of TL.  <https://tug.org/texlive/distro.html#perltk> has a list of invocations for some distros.
The GUI is started with the invocation "tlmgr gui"; assuming Tk is loadable, the graphical user interface will be shown.  The main window contains a menu bar, the main display, and a status area where messages normally shown on the console are displayed.
Within the main display there are three main parts: the "Display configuration" area, the list of packages, and the action buttons.
Also, at the top right the currently loaded repository is shown; this also acts as a button and when clicked will try to load the default repository.  To load a different repository, see the "tlmgr" menu item.
Finally, the status area at the bottom of the window gives additional information about what is going on.
Main display Display configuration area
The first part of the main display allows you to specify (filter) which packages are shown.  By default, all are shown.  Changes here are reflected right away.
Status Select whether to show all packages (the default), only those installed, only those not installed, or only those with update available.
Category Select which categories are shown: packages, collections, and/or schemes.  These are briefly explained in the "DESCRIPTION" section above.
Match Select packages matching for a specific pattern.  By default, this searches both descriptions and filenames.  You can also select a subset for searching.
Selection Select packages to those selected, those not selected, or all.  Here, ``selected'' means that the checkbox in the beginning of the line of a package is ticked.
Display configuration buttons To the right there are three buttons: select all packages, select none (a.k.a. deselect all), and reset all these filters to the defaults, i.e., show all available.
Package list area
The second are of the main display lists all installed packages.  If a repository is loaded, those that are available but not installed are also listed.
Double clicking on a package line pops up an informational window with further details: the long description, included files, etc.
Each line of the package list consists of the following items:
a checkbox Used to select particular packages; some of the action buttons (see below) work only on the selected packages.
package name The name (identifier) of the package as given in the database.
local revision (and version) If the package is installed the TeX Live revision number for the installed package will be shown.  If there is a catalogue version given in the database for this package, it will be shown in parentheses.  However, the catalogue version, unlike the TL revision, is not guaranteed to reflect what is actually installed.
remote revision (and version) If a repository has been loaded the revision of the package in the repository (if present) is shown.  As with the local column, if a catalogue version is provided it will be displayed.  And also as with the local column, the catalogue version may be stale.
short description The short description of the package.
Main display action buttons
Below the list of packages are several buttons:
Update all installed This calls "tlmgr update --all", i.e., tries to update all available packages.  Below this button is a toggle to allow reinstallation of previously removed packages as part of this action.
The other four buttons only work on the selected packages, i.e., those where the checkbox at the beginning of the package line is ticked.
Update Update only the selected packages.
Install Install the selected packages; acts like "tlmgr install", i.e., also installs dependencies.  Thus, installing a collection installs all its constituent packages.
Remove Removes the selected packages; acts like "tlmgr remove", i.e., it will also remove dependencies of collections (but not dependencies of normal packages).
Backup Makes a backup of the selected packages; acts like "tlmgr backup". This action needs the option "backupdir" set (see "Options -" General>).
Menu bar The following entries can be found in the menu bar:
"tlmgr" menu The items here load various repositories: the default as specified in the TeX Live database, the default network repository, the repository specified on the command line (if any), and an arbitrarily manually- entered one.  Also has the so-necessary "quit" operation.
"Options menu" Provides access to several groups of options: "Paper" (configuration of default paper sizes), "Platforms" (only on Unix, configuration of the supported/installed platforms), "GUI Language" (select language used in the GUI interface), and "General" (everything else).
Several toggles are also here.  The first is "Expert options", which is set by default.  If you turn this off, the next time you start the GUI a simplified screen will be shown that display only the most important functionality.  This setting is saved in the configuration file of "tlmgr"; see "CONFIGURATION FILE FOR TLMGR" for details.
The other toggles are all off by default: for debugging output, to disable the automatic installation of new packages, and to disable the automatic removal of packages deleted from the server.  Playing with the choices of what is or isn't installed may lead to an inconsistent TeX Live installation; e.g., when a package is renamed.
"Actions menu" Provides access to several actions: update the filename database (aka "ls-R", "mktexlsr", "texhash"), rebuild all formats ("fmtutil-sys --all"), update the font map database ("updmap-sys"), restore from a backup of a package, and use of symbolic links in system directories (not on Windows).
The final action is to remove the entire TeX Live installation (also not on Windows).
"Help menu" Provides access to the TeX Live manual (also on the web at <https://tug.org/texlive/doc.html>) and the usual ``About'' box.
GUI options Some generic Perl/Tk options can be specified with "tlmgr gui" to control the display:
"-background" color Set background color.
"-font "" fontname fontsize """ Set font, e.g., "tlmgr gui -font "helvetica 18"".  The argument to "-font" must be quoted, i.e., passed as a single string.
"-foreground" color Set foreground color.
"-geometry" geomspec Set the X geometry, e.g., "tlmgr gui -geometry 1024x512-0+0" creates the window of (approximately) the given size in the upper-right corner of the display.
"-xrm" xresource Pass the arbitrary X resource string xresource.
A few other obscure options are recognized but not mentioned here.  See the Perl/Tk documentation (<https://search.cpan.org/perldoc?Tk>) for the complete list, and any X documentation for general information.
MACHINE-READABLE OUTPUT With the "--machine-readable" option, "tlmgr" writes to stdout in the fixed line-oriented format described here, and the usual informational messages for human consumption are written to stderr (normally they are written to stdout).  The idea is that a program can get all the information it needs by reading stdout.
Currently this option only applies to the update, install, and "option" actions.
Machine-readable "update" and "install" output The output format is as follows:
fieldname "\t" value ... "end-of-header" pkgname status localrev serverrev size runtime esttot ... "end-of-updates" other output from post actions, not in machine readable form
The header section currently has two fields: "location-url" (the repository source from which updates are being drawn), and "total-bytes" (the total number of bytes to be downloaded).
The localrev and serverrev fields for each package are the revision numbers in the local installation and server repository, respectively. The size field is the number of bytes to be downloaded, i.e., the size of the compressed tar file for a network installation, not the unpacked size. The runtime and esttot fields are only present for updated and auto-install packages, and contain the currently passed time since start of installation/updates and the estimated total time.
"location-url" location The location may be a url (including "file:///foo/bar/..."), or a directory name ("/foo/bar").  It is the package repository from which the new package information was drawn.
"total-bytes" count The count is simply a decimal number, the sum of the sizes of all the packages that need updating or installing (which are listed subsequently).
Then comes a line with only the literal string "end-of-header".
Each following line until a line with literal string "end-of-updates" reports on one package.  The fields on each line are separated by a tab. Here are the fields.
pkgname The TeX Live package identifier, with a possible platform suffix for executables.  For instance, "pdftex" and "pdftex.i386-linux" are given as two separate packages, one on each line.
status The status of the package update.  One character, as follows:
"d"     The package was removed on the server.
"f"     The package was removed in the local installation, even though a collection depended on it.  (E.g., the user ran "tlmgr remove --force".)
"u"     Normal update is needed.
"r"     Reversed non-update: the locally-installed version is newer than the version on the server.
"a"     Automatically-determined need for installation, the package is new on the server and is (most probably) part of an installed collection.
"i"     Package will be installed and isn't present in the local installation (action install).
"I"     Package is already present but will be reinstalled (action install).
localrev The revision number of the installed package, or "-" if it is not present locally.
serverrev The revision number of the package on the server, or "-" if it is not present on the server.
size The size in bytes of the package on the server.  The sum of all the package sizes is given in the "total-bytes" header field mentioned above.
runtime The run time since start of installations or updates.
esttot The estimated total time.
Machine-readable "option" output The output format is as follows:
key "\t" value
If a value is not saved in the database the string "(not set)" is shown.
If you are developing a program that uses this output, and find that changes would be helpful, do not hesitate to write the mailing list.
"tlmgr" uses many of the standard TeX environment variables, as reported by, e.g., "tlmgr conf" ("conf").
In addition, for ease in scripting and debugging, "tlmgr" looks for the following environment variables. These are not of interest for normal user installations.
"TEXLIVE_COMPRESSOR" This option allows selecting a different compressor program for backups and intermediate rollback containers. The order of selection is:
1.      If the environment variable "TEXLIVE_COMPRESSOR" is defined, use it; abort if it doesn't work. Possible values: "lz4", "gzip", "xz". The necessary options are added internally.
2.      If lz4 is available (either from the system or TL) and working, use that.
3.      If gzip is available (from the system) and working, use that.
4.      If xz is available (either from the system or TL) and working, use that.
lz4 and gzip are much faster in creating tlmgr's local backups.  The unconditional use of xz for the tlnet containers is unaffected, to minimize download sizes.
"TEXLIVE_DOWNLOADER" "TL_DOWNLOAD_PROGRAM" "TL_DOWNLOAD_ARGS" These options allow selecting different download programs then the ones automatically selected by the installer. The order of selection is:
1.      If the environment variable "TEXLIVE_DOWNLOADER" is defined, use it; abort if the specified program doesn't work. Possible values: "lwp", "curl", "wget". The necessary options are added internally.
2.      If the environment variable "TL_DOWNLOAD_PROGRAM" is defined (can be any value), use it together with "TL_DOWNLOAD_ARGS"; abort if it doesn't work.
3.      If LWP is available and working, use that (by far the most efficient method, as it supports persistent downloads).
4.      If curl is available (from the system) and working, use that.
5.      If wget is available (either from the system or TL) and working, use that.
TL provides "wget" binaries for platforms where necessary, so some download method should always be available.
"TEXLIVE_PREFER_OWN" By default, compression and download programs provided by the system, i.e., found along "PATH" are preferred over those shipped with TeX Live.
This can create problems with systems that are too old, and so can be overridden by setting the environment variable "TEXLIVE_PREFER_OWN" to 1. In this case, executables shipped with TL will be preferred.
Extra compression/download programs not provided by TL, such as gzip, lwp, and curl, are still checked for on the system and used if available, per the above. "TEXLIVE_PREFER_OWN" only applies when the program being checked for is shipped with TL, namely the lz4 and xz compressors and wget downloader.
Exception: on Windows, the "tar.exe" shipped with TL is always used, regardless of any setting.
This script and its documentation were written for the TeX Live distribution (<https://tug.org/texlive>) and both are licensed under the GNU General Public License Version 2 or later.
$Id: tlmgr.pl 49885 2019-01-31 19:27:00Z karl $
ARCH(1)                           User Commands                          ARCH(1)
arch - print machine hardware name (same as uname -m)
arch [OPTION]...
Print machine architecture.
Written by David MacKenzie and Karel Zak.
uname(1), uname(2)
Full documentation <https://www.gnu.org/software/coreutils/arch> or available locally via: info '(coreutils) arch invocation'
SCHROOT(1)                        Debian sbuild                       SCHROOT(1)
schroot - securely enter a chroot environment
schroot [-h|--help | -V|--version  | -l|--list | -i|--info  | --config | --location  | --automatic-session  | -b|--begin-session | --recover-session  | -r|--run-session | -e|--end-session] [-f|--force] [-n session-name|--session-name=session-name] [-d directory|--directory=directory] [-u user|--user=user] [-p|--preserve-environment] [-s shell|--shell=shell] [-q|--quiet | -v|--verbose] [-c chroot|--chroot=chroot  | [--all | --all-chroots | --all-source-chroots | --all-sessions] [--exclude-aliases]] [-o|--option=key=value] [--] [COMMAND [ ARG1 [ ARG2 [ ARGn]]]]
schroot allows the user to run a command or a login shell in a chroot environment.  If no command is specified, a login shell will be started in the user's current working directory inside the chroot.
The command is a program, plus as many optional arguments as required. Each argument may be separately quoted.
The directory the command or login shell is run in depends upon the context.  See --directory option below for a complete description.
All chroot usage will be logged in the system logs.  Under some circumstances, the user may be required to authenticate themselves; see the section “Authentication”, below.
If no chroot is specified, the chroot name or alias ‘default’ will be used as a fallback.  This is equivalent to “--chroot=default”.
There is often a need to run programs in a virtualised environment rather than on the host system directly.  Unlike other virtualisation systems such as kvm or Xen, schroot does not virtualise the entire system; it only virtualises the filesystem, and some parts of the filesystem may still be shared with the host.  It is therefore fast, lightweight and flexible.  However, it does not virtualise other aspects of the system, such as shared memory, networking, devices etc., and so may be less secure than other systems, depending upon its intended use.  Some examples of existing uses for schroot include:
•      Running an untrusted program in a sandbox, so that it can't interfere with files on the host system; this may also be used to limit the damage a compromised service can inflict upon the host
•      Using a defined or clean environment, to guarantee the reproducibility and integrity of a given task
•      Using different versions of an operating system, or even different operating systems altogether, e.g. different GNU/Linux distributions
•      Running 32-bit programs using a 32-bit chroot on a 64-bit host system
•      Automatic building of Debian packages using sbuild(1), which builds each package in a pristine chroot snapshot when using LVM snapshots or unions
•      Supporting multiple system images in a cluster setup, where modifying the base image is time-consuming and/or supporting all the required configurations needed by users is difficult: different chroots can support all the different configurations required, and cluster users may be given access to the chroots they need (which can include root access for trusted users to maintain their own images)
A chroot may be used directly as root by running chroot(8), but normal users are not able to use this command.  schroot allows access to chroots for normal users using the same mechanism, but with several additional features.  While schroot uses a directory as a chroot just like chroot(8), it does not require this to be a regular directory in the filesystem.  While this is the default, the chroot can also be created from a file, a filesystem, including LVM and Btrfs snapshots and loopback mounts, or composed of a unionfs overlay.  Being user-extensible, the scope for creating chroots from different sources is limited only by your imagination.  schroot performs permissions checking and allows additional automated setup of the chroot environment, such as mounting additional filesystems and other configuration tasks.  This automated setup is done through the action of setup scripts which may be customised and extended to perform any actions required.  Typical actions include mounting the user's home directory, setting up networking and system databases, and even starting up services.  These are again entirely customisable by the admin.  The setup scripts are run for all types of chroot, with the exception of the ‘plain’ type, the simplest chroot type, offering no automated setup features at all.  The configuration of schroot is covered in more detail in schroot.conf(5).
schroot accepts the following options:
Actions -h, --help Show help summary.
-l, --list List all available chroots.
-i, --info Print detailed information about the specified chroots.
--config Print configuration of the specified chroots.  This is useful for testing that the configuration in use is the same as the configuration file.  Any comments in the original file will be missing.
--location Print location (path) of the specified chroots.  Note that chroot types which can only be used within a session will not have a location until they are active.
General options -q, --quiet Print only essential messages.
Chroot selection -c, --chroot=chroot Specify a chroot or active session to use.  This option may be used multiple times to specify more than one chroot, in which case its effect is similar to --all.  The chroot name may be prefixed with a namespace; see the section “Chroot Namespaces”, below.
-a, --all Select all chroots, source chroots and active sessions.  When a command has been specified, the command will be run in all chroots, source chroots and active sessions.  If --info has been used, display information about all chroots.  This option does not make sense to use with a login shell (run when no command has been specified).  This option is equivalent to “--all-chroots --all-source-chroots --all-sessions”.
--all-chroots Select all chroots.  Identical to --all, except that source chroots and active sessions are not considered.
--all-sessions Select all active sessions.  Identical to --all, except that chroots and source chroots are not considered.
--all-source-chroots Select all source chroots.  Identical to --all, except that chroots and sessions are not considered.
--exclude-aliases Do not select aliases in addition to chroots.  This ensures that only real chroots are selected, and are only listed once.
Chroot environment -d, --directory=directory Change to directory inside the chroot before running the command or login shell.  If directory is not available, schroot will exit with an error status.
The default behaviour is as follows (all directory paths are inside the chroot).  A login shell is run in the current working directory.  If this is not available, it will try $HOME (when --preserve-environment is used), then the user's home directory, and / inside the chroot in turn.  A command is always run in the current working directory inside the chroot.  If none of the directories are available, schroot will exit with an error status.
-u, --user=user Run as a different user.  The default is to run as the current user.  If required, the user may be required to authenticate themselves with a password.  For further information, see the section “Authentication”, below.
-p, --preserve-environment Preserve the user's environment inside the chroot environment. The default is to use a clean environment; this option copies the entire user environment and sets it in the session.  The environment variables allowed are subject to certain restrictions; see the section “Environment”, below.
-s, --shell=shell Use shell as the login shell.  When running a login shell a number of potential shells will be considered, in this order: the command in the SHELL environment variable (if --preserve-environment is used, or preserve-environment is enabled), the user's shell in the ‘passwd’ database, /bin/bash and finally /bin/sh.  This option overrides this list, and will use the shell specified.  This option also overrides the shell configuration key, if set.
-o, --option=key=value Set an option.  The value of selected configuration keys in schroot.conf may be modified using this option.  The key must be present in the user-modifiable-keys configuration key in schroot.conf, or additionally the user-modifiable-keys key if running as (or switching to) the root user.  The key and value set here will be set in the environment of the setup scripts, and may hence be used to customise the chroot on a per-session basis.
Session actions --automatic-session Begin, run and end a session automatically.  This is the default action, so does not require specifying in normal operation.
-b, --begin-session Begin a session.  A unique session identifier (session ID) is returned on standard output.  The session ID is required to use the other session options.  Note that the session identifier may be specified with the --session-name option.
--recover-session Recover an existing session.  If an existing session has become unavailable, for example becoming unmounted due to a reboot, this option will make the session available for use again, for example by remounting it.  The session ID is specified with the --chroot option.
-r, --run-session Run an existing session.  The session ID is specified with the --chroot option.
-e, --end-session End an existing session.  The session ID is specified with the --chroot option.
Session options -n, --session-name=session-name Name a session.  The specified session-name replaces the default session name containing an automatically-generated session ID. The session name must not contain a namespace qualifier, since sessions are always created within the ‘session:’ namespace.  The session name is also subject to the chroot naming restrictions documented in schroot.conf(5).
-f, --force Force a session operation, even if it would otherwise fail.  This may be used to forcibly end a session, even if it has active users.  This does not guarantee that the session will be ended cleanly; filesystems may not be unmounted, for example.
Separator --     End of options.  Used to indicate the end of the schroot options; any following options will be passed to the command being run, rather than to schroot.
If the user is not an allowed user, or a member of the allowed groups (or if changing to root, the allowed root users or allowed root groups) for the specified chroot(s), permission will be immediately denied.  If switching users, and the user running the command has access, the user will be required to authenticate themselves using the credentials of the user being switched to.
On systems supporting Pluggable Authentication Modules (PAM), schroot will use PAM for authentication and authorisation of users.  If and when required, schroot will prompt for a password.  If PAM is not available, all authentication will automatically fail (user switching is not supported without PAM).
Note that when PAM is in use, the root user is not granted any special privileges by default in the program.  However, the default PAM configuration permits root to log in without a password (pam_rootok.so), but this may be disabled to prevent root from accessing any chroots except if specifically permitted.  In such a situation, root must be added to the allowed users or groups as for any other user or group.  If PAM is not available, the root user will be permitted to access all chroots, even when not explicitly granted access.
Namespace basics There are three different types of chroot: regular chroots, source chroots and session chroots.  These different types of chroot are separated into different namespaces.  A namespace is a prefix to a chroot name.  Currently there are three namespaces: ‘chroot:’, ‘source:’ and ‘session:’.  Use --list --all to list all available chroots in all namespaces.  Because ‘:’ is used as the separator between namespace and chroot names, it is not permitted to use this character in chroot names.
Depending upon the action you request schroot to take, it may look for the chroot in one of the three namespaces, or a particular namespace may be specified.  For example, a chroot named “sid” is actually named “chroot:sid” if the namespace is included, but the namespace may be omitted for most actions.
Source chroots Some chroot types, for example LVM snapshots and Btrfs snapshots, provide session-managed copy-on-write snapshots of the chroot.  These also provide a source chroot to allow easy access to the filesystem used as a source for snapshotting.  These are regular chroots as well, just with the snapshotting disabled.  For a chroot named “sid-snapshot” (i.e. with a fully qualified name of “chroot:sid-snapshot”), there will also be a corresponding source chroot named “source:sid-snapshot”.  Earlier versions of schroot provided source chroots with a ‘-source’ suffix. These are also provided for compatibility.  In this example, this would be called “chroot:sid-snapshot-source”.  These compatibility names will be dropped in a future version, so programs and scripts should switch to using the namespace-qualified names rather than the old suffix.
Session chroots All sessions created with --begin-session are placed within the ‘session:’ namespace.  A session named with --session-name may have any name, even the same name as the chroot it was created from, providing that it is unique within this namespace.  This was not permitted in previous versions of schroot which did not have namespaces.
Actions and default namespaces All actions use ‘chroot:’ as the default namespace, with some session actions being the exception.  --run-session, --recover-session and --end-session use ‘session:’ as the default namespace instead, since these actions work on session chroots.  The upshot is that the namespace is usually never required except when you need to work with a chroot in a namespace other than the default, such as when using a source chroot.  To make chroot selection unambiguous, it is always possible to use the full name including the namespace, even when not strictly required.
Performance on some filesystems, for example Btrfs, is bad when running dpkg due to the amount of fsync operations performed.  This may be mitigated by installing the eatmydata package and then adding eatmydata to the command-prefix configuration key, which disables all fsync operations.  Note that this should only be done in snapshot chroots where data loss is not an issue.  This is useful when using a chroot for package building, for example.
schroot will select an appropriate directory to use within the chroot based upon whether an interactive login shell will be used, or a command invoked, and additionally if the --directory option is used.  In the case of running commands directly, or explicitly specifying a directory, only one directory will be used for safety and consistency, while for a login shell several possibilities may be tried.  The following subsections list the fallback sequence for each case.  CWD is the current working directory, DIR is the directory specified with --directory.
Login shell ┌────────────────────┬──────────────────────────────────────────┐ │Transition          │                                          │ │(Host → Chroot)     │ Comment                                  │ ├────────────────────┼──────────────────────────────────────────┤ │CWD → CWD           │ Normal behaviour (if --directory is not  │ │                    │ used)                                    │ │CWD → $HOME         │ If CWD is nonexistent and                │ │                    │ --preserve-environment is used           │ │CWD → passwd pw_dir │ If CWD is nonexistent (or                │ │                    │ --preserve-environment is used and no    │ │                    │ $HOME exists)                            │ │CWD → /             │ None of the above exist                  │ │FAIL                │ If / is nonexistent                      │ └────────────────────┴──────────────────────────────────────────┘ Command ┌────────────────┬──────────────────────────────────────────┐ │Transition      │                                          │ │(Host → Chroot) │ Comment                                  │ ├────────────────┼──────────────────────────────────────────┤ │CWD → CWD       │ Normal behaviour (if --directory is not  │ │                │ used)                                    │ │FAIL            │ If CWD is nonexistent                    │ └────────────────┴──────────────────────────────────────────┘ No fallbacks should exist under any circumstances.
--directory used ┌────────────────┬──────────────────────────────────────────┐ │Transition      │                                          │ │(Host → Chroot) │ Comment                                  │ ├────────────────┼──────────────────────────────────────────┤ │CWD → DIR       │ Normal behaviour                         │ │FAIL            │ If DIR is nonexistent                    │ └────────────────┴──────────────────────────────────────────┘ No fallbacks should exist under any circumstances.
Debugging Note that --debug=notice will show the internal fallback list computed for the session.
List available chroots % schroot -l↵ chroot:default chroot:etch chroot:sid chroot:testing chroot:unstable
Get information about a chroot % schroot -i -c sid↵ ——— Chroot ——— Name                   sid Description            Debian sid (unstable) Type                   plain Priority               3 Users                  rleigh Groups                 sbuild Root Users Root Groups            sbuild Aliases                unstable unstable-sbuild unstable-p owerpc-sbuild Environment Filter     ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|I\ FS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMA\ IN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TE\ RMPATH)$ Run Setup Scripts      true Script Configuration   script-defaults Session Managed        true Personality            linux32 Location               /srv/chroot/sid
Use --all or -c multiple times to use all or multiple chroots, respectively.
Running commands in a chroot % schroot -c sid /bin/ls↵ [sid chroot] Running command: “/bin/ls” CVS          sbuild-chroot.c   sbuild-session.h  schroot.conf.5 Makefile     sbuild-chroot.h   schroot.1         schroot.conf.5.in Makefile.am  sbuild-config.c   schroot.1.in Makefile.in  sbuild-config.h   schroot.c pam          sbuild-session.c  schroot.conf % schroot -c sid -- ls -1 | head -n 5↵ [sid chroot] Running command: “ls -1” ABOUT-NLS AUTHORS COPYING ChangeLog INSTALL
Use -- to allow options beginning with ‘-’ or ‘--’ in the command to run in the chroot.  This prevents them being interpreted as options for schroot itself.  Note that the top line was echoed to standard error, and the remaining lines to standard output.  This is intentional, so that program output from commands run in the chroot may be piped and redirected as required; the data will be the same as if the command was run directly on the host system.
Switching users % schroot -c sid -u root↵ Password: [sid chroot] (rleigh→root) Running login shell: “/bin/bash” #
If the user ‘rleigh’ was in root-users in /etc/schroot/schroot.conf, or one of the groups he belonged to was in root-groups, they would be granted root access without authentication, but the PAM authorisation step is still applied.
Sessions A chroot may be needed to run more than one command.  In particular, where the chroot is created on the fly from an LVM LV or a file on disc, there is a need to make the chroot persistent while a given task (or set of tasks) is performed.  Sessions exist for this purpose.  For simple chroot types such as ‘plain’ and ‘directory’, sessions may be created but are not strictly necessary.
Let's start by looking at a session-capable chroot:
% schroot -i -c sid-snap↵ ——— Chroot ——— Name                   sid-snap Description            Debian sid snapshot Type                   lvm-snapshot Priority               3 Users                  maks rleigh Groups                 sbuild Root Users Root Groups            root sbuild Aliases Environment Filter     ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|I\ FS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMA\ IN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TE\ RMPATH)$ Run Setup Scripts      true Script Configuration   script-defaults Session Managed        true Personality            linux Device                 /dev/hda_vg/sid_chroot Mount Options          -o atime,async,user_xattr Source Users Source Groups          root rleigh Source Root Users Source Root Groups     root rleigh LVM Snapshot Options   --size 2G -c 128
Note that the Session Managed option is set to ‘true’.  This is a requirement in order to use session management, and is supported by most chroot types.  Next, we will create a new session:
% schroot -b -c sid-snap↵ sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f
The session ID of the newly-created session is returned on standard output.  It is common to store it like this:
% SESSION=$(schroot -b -c sid-snap)↵ % echo $SESSION↵ sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f
The session may be used just like any normal chroot.  This is what the session looks like:
% schroot -i -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f↵ ——— Session ——— Name                   sid-snap-46195b04-0893-49bf-beb8-0d\ 4ccc899f0f Description            Debian sid snapshot Type                   lvm-snapshot Priority               3 Users                  maks rleigh Groups                 sbuild Root Users Root Groups            root sbuild Aliases Environment Filter     ^(BASH_ENV|CDPATH|ENV|HOSTALIASES|I\ FS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMA\ IN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TE\ RMPATH)$ Run Setup Scripts      true Script Configuration   script-defaults Session Managed        true Personality            linux Mount Location         /var/lib/schroot/mount/sid-snap-461\ 95b04-0893-49bf-beb8-0d4ccc899f0f Path                   /var/lib/schroot/mount/sid-snap-461\ 95b04-0893-49bf-beb8-0d4ccc899f0f Mount Device           /dev/hda_vg/sid-snap-46195b04-0893-\ 49bf-beb8-0d4ccc899f0f Device                 /dev/hda_vg/sid_chroot Mount Options          -o atime,async,user_xattr Source Users Source Groups          root rleigh Source Root Users Source Root Groups     root rleigh LVM Snapshot Device    /dev/hda_vg/sid-snap-46195b04-0893-\ 49bf-beb8-0d4ccc899f0f LVM Snapshot Options   --size 2G -c 128
Now the session has been created, commands may be run in it:
% schroot -r -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f -- \ uname -sr↵ I: [sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f chroot] Running \ command: “uname -sr” Linux 2.6.18-3-powerpc % schroot -r -c $SESSION -- uname -sr↵ I: [sid-snap-fe170af9-d9be-4800-b1bd-de275858b938 chroot] Running \ command: “uname -sr” Linux 2.6.18-3-powerpc
When all the commands to run in the session have been performed, the session may be ended:
% schroot -e -c sid-snap-46195b04-0893-49bf-beb8-0d4ccc899f0f↵ % schroot -e -c $SESSION↵
Finally, the session names can be long and unwieldy.  A name may be specified instead of using the automatically generated session ID:
% schroot -b -c sid-snap -n my-session-name↵ my-session-name
If something is not working, and it's not clear from the error messages what is wrong, try using the --debug=level option to turn on debugging messages.  This gives a great deal more information.  Valid debug levels are ‘none’, and ‘notice’, ‘info’, ‘warning’ and ‘critical’ in order of increasing severity.  The lower the severity level, the more output.
If you are still having trouble, the developers may be contacted on the mailing list: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
On the mips and mipsel architectures, Linux kernels up to and including at least version 2.6.17 have broken personality(2) support, which results in a failure to set the personality.  This will be seen as an “Operation not permitted” (EPERM) error.  To work around this problem, set personality to ‘undefined’, or upgrade to a more recent kernel.
By default, the environment is not preserved, and the following environment variables are defined: HOME, LOGNAME, PATH, SHELL, TERM (preserved if already defined), and USER.  The environment variables SCHROOT_COMMAND, SCHROOT_USER, SCHROOT_GROUP, SCHROOT_UID and SCHROOT_GID are set inside the chroot specifying the command being run, the user name, group name, user ID and group ID, respectively.  Additionally, the environment variables SCHROOT_SESSION_ID, SCHROOT_CHROOT_NAME and SCHROOT_ALIAS_NAME specify the session ID, the original chroot name prior to session creation, and the alias used to originally identify the selected chroot, respectively.
The following, potentially dangerous, environment variables are removed for safety by default: BASH_ENV, CDPATH, ENV, HOSTALIASES, IFS, KRB5_CONFIG, KRBCONFDIR, KRBTKFILE, KRB_CONF, LD_.*, LOCALDOMAIN, NLSPATH, PATH_LOCALE, RES_OPTIONS, TERMINFO, TERMINFO_DIRS, and TERMPATH. If desired, the environment-filter configuration key will allow the exclusion list to the modified; see schroot.conf(5) for further details.
Configuration files /etc/schroot/schroot.conf The system-wide chroot definition file.  This file must be owned by the root user, and not be writable by other.
/etc/schroot/chroot.d Additional chroot definitions may be placed in files under this directory.  They are treated in exactly that same manner as /etc/schroot/schroot.conf.  Each file may contain one or more chroot definitions.  Note that the files in this directory follow the same naming rules as run-parts(8) when run with the --lsbsysinit option.
/etc/schroot/setup.d The system-wide chroot setup script directories.  See schroot- setup(5).
/etc/pam.d/schroot PAM configuration.
System directories /usr/lib/schroot Directory containing helper programs used by setup scripts.
Session directories Each directory contains a directory or file with the name of each session.  Not all chroot types make use of all the following directories.
/var/lib/schroot/session Directory containing the session configuration for each active session.
/var/run/schroot/mount Directory used to mount the filesystems used by each active session.
/var/lib/schroot/union/underlay Directory used for filesystem union source (underlay).
/var/lib/schroot/union/overlay Directory used for filesystem union writeable overlay.
/var/lib/schroot/unpack Directory used for unpacking file chroots.
Roger Leigh.
Copyright © 2005-2012  Roger Leigh <rleigh@debian.org>
schroot is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
dchroot(1), sbuild(1), chroot(2), run-parts(8), schroot-setup(5), schroot-faq(7), schroot.conf(5).
SCCMAP(1)                    General Commands Manual                   SCCMAP(1)
sccmap - extract strongly connected components of directed graphs
sccmap [-dsv] [ -ooutfile ] [ files ]
sccmap decomposes digraphs into strongly connected components and an auxiliary map of the relationship between components.  In this map, each component is collapsed into a node.  The resulting graphs are printed to standard out.  The number of nodes, edges and strongly connected components are printed to standard error.  sccmap is a way of partitioning large graphs into more manageable pieces.
-d     Preserve degenerate components of only one node.
-s     Do not print the resulting graphs. Only the statistics are important.
-S     Just print the resulting graphs. No statistics are printed.
-ooutput Prints output to the file output. If not given, sccmap uses stdout.
-v     Generate additional statistics. In particular, sccmap prints the number of nodes, edges, connected components, and strongly connected components, followed by the fraction of nodes in a non- trivial strongly connected components, the maximum degree of the graph, and fraction of non-tree edges in the graph.
sccmap emits a warning if it encounters an undirected graph, and ignores it.
TEXDOC(1)                         User Commands                        TEXDOC(1)
texdoc - find & view documentation in TeX Live
texdoc [OPTION]... NAME... texdoc ACTION
Try to find appropriate TeX documentation for the specified NAME(s). Alternatively, perform the given ACTION and exit.
Actions: -h, --help Print this help message.
-V, --version Print the version number.
-f, --files Print the list of configuration files used.
--just-view file Display file, given with full path (no searching).
-w, --view Use view mode: start a viewer. (default)
-m, --mixed Use mixed mode (view or list).
-l, --list Use list mode: show a list of results.
-s, --showall Use showall mode: show also "bad" results.
-i, --interact Use interactive menus. (default)
-I, --nointeract Use plain lists, no interaction required.
-M, --machine Machine-readable output for lists (implies -I).
-q, --quiet Suppress warnings and most error messages.
-v, --verbose Print additional information (eg, viewer command).
-d, --debug[=list] Activate debug output (restricted to list).
PAGER, BROWSER, PDFVIEWER, PSVIEWER, DVIVIEWER.
<texmf>/texdoc/texdoc.cnf, see output of the --files option.
Report bugs to <texdoc@tug.org>. Texdoc home page: <http://tug.org/texdoc/> Source: <https://github.com/mpg/texdoc>
Copyright Â© 2008-2011 Manuel P'egouri'e-Gonnard.  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it.