Subversion Repositories configs

# This configuration file specifies which programs should be run
# when the specified event occurs in problem directory lifetime.
#
# It consists of directives and rules.
#
# Directives start with a reserved word. Currently, there is only one
# directive, "include". Its format is "include FILE".
# It causes files which match FILE to be read and
# parsed as if they are inserted textually where this directive
# occurs. FILE can use shell pattern metacharacters (*,?,etc) to
# specify multiple files. Relative paths are interpreted relative
# to current file.
#
# Rule starts with a line with non-space leading character.
# All subsequent lines which start with space or tab form one rule.
#
# EVENT=post-create
#
#         cp /etc/example.conf .
#         uptime > uptime
#         echo $HOSTNAME `uname -r`
#
# This example event will copy `/etc/example.conf` to newly created
# problem directory, store current uptime in `uptime` file
# and prints current hostname and uname to logs.
#
# Rules may be commented out with #. One # is sufficient to comment out
# even a multi-line rule (no need to comment out every line).
#
# Rules specify which programs to run on the problem directory.
# Each rule may have conditions to be checked before the program is run.
#
# Conditions have form VAR[!]=VAL or VAL~=REGEX, where VAR is either
# word "EVENT" or a name of problem directory element to be checked
# (for example, "executable", "package", hostname" etc).
#
# If all conditions match, the remaining part of the rule
# (the "program" part) is run in the shell.
# All shell language constructs are valid.
# All stdout and stderr output is captured and passed to abrt
# and possibly to abrt's frontends and shown to the user.
#
# If the program terminates with nonzero exit code,
# the event processing is considered unsuccessful and is stopped.
# Last captured output line, if any, is considered to be
# the error message indicating the reason of the failure,
# and may be used by abrt as such.
#
# If the program terminates successfully, next rule is read
# and processed. This process is repeated until the end of this file.


# Determine in which package/component the crash happened (if not yet done):
EVENT=post-create container_cmdline= remote!=1 component=
        abrt-action-save-package-data

# Store information about the container:
EVENT=post-create container_cmdline!= remote!=1
      /usr/libexec/abrt-action-save-container-data || :


# Example: if you want all users (not just root) to be able to see some problems:
#EVENT=post-create
        rm uid; chmod a+rX .

EVENT=post-create remote!=1
        # uid file is missing for problems visible to all users
        # (oops scanner is often set up to not create it).
        # Record username only if uid element is present:
        if [ -f uid ]; then getent passwd "`cat uid`" | cut -d: -f1 >username; fi
        # Save cpuinfo because crashes in some components are
        # related to HW acceleration. The file must be captured for all crashes
        # because of the library vs. executable problem.
        if command -v lscpu >/dev/null 2>&1; then
            # use lscpu if installed
            lscpu > $DUMP_DIR/cpuinfo
        else
            cp /proc/cpuinfo $DUMP_DIR/cpuinfo
        fi

# Record runlevel (if not yet done) and don't return non-0 if it fails:
EVENT=post-create runlevel= remote!=1
        runlevel >runlevel 2>&1
        exit 0

# A dummy EVENT=post-create for uploaded problems.
# abrtd would delete uploaded problems without this EVENT.
EVENT=post-create remote=1
        echo "Processing uploaded problem : $DUMP_DIR"

# Example:
# if you want to upload data immediately at the moment of a crash to
# a remote directory:
# (this example shows how to upload the crash data on
#  a ABRT centralized crash collection client; man abrt-upload-watch)
#
# CAUTION:
#   The event 'notify' is used because it will ensure that the uploaded problem
#   data will contain results of all post-create events.
#
#   The event 'notify' might not get executed if any of the post-create events
#   decide that the problem should be ignored by ABRT (e.g. unpackaged program,
#   unsigned package, ...).
#
#   For duplicate problems, abrtd executes the event 'notify-dup'. If you want
#   to upload also duplicate occurrences of a single problem, copy the lines
#   below and change "EVENT=notify" to "EVENT=notify-dup".
#
#EVENT=notify
        reporter-upload -u scp://user:password@server.name/var/spool/abrt-upload/ || :

# Example:
# if you want to upload data immediately at the moment of a crash to
# a remote file
#
# CAUTION:
#   The event 'notify' is used because it will ensure that the uploaded problem
#   data will contain results for all post-create events.
#
#   The event 'notify' might not get executed if any of the post-create events
#   decide that the problem should be ignored by ABRT (e.g. unpackaged program,
#   unsigned package, ...).
#
#   For duplicate problems, abrtd executes the event 'notify-dup'. If you want
#   to upload also duplicate occurrences of a single problem, copy the lines
#   below and change "EVENT=notify" to "EVENT=notify-dup".
#
#EVENT=notify
        reporter-upload -u scp://user:password@server.name/tmp/crash.tar.gz || :


#open-gui event is used by abrt-gui's "Edit"->"Open problem data"

EVENT=open-gui
        report-gtk -x -- "$DUMP_DIR"

# Notify a new crash
EVENT=notify
        abrt-action-notify -d $DUMP_DIR
        true # ignore failures because we want to run all 'notify' events

# Notify a new occurrence of a single crash
EVENT=notify-dup
        abrt-action-notify -d $DUMP_DIR
        true # ignore failures because we want to run all 'notify' events