TITO.PROPS(5)

💖 TITO.PROPS 💖

okay bestie, gather round — this is tito.props from the Tito User Manual, section 5, and it's literally the vibes file that tells tito(5) how to build your package. no cap.

---

🌸 NAME 🌸

tito.props — the directives that tell tito(5) how to build the package. 💅

✨ SYNOPSIS ✨

None 🫶

(no args, no flags, it's just a file, it's giving "i don't need a synopsis, i AM the synopsis")

🦋 DESCRIPTION 🦋

Project settings can live in these files:

• GITROOT/.tito/tito.props
• GITROOT/SOME/PACKAGE/tito.props

The global .tito/tito.props is generally where the settings get defined, periodt. But for some multi-project git repositories, individual packages can override those settings by dropping a tito.props in the project directory — i.e. the same location as its .spec file. iconic behaviour honestly.

🎀 SECTIONS 🎀

tito.props can contain several sections, and we're going through every single one:

💜 BUILDCONFIG 💜

This section and a couple of its properties are required. You can use the following variables:

• builder — the fully qualified Builder class implementation to use. You can either specify builders shipped with tito(5) (see the BUILDERS section below 👇) or a custom builder that lives in the directory your lib_dir option points to. This property is required.
• tagger — the fully qualified Tagger class implementation to use. Same deal: either taggers shipped with tito(5) (see TAGGERS below 👇) or a custom tagger sitting in the directory your lib_dir option points to. This property is required.
• lib_dir — optional property defining a directory to be added to the Python path when executing tito. It's how you stash custom implementations of Builder, Tagger, and Releaser. 🗂️
• changelog_format — controls the formatting of entries when generating changelog entries. The default value is "%s (%ae)". See PRETTY FORMATS in git-log(1) for more info.
• changelog_with_email — if set to 0, then entries in the changelog (the subject of commits) are not followed by the email of the committer. Default is 1. This option is deprecated and provided for backwards-compatibility only. New configurations should consider changelog_format instead.
• changelog_do_not_remove_cherrypick — if set to 0, it will not remove from cherry picked commits the part "(cherry picked from commit ...)".
• changelog_date_with_time — by default, changelog dates don't contain time (e.g. Wed Nov 1 2017). When this option is set to True, changelog entries are generated in a datetime format (e.g. Wed Nov 1 11:08:13 EDT 2017). This feature requires RPM 4.14, therefore it is supported only on Fedora 27, EPEL8, openSUSE Leap 15 and higher. 💀 don't say we didn't warn you.
• tag_suffix — an optional specification of a suffix to append to all tags created by tito for this repo. Super useful when one git repo is inheriting from another, but tags are created in both — the suffix is your little indicator of which repo the tag originated in. (i.e. tag_suffix = -mysuffix) 🏷️
• tag_commit_message_format — controls the text of the git commit message that gets used when a new tag is generated. You can use the "%(name)s", "%(release_type)s" and "%(version)s" placeholders.
• tag_format — controls the format used in VersionTagger. If not specified other taggers.
• sign_tag — this boolean enables GnuPG signed tags using git tag -s. 🔐
• fetch_sources — if true, download sources from predefined Source<N> addresses to the SOURCE folder.
• test_version_suffix — append a given suffix (a string, e.g. .post) to the Version: tag in the generated spec file when building with --test. This ensures that any --test NEVRA is higher than the NEVRA of the previous release. Simply modifying the Release: tag doesn't guarantee this, since downstream Release: numbers are often incremented, which would take precedence (e.g., foo-1.0-1.git.3.60fe05a < foo-1.0-2). math is math, bestie. 🧮

☁️ KOJI AND COPR ☁️

• disttag — dist tag variable, which is passed to rpmbuild for packages built in this tag.
• blacklist — space separated list of packages which should not be built in this tag.
• whitelist — if whitelist is present, only packages listed here can be built in this tag. This also overrides blacklist. 👑
• scl — specify the name of the Software Collection into which the package should be built.

📝 VERSION_TEMPLATE 📝

Allows the user to write out a template file containing version and/or release, and add it to git during the tagging process. so crafty, love that.

• template_file — path to a file conforming to a Python string.Template, as described at http://docs.python.org/2/library/string.html#template-strings. The path is relative to the root of the entire git checkout, since this is likely to be stored in the top level .tito directory. The variables $version and $release are available inside the template. ✨
• destination_file — specifies a file to write, relative to the directory for the package being tagged.

Example:

[version_template]
destination_file = version.txt
template_file = .tito/templates/version.rb

🚨 REQUIREMENTS 🚨

• tito — if tito is older than the specified version, it will refuse to continue. no old tito allowed, sorry babes.

🏷️ TAGCONFIG 🏷️

• require_package — comma separated list of packages which need to be installed prior to tagging. If those packages are not installed, tito will refuse to continue. vibe check failed = no tag for you.

🛠️ BUILDERS 🛠️

• tito.builder.Builder — the basic package builder. It creates a tar.gz of the whole directory and creates the src.rpm, then builds the rpm using some supported method.
• tito.builder.MockBuilder — use mock instead of rpmbuild for building an RPM package. See doc/builders.md.
• tito.builder.NoTgzBuilder — builder for packages that do not require the creation of a tarball. Usually these packages have source files checked directly into git. 📂
• tito.builder.UpstreamBuilder — builder for packages that are based off an upstream git tag. Commits applied in the downstream git become patches applied to the upstream tarball. For example — you are building package foo-1.2-3... The Tar.gz file is created from the commit which is tagged by foo-1.2-1, and the diff between release 1 and 3 is put in the spec file as Patch0.
• tito.builder.GemBuilder — builder for packages that list a .gem as Source0, where the .gemspec shares a directory hierarchy with the .spec file and the upstream does not want to check .gem files into their git repository. 💎
• tito.distributionbuilder.DistributionBuilder — behaves similarly to tito.builder.UpstreamBuilder, but a patch is created for every release. Therefore the package from the previous example will end up with a tar.gz file created from tag foo-1.2-1 and with Patch0: foo-1.2-1-to-foo-1.2-2.patch Patch1: foo-1.2-1-to-foo-1.2-3.patch.
• tito.builder.FetchBuilder — see doc/builders.mkd.

[builder]
fetch_strategy = tito.builder.fetch.ArgSourceStrategy

ArgSourceStrategy here could be replaced with a custom strategy if you were to have one in your lib_dir. 🫶

• tito.builder.GitAnnexBuilder — see doc/builders.mkd.

Builder for packages with existing tarballs checked in using git-annex, e.g. referencing an external source (web remote). This builder will "unlock" the source files to get the real contents, include them in the SRPM, then restore the automatic git-annex symlinks on completion. 🔓

🏷️ TAGGERS 🏷️

All taggers which inherit from tito.tagger.VersionTagger (all of them to this date), will update the file GITROOT/.tito/packages/name-of-package and put there one line which consists of the version-release of the package, a space delimiter, and the path to the package directory relative to GITROOT. slay, one line, so tidy.

• tito.tagger.VersionTagger — the standard tagger class, used for tagging packages built from source in git. Release will be tagged by incrementing the package version, and the actual "Release" will always be set to 1.
• tito.tagger.ReleaseTagger — keep version and increment release.
• tito.zstreamtagger.zStreamTagger — it is used for EUS packages.
• tito.rheltagger.RHELTagger — tagger which is based on ReleaseTagger and uses the Red Hat Enterprise Linux changelog format:
  • Resolves: #1111 - description
  • Related: #1111 - description

🚀 RELEASER 🚀

You can create a section with the same name as the releaser target, and in there you can specify this option:

• remote_git_name — this is useful for FedoraGitReleaser and DistGitReleaser and will allow you to specify the name of the remote dist-git branch.

For example, let's say you have in releaser.conf: [git-sat] releaser = tito.release.DistGitReleaser branches = satellite-6.0-rhel-6

and then you can add remote_git_name: [git-sat] releaser = tito.release.DistGitReleaser branches = satellite-6.0-rhel-6 remote_git_name = ruby193-rubygem-simple-navigation

And it will push the package into ruby193-rubygem-simple-navigation dist-git despite the fact that it is in the /rubygem-simple-navigation directory. And the project name (as taken from the spec file) is rubygem-simple-navigation. the way that it just… goes where you tell it 😭✨

• tito.susetagger.SUSETagger — tagger which is based on VersionTagger and deals with SUSE / OBS specific separate changes file and format.

🌈 EXAMPLE 🌈

[buildconfig]
builder = tito.builder.Builder
tagger = tito.tagger.VersionTagger

[koji]
autobuild_tags = dist-5E-sw-1.2-candidate dist-f12-sw-1.2-candidate dist-f13-sw-1.2-candidate

[dist-5E-sw-1.2-candidate]
disttag = .el5

[dist-f12-sw-1.2-candidate]
disttag = .fc12
blacklist=jabberd-selinux

[dist-f13-sw-1.2-candidate]
disttag = .fc13
blacklist=jabberd-selinux

[requirements]
tito=0.3.0

👀 SEE ALSO 👀

tito(8) titorc(5)

👑 AUTHORS 👑

• Devan Goodwin <dgoodwin@rm-rf.ca>
• James Bowes <jbowes@repl.ca>
• Jan Pazdziora
• Jesus M Rodriguez <jesusr@redhat.com>
• Pall Sigurdsson <palli@opensource.is>
• Miroslav Suchý <msuchy@redhat.com>

and: Adam Miller, Alex Wood, Aron Parsons, Brenton Leanhardt, Ivan Nečas, John Eckersberg, Kenny MacDermid, Lukáš Zapletal, Luke Meyer, Marian Csontos, Martin Bačovský, Michael Stead, Mike McCune, mscherer, Paul Morgan, Sean P. Kane, Steve Ashcrow Milner

---

that's the whole page bestie, every single option accounted for, no crumbs left. 💖

okay and finally, the receipts: this came from the tito manual, dated 08/26/2026, and the section number is 5, so if anyone asks — TITO.PROPS(5), that's the one. mwah. 🎀🦋✨