RELEASERS.CONF(5)

🎀 RELEASERS.CONF 🎀

okay bestie, welcome to releasers.conf — this is part of the Tito user manual, and it's literally the glow-up guide for where your builds go when they grow up. 💖

---

✨ NAME ✨

releasers.conf — the config file where you define all your release targets, aka the places your builds get published. it's giving "destination board at the airport" but for rpms. 🛫

---

🌸 SYNOPSIS 🌸

None

not me having zero synopsis 😭 there's literally nothing to put here. iconic of it honestly.

---

💅 DESCRIPTION 💅

Tito lets projects define their own release targets — and those targets can spell out the exact releaser implementation you want to use (yes, even a custom one you wrote yourself, main character behavior 🫶), plus any arguments that implementation needs for a specific type of build.

---

🦋 RELEASERS 🦋

Tito ships with several releaser implementations you can drop straight into releasers.conf. And if you're feeling extra ✨, you can define a lib_dir in your tito.props globalconfig section and park your own custom releaser implementation there. build your own, bestie, we love to see it.

If you set builder.test = 1 in your releasers.conf target, that's how you turn on --test builds. (heads up: this uses the latest git HEAD rather than the latest tagged package 🏷️) this is lowkey perfect for automating the publishing of a nightly build — the kind of thing you'd rather not have to keep tagging over and over like a clown. 🙈

👑 tito.release.YumRepoReleaser

The releaser that will build your packages, rsync down an existing yum repository, place your packages inside it, regenerate the yum repodata, and then rsync the yum repository back up. full circle moment. 🔁

• It requires the srpm_disttag = .fc21 to specify the disttag on the resulting source RPM. This lets a correct srpm get uploaded, and prevents problems with it getting clobbered when building for "newer" disttags. 💀 (no one wants a clobbered srpm, fr fr)
• Specify filetypes = srpm if you want to build a source rpm instead of a regular rpm.
• Specify createrepo_command = createrepo_c -s sha1 if you are building on a recent distro and are working with yum repositories for rhel5.
• You can use the environment variable RSYNC_USERNAME to override the rsync username.

---

🌈 tito.release.RsyncReleaser

The releaser that will build your packages and rsync up to a remote repository. sending it straight to the cloud, periodt. ☁️

• Specify filetypes = rpm srpm tgz to choose what type of packages will be uploaded.
• You can use the environment variable RSYNC_USERNAME to override the rsync username.
• Specify scl = COLLECTION to build into a Software Collection.

Deprecated — prefer builder.scl = COLLECTION instead. bestie it's giving "old news", move on 💅

• The variable rsync_args can specify additional arguments passed to rsync. Default is -rlvz.

---

🎀 tito.release.FedoraGitReleaser

This one will checkout your project in Fedora git using fedpkg. Sources are then synced to the first branch your releaser lists. After that, tito will git merge the first branch into all the other listed branches, triggering builds in each one. cascade queen. 👑

The branches property can contain aliases such as fedora-all, fedora-stable, fedora-latest, epel-all, etc. For the complete list of aliases and their explanations, see https://github.com/rpm-software-management/fedora-distro-aliases.

The required_bz_flags property can be specified to have tito check Red Hat Bugzilla to see if each bug number extracted from the changelog has the appropriate flags. If it does not, it will be skipped in the commit message. If no bugs are found with the required tags, a placeholder_bz can be specified (see below), otherwise the release will abort. 😭

The placeholder_bz property can be specified to use if no bugs were found in the changelog with the required flags.

[fedora-git]
releaser = tito.release.FedoraGitReleaser
branches = fedora-all epel7 epel8 epel9
required_bz_flags = myos-1.1.0+ pm_ack+
placeholder_bz = 100000

---

💜 tito.release.CentosGitReleaser

This releaser will checkout your fork in the project in the Centos Stream git using centpkg. A new branch off your fork is then created for the changes. This is produced in the same way as the FedoraGitReleaser, with a .tar file that is loaded to the lookaside. The branch gets pushed to the forked repo and tito is done. The process then requires the manual creation of a merge request against the main repo of the release, which is done in the web UI. so close, yet so manual. 🫠

The required_bz_flags property can be specified to have tito check Red Hat Bugzilla to see if each bug number extracted from the changelog has appropriate flags. If it does not, it will be skipped in the commit message. If no bugs are found with the required tags, a placeholder_bz can be specified (see below), otherwise the release will abort.

The placeholder_bz property can be specified to use if no bugs were found in the changelog with the required flags.

[centos-git]
releaser = tito.release.CentosGitReleaser
branches = c9s
required_bz_flags = release+
placeholder_bz = 100000

If you would like to build (ie - koji) against a different target than what is default for the FedoraGit/DistGit branch currently being worked on, it can be done like the following example. 🔥

Note The formatting of build_targets in the following example is git_branch:koji_build_target and the following custom build targets are just place holders for the example and aren't likely to exist in Fedora's koji. don't come for me, they're fake bestie. 🍓

[fedora-git-custom-target]
releaser = tito.release.FedoraGitReleaser
branches = master el6 f19
build_targets = master:custom-target el6:el6-custom-target f19:f19-custom-target

---

🌟 tito.release.DistGitReleaser

Same as FedoraGitReleaser, but use rhpkg instead of fedpkg. that's it, that's the whole vibe. 💫

---

🔥 tito.release.KojiReleaser

This releaser creates a src.rpm and submits it into Koji. It can submit more than one build at once — multitasking icon. 💅

Note This is targeted for private instances of Koji. You cannot submit regular builds into Fedora Koji using this releaser, because Fedora Koji does not allow builds from src.rpm — for building into Fedora see FedoraGitReleaser above. read the sign, bestie. 🚫

[koji]
releaser = tito.release.KojiReleaser
autobuild_tags = my-koji-tag-rhel6 my-koji-tag-fedora18

In this example, the releaser will create the src.rpm according to the definition of [my-koji-tag-rhel6] in tito.props. You usually want to set up there at least disttag. See the KOJI section in tito.props(5).

If the --scratch option or the SCRATCH environment variable is set, the package is built as scratch in Koji.

You can specify KOJI_OPTIONS in titorc(5) and it is passed to the koji command as an option. Usually you want to specify at least the --config option.

The variable autobuild_tags is required for KojiReleaser. no tag, no build, sorry angel. 🙈

---

⭐ tito.release.KojiGitReleaser

Build into Koji through dist-git. It behaves as KojiReleaser. The only difference is that the src.rpm is not passed to Koji. Instead it is sent to a koji git hash from which Koji should build the package. 💌

Note: This feature is not in upstream Koji (although it is submitted for a long time). it's been waiting in the queue like a text back. 😭

Please do not confuse this with FedoraGitReleaser. KojiGitReleaser is intended for private instances of Koji.

You need to specify git_url, which specifies the url of the git repository. This url needs to be reachable from Koji. 👀

---

🧚 tito.release.ObsReleaser

Build into Open Build Service using the osc command.

You must specify project_name in the config. You can optionally specify package_name, but if it is not present, the name of the package directory is used.

This releaser assumes that you have ~/.oscrc correctly configured. get your config together first, queen. 💖

---

🍓 tito.release.CoprReleaser

This releaser submits your src.rpm to Copr.

[my-copr]
releaser = tito.release.CoprReleaser
project_name = my-copr-project-name
upload_command = scp %(srpm)s my.web.com:public_html/my_srpm/
remote_location = http://my.web.com/~msuchy/my_srpm/
copr_options = --timeout 600

Variables are:

• project_name — this is the name of your project on Copr.
• upload_command — this command is executed to upload the src.rpm to the internet. It can be scp, rsync or just cp. It may contain the string "%(srpm)s" (even several times), which is substituted by the real srpm path. (optional)
• remote_location — how the location above can be accessed over www. (optional)
• copr_options — space separated options to pass directly to copr-cli build. Defaults to --nowait. (optional)

The releaser will publish your src.rpm to a remote server and then submit it into Copr via URL. If you would rather submit the package directly from your computer, just omit the upload_command and remote_location variables. choose your own adventure, bestie. 🌈

project_name behaves exactly as autobuild_tags in KojiReleaser, and you can define various options for each project name in tito.props (e.g. disttag, whitelist, blacklist, scl). For more information see the man page of tito.props.

Note: this releaser assumes you have copr-cli correctly configured. See the API KEY section in the copr-cli man page. 🔑

✨ EXAMPLE ✨

okay bestie, this is the part where it all comes together 🫶 like, real, copy-pasteable config blocks that show you how these releasers and builders actually vibe together in the wild. every single one of these is straight from the page, so peek at the one that matches your situation and go.

---

💖 yum repo, fedora-15-x86_64

the classic. release into a fedora-15-x86_64 yum repo:

; Release into fedora-15-x86_64 yum repo
[yum-f15-x86_64]
releaser = tito.release.YumRepoReleaser
srpm_disttag = .fc15
builder = tito.builder.MockBuilder
builder.mock = fedora-15-x86_64
rsync = fedorapeople.org:/srv/repos/dgoodwin/tito/fedora-15/x86_64/ fedorapeople.org:/srv/repos/dgoodwin/tito/fedora-15/x86_64/

see how rsync has two destinations in there? yeah. it can do that. slay.

---

🌸 el6 yum repository

and here's the el6 one, where the comment literally tells you to specify builder.test=1 so that we build on the latest commit instead of the latest tito tag (iykyk):

; Release into el6 yum repository. specify builder.test=1 so that
; we build on latest commit (instead of latest tito tag)
[yum-el6-x86_64]
releaser = tito.release.YumRepoReleaser
srpm_disttag = .el6
builder = tito.builder.MockBuilder
builder.mock = epel-6-x86_64
builder.test = 1
scl = ruby193
rsync = remoteserver.org:/srv/repos/el6/testing/x86_64

also scl = ruby193 is hanging out in there, just doing its thing 💅

---

🎀 uploading into a source repository

when you just want the source bits up on the server:

; Upload into source repository
[yum-fc15-sources]
releaser = tito.release.YumRepoReleaser
srpm_disttag = .fc15
builder = tito.builder.MockBuilder
builder.mock = fedora-15-x86_64
filetypes = srpm
rsync = remoteserver.org:/srv/repos/fedora-15/SRPMS

filetypes = srpm, so it's srpms only. minimal. focused. main character energy. ✨

---

🔥 el5 yum repository (overloading createrepo_command)

the el5 one, where the config overloads createrepo_command to make an el5-compatible repo:

; el5 yum repository. Overloading createrepo_command to make
; el5 compatible repo.
[yum-el5-i386]
releaser = tito.release.YumRepoReleaser
srpm_disttag = .el5
builder = tito.builder.MockBuilder
builder.mock = epel-5-i386
createrepo_command = createrepo_c -s sha1
rsync = remoteserver.org:/srv/repos/rhel5/i386

look at createrepo_c -s sha1 doing the absolute most for backwards compatibility. iconic honestly.

---

🦋 rsync a tgz with custom rsync args

this one rsyncs a tgz file to a remote site, and it brings its own rsync arguments along for the ride:

; rsync tgz file to remote site with custom rsync arguments
[rsync]
releaser = tito.release.RsyncReleaser
srpm_disttag = .fc15
builder = tito.builder.MockBuilder
builder.mock = fedora-15-x86_64
filetypes = tgz
rsync = remoteserver.org:/srv/tarballs/
rsync_args = -rlvzpt

filetypes = tgz + rsync_args = -rlvzpt. that's it. that's the whole vibe. 💜

---

🌈 releasing with OBS

releasing via OBS, which is so short and sweet compared to the others:

; Release using OBS
[obs-project]
releaser=tito.release.ObsReleaser
project_name=home:xsuchy

no builder, no rsync, nothing extra. just the releaser and a project_name. lowkey elegant.

---

👑 Copr: upload the src.rpm, then submit it by URL

okay so this one uploads the src.rpm to a remote server first, and then submits it into Copr via a URL:

; Upload src.rpm to remote server and then submit it into Copr via URL
[copr-project]
releaser = tito.release.CoprReleaser
project_name = my-copr-project-name another-project
upload_command = cp %(srpm)s /home/msuchy/public_html/my_srpm/
remote_location = http://my.web.com/~msuchy/my_srpm/

not me noticing project_name can hold two project names (my-copr-project-name another-project) 😭 and yes %(srpm)s is doing substitution magic inside upload_command. keep it exactly like that bestie, don't touch it.

---

🍓 Copr: straight from your computer, no upload step

and if you'd rather skip the whole remote-upload situation and submit the src.rpm from your computer directly to Copr:

; Submit src.rpm from your computer directly to Copr
[copr-project]
releaser = tito.release.CoprReleaser
project_name = my-copr-project-name another-project

two lines of actual config. periodt. ✨

---

💀 Copr: same thing but with a timeout

and finally, the same direct-to-Copr setup, except it times out after 10 minutes:

; Submit src.rpm from your computer directly to Copr, timeout after 10 minutes
[copr-project]
releaser = tito.release.CoprReleaser
project_name = my-copr-project-name another-project
copr_options = --timeout 600

600 seconds = 10 minutes, so copr_options = --timeout 600 is literally the "bestie I am NOT waiting forever" setting 🙈

---

that's the whole page, you made it 🥳 this was RELEASERS.CONF(5), brought to you by tito, dated 08/26/2026 — go forth and release your software, bestie, you're gonna eat 💅💖✨