# This is a sample bracket configuration file.  Edit to suit your
# purpose and environment.

# This file should consist only of name="string" pairs and comments,
# such that it can be parsed both as a valid shell script and by the
# Python configuration parser.  Note in particular that numeric
# parameters are specified as strings enclosed in double quotes.
# The dollar sign can be used to expand a previously defined value.

# The version control system in use.  Currently only "cvs" is
# fully supported, "hg" and/or "git" may be supported in the future.
vc="cvs"

# The NetBSD port to test.  This also appears in various pathnames
# below; use global search-and-replace to change.
arch="sparc"

# The build variant.  If you are running multiple bracket instances
# for the same port, for example with different build options or a
# different compiler, then set this to something like "lockdebug" or
# "gcc45" to distinguish this instance from the others.  You can also
# add a sentence or two describing the configuration to
# variant_description_html; it will be added to WWW reports.
#variant=""
#variant_description_html=""

# Directories that can be shared between ports

# Common top-level directory.  This is only used in expansions
# in this file, so if you don't use $top anywhere below, you don't
# need to set it.
top="/bracket"

repo_root="$top/repo"
db_dir="$top/db"

# Directory where builds are done.
# Put this on a ramdisk if you have one of at least 32 gigabytes.
# If not, put it on an SSD.
build_root="/bracket/build"

# The target argument passed to build.sh.  Adding "live-image"
# here works only for source date 2012.01.22.03.53.33 or newer,
# as that is when support for it was added to build.sh.
build_target="release iso-image"

# Directories specific to this port.  release_root can be shared
# between variants that are built identically but tested differently,
# but in a rather limited way: existing builds will be reused by the
# other variant, but build logs will only be saved for the variant
# where the build was performed, and there is no automatic way to
# ensure that each variant is configured to build indentically.
arch_root="$top/$arch"
release_root="$top/$arch/release"
test_root="$top/$arch/test"
results_root="$top/$arch/results"
precommit_root="$top/$arch/precommit"
#archive_root="$top/i386/archive"
logdir="$top/$arch/log"
htmldir="$top/$arch/html"

# Paths to programs
rsync="rsync"
cvs="cvs"

# When "1", mirror the repository at the beginning of notify.py;
# when "0", do not.  The latter is useful when building multiple
# ports, as it is usually sufficient to mirror the repository in
# the notify cron job for one of the ports, and the rest can
# piggy-back off of it.
update_repo="1"

# When "1", retry failing repository rsyncs to work around
# the issue of systems ticket
# "[NetBSD.org #160795] rsync from anoncvs fails repeatedly"
#update_repo_retry="1"

# Repository modules to mirror and check out.  Default is "src".
#repo_modules="src,xsrc"

# Safety margin to allow for skew in the cvs-to-anoncvs mirroring,
# in seconds.  We only test versions at least this many seconds
# older than the start of the rsync, as newer ones may be incomplete.
rsync_margin="1200"

# Number of parallel make jobs.  Default is the number of CPUs.
#njobs="1"

# CFLAGS to pass to the host C compiler
# On Linux, use host_cppflags="-D_BSD_SOURCE=1 -D_POSIX_C_SOURCE=200112"
host_cppflags=""

# Flags to pass on the build.sh command line, e.g., "-V TMPDIR=/tmp"
build_sh_flags=""

# If set to "1", build with debug symbols, and also use the
# -fdebug-prefix-map compiler option to embed /usr/src as the
# source path in debug information regardless of the source
# location on the build host.
debug_build="0"

# Extra arguments to pass to qemu or other VMM.
# On NetBSD, if you have NVMM set up and want to use it
# to accelerate an i386 or amd64 guest, use "-accel nvmm".
# Similarly, on Linux, you can use "-accel kvm".
# The deprecated form extra_qemu_args is still accepted.
extra_vmm_args=""

# Extra arguments to pass to anita (e.g., "--disk-size 1280M")
extra_anita_args=""

# The maximum number of concurrent builds.
build_slots="1"

# Maximum number of release directories to keep around.
keep_release_dirs="4"

# Maximum number of test directories to keep around.  If you
# run frequent builds, the background test runs of multiple
# older builds may still be running when a new one is started,
# and this needs to be large enough to accommodate that.  It
# may also be useful to increase this in case you want to
# manually analyze or otherwise use the results of builds
# older than the most recent few, and can afford the disk space.
keep_test_dirs="4"

# As above, but for build directories.  This does not include the
# directory or directories actively being built in (whose number is
# determined by the build_slots setting), only additional ones that
# can be used for CVS checkout in preparation for a build, or to
# allow debugging the content after a build even after a new build
# has been started.  If your build directories are on a ramdisk,
# zero is a good choice.
keep_build_dirs="0"

# The first year and month to include in HTML reports.
report_from_year="2023"
report_from_month="1"

# The oldest source date the "bracket refine" command should consider
# for building.  This is useful for avoiding trying to build versions
# that are so old that they no longer build on a modern build host.
#build_from="2017.01.01.00.00.00"

# How often the tests are run, for display on the main web page
#update_frequency="roughly eight times a day"

# HTML code added at the end of the build status page
footer=""

# If the machine running the tests is not itself the web server, define
# this to copy the files over to the web server and make sure ssh is set
# up to authenticate without user interaction
#webserver_rsync_target="user@webserver:/some-remote-directory/$arch/"

# If you need to pass the --rsh aka -e option to rsync, specify its
# value here
#webserver_rsync_rsh=""

# URL base that the reports are published under on the web server.
# Used in the notification emails.
#url_base="http://www.domain.com/netbsd-stuff/bracket-reports/$arch/"

# Email build failure notification From: address
# If unset, no notifications will be sent.
#notify_from="Example Arch Build Failures <example-arch-autobuild@domain.example>"

# Email notification header To: addresses.  The special
# value "committers" means send to everyone who committed changes
# between the last good build and the first failed one.
#notify_build_to="mailinglist@domain.example"
#notify_install_to="mailinglist@domain.example"
#notify_test_completion_to="mailinglist@domain.example"
#notify_test_to="mailinglist@domain.example"

# Email build failure notification envelope To: address.  If you want to
# manually review or moderate the email notifications, set this to the
# email address of the moderator.  If not set, the envelope To: address
# will be the same as the header To: address.
#notify_build_envelope_to="moderator@domain.example"
#notify_install_envelope_to="mailinglist@domain.example"
#notify_test_completion_envelope_to="mailinglist@domain.example"
#notify_test_envelope_to="mailinglist@domain.example"

#
# Contents of notification email Reply-To: header (optional).
#notify_reply_to="<discussion-list@domain.example>"

# Take hints from another bracket installation that may already
# have bisected failures before us.  For example, if you are running
# another bracket installation on the same machine publishing
# results in /bracket/i386/html/, you can use
#
#hints_file="$top/i386/html/events.dat"
#
# or to reproduce the results from babylon5.netbsd.org, put this in
# in your crontab:
#
#   55 7,19 * * * cd $top/db && ftp -4 http://releng.netbsd.org/b5reports/i386/events.dat
#
# and use
#
#hints_file="$top/db/events.dat"

# Background jobs for the priority scheduler (schedule.py)
# This is a comma-separated list of directory:script pairs;
# whenever there is spare time, the listed scripts are run
# in round-robin order.
#background_jobs=".:refine,../i386-debug:notify,../i386-debug:refine,../amd64:notify,../amd64:refine"

# Whether or not to report changes in the test/fail status of
# individual tests in the montly details list.  The default is "0"
# as this is rather slow.
#report_test_changes="1"
# Set this to "0" if the guest is unable to export the ATF XML output files;
# then the reports of test changes will be based on the console output instead
#have_atf_xml="1"

# For test runs that failed to complete, try to determine why by grepping
# the console output for a panic message and include it in the HTML report
# if found.
#report_noncompletion_reason="1"

# When "1", respect the user's dark color scheme preference.  This is
# the default.  When "0", always use a dark-on-light scheme.
#dark_mode_auto="1"
