BODHI(1)

📦
version 26.4.0 · 5 versions
, in fedora 43

💖 BODHI(1) — the bodhi manual, bestie edition 💖

okay so before we even start: this is the man page for bodhi, section 1 of the manual, and it lives at the top of your terminal like BODHI(1) on the left and BODHI(1) on the right, with bodhi chillin' in the middle. that's just how man pages flex. anyway. let's get into it 🫶

✨ NAME ✨

bodhi — manage Fedora updates

that's it. that's the whole name section. short, sweet, iconic. 👑

🌸 SYNOPSIS 🌸

bodhi COMMAND SUBCOMMAND [OPTIONS] [ARGS]...

so the shape of literally every invocation is: a command, then a subcommand, then whatever options and args you feel like throwing at it. no cap. ✨

🦋 DESCRIPTION 🦋

bodhi is the command line interface to bodhi — which is Fedora's update release management system, in case you were wondering who's running the whole update situation. 💅

you can use it to create or modify updates and overrides. that's the whole vibe. that's the job.

💅 OPTIONS 💅

most of the commands will accept these options, so like, they're basically the group chat everyone's in:

  • --client-id <string> — use the OpenID Connect client_id you hand over instead of the default one. heads up though: this gets ignored if the --staging flag is set. 🙈
  • --debug — some commands accept this flag to show extra debug information. (emphasis on some, bestie, don't come for me.)
  • --help — show help text and exit. your classic escape hatch. 🏃♀️
  • --id-provider <url> — use the OpenID Connect provider at the given URL instead of the default server. you can also set this with the BODHI_OPENID_PROVIDER environment variable. and again: ignored if --staging is set. ✨
  • --staging — use the staging bodhi instance instead of the production instance. your safe little sandbox. 🧚
  • --url <url> — use the Bodhi server at the given URL instead of the default server. you can also set this with the BODHI_URL environment variable. and yep, one more time: ignored if --staging is set. 💀
  • --version — show version and exit. not accepted by subcommands, so don't try it, it's giving boundaries. ⭐

👑 COMMANDS 👑

there are four commands: composes, overrides, updates and releases. they each get their own little section below because they're all main characters. 💖

  • bodhi composes <subcommand> [options] [args] — provides an interface to view composes. supports the subcommands list and info, described below. 🌈
  • bodhi overrides <subcommand> [options] [args] — provides commands to aid in management of build overrides. supports the subcommands query and save, described below. 🔥
  • bodhi updates <subcommand> [options] [args] — provides an interface to manage updates. supports the subcommands comment, download, new, query, and request, described below. 💜
  • bodhi releases <subcommand> [options] [args] — provides an interface to manage releases. supports the subcommands create, edit, info and list, described below. 🎀

🎀 COMPOSES 🎀

the composes command lets users view composes. that's the whole assignment. 👑

bodhi composes list [options]

the list subcommand lets you see the current composes on the Bodhi server. it supports the following option:

  • -v, --verbose — print more detail about the composes. more words, more lore. 📖

bodhi composes info [options] RELEASE REQUEST

the info subcommand lets you see the compose for release with the given request. you give it a RELEASE and a REQUEST, and it gives you the tea. ☕

🦄 OVERRIDES 🦄

the overrides command lets users manage build overrides. it's giving admin energy, but make it cute. ✨

bodhi overrides query [options]

the query subcommand provides an interface for users to query the bodhi server for existing overrides. it supports the following options:

  • --mine — show only your overrides. it's about you. it's always been about you. 💅
  • --active — filter for only active overrides.
  • --expired — filter for only expired overrides.
  • --packages <packagename> — query for overrides related to the given packages, given as a comma-separated list.
  • --releases <releases> — query for overrides related to a list of releases, given as a comma-separated list. <releases> is the release shortname, for example: F26 or F26,F25, or a macro filter (__current__, __pending__, __archived__) to include all releases in a certain status. 🌈
  • --builds <builds> — query for overrides for a list of builds, given as a comma-separated list. <builds> is the build NVR, for example: corebird-1.3-0.fc24. 🔥
  • --user <username> — filter for overrides by a list of usernames, given as a comma-separated list.
  • --rows <integer> — limits number of results shown per page.
  • --page <integer> — go to page number. pagination nation. 📄

bodhi overrides save [options] <nvr>

save the build root given by <nvr> as a buildroot override. the save subcommand supports the following options:

  • --duration <days> — the number of days the override should exist, given as an integer. ⏳
  • --notes <text> — notes on why this override is in place. future you says thank you. 🫶

bodhi overrides edit [options] <nvr>

edit the build root given by <nvr> as a buildroot override. the edit subcommand supports the same options as the save command, and also the following option:

  • --expire — force an override to the expired state. bye bestie, you had a good run. 💀
more of this manual is coming, bestie — we're only on part 1 of 3. don't go anywhere. 💖

✨ UPDATES ✨

okay bestie, so the updates command is literally your whole backstage pass to bodhi updates 💅 you can comment, download, create, edit, query, request changes, waive tests, and trigger tests. it's giving main character energy for package maintainers fr fr.

bodhi updates comment [options] <update> <text>

Leave the given text as a comment on a bodhi update. The comment subcommand supports the following options:

  • --karma [+1 | 0 | -1] — The karma value you wish to contribute to the update. 💖

bodhi updates download [options]

Download update(s) given by ID(s) or NVR(s). One of --updateid or builds is required. The download subcommand supports the following options:

  • --debuginfo — Include debuginfo packages when downloading. 🐛
  • --updateid <ids> — A comma-separated list of update IDs you would like to download. 🆔
  • --builds <nvrs> — A comma-separated list of NVRs that identify updates you would like to download. 📦
  • --arch <arch> — You can specify an architecture of packages to download. "all" will download packages for all architectures. Omitting this option will download packages for the architecture you are currently running. 🏗️

bodhi updates new [options] <builds_or_tag>

Create a new bodhi update containing the builds, given as a comma separated list of NVRs. The new subcommand supports the following options:

  • --type [security | bugfix | enhancement | newpackage] — The type of the new update. ✨
  • --notes <text> — The description of the update. 📝
  • --notes-file <path> — A path to a file containing a description of the update. 📄
  • --bugs <bugs> — A comma separated list of bugs to associate with this update. 🐞
  • --close-bugs / --no-close-bugs — If given, this flag will cause bodhi to close the referenced bugs automatically when the update reaches stable. When creating a new update this is off by default. 🔒
  • --request [testing | stable | upush] — The repository requested for this update. 🚀
  • --autokarma / --no-autokarma — Enable or disable autokarma for this update. When creating a new update this is off by default. ⚖️
  • --autotime / --no-autotime — Enable autotime for this update. Automatically push the update to stable based on the time spent in testing. When creating a new update this is off by default. ⏰
  • --stable-karma <integer> — Configure the stable karma threshold for the given value. 📈
  • --unstable-karma <integer> — Configure the unstable karma threshold for the given value. 📉
  • --stable-days <integer> — Configure the number of days an update has to spend in testing before being automatically pushed to stable. 📅
  • --suggest [logout | reboot] — Suggest that the user logout or reboot upon applying the update. 🔄
  • --file <path> — A path to a file containing all the update details. 📁
  • --requirements <Taskotron tasks> — A comma or space-separated list of required Taskotron tasks that must pass for this update to reach stable. ✅
  • --display-name <text> — The name of the update 👑
  • --from-tag — If this flag is provided, <builds_or_tag> will be interpreted as a Koji tag and expand to all latest builds in it. Only a single tag can be provided. 🏷️

bodhi updates edit [options] <update>

Edit an existing bodhi update, given an update id or an update title. The edit subcommand supports the following options:

  • --addbuilds <builds> — Add a comma separated list of build nvr to this update. ➕
  • --removebuilds <builds> — Remove a comma separated list of build nvr from this update. ➖
  • --type [security | bugfix | enhancement | newpackage] — The type of the new update. ✨
  • --notes <text> — The description of the update. 📝
  • --notes-file <path> — A path to a file containing a description of the update. 📄
  • --bugs <bugs> — A comma separated list of bugs to associate with this update. 🐞
  • --close-bugs — If given, this flag will cause bodhi to close the referenced bugs automatically when the update reaches stable. 🔒
  • --request [testing | stable | upush] — The repository requested for this update. 🚀
  • --autokarma — Enable autokarma for this update. ⚖️
  • --stable-karma <integer> — Configure the stable karma threshold for the given value. 📈
  • --unstable-karma <integer> — Configure the unstable karma threshold for the given value. 📉
  • --suggest [logout | reboot] — Suggest that the user logout or reboot upon applying the update. 🔄
  • --requirements <Taskotron tasks> — A comma or space-separated list of required Taskotron tasks that must pass for this update to reach stable. ✅
  • --display-name <text> — The name of the update 👑
  • --from-tag — If given, for updates that were created from a Koji tag, this will update the builds to the latest ones in the tag. 🏷️

bodhi updates query [options]

Query the bodhi server for updates.

If the query returns only one update, a detailed view of the update will be displayed.

If more than one update is returned, the command will display a list showing the packages contained in the update, the update content-type (rpm / module / ...), the current status of the update (pushed / testing / ...) and the date of the last status change with the number of days passed since. A leading * marks security updates.

The query subcommand supports the following options:

  • --updateid <id> — Query for the update given by id. 🆔
  • --title <title> — Query for the update given by title. 🏷️
  • --alias <alias> — Query for the update given by alias. 🪪
  • --approved-since <timestamp> — Query for updates approved after the given timestamp. ⏳
  • --approved-before <timestamp> — Query for updates approved before the given timestamp. ⏳
  • --modified-since <timestamp> — Query for updates modified after the given timestamp. 🛠️
  • --modified-before <timestamp> — Query for updates modified before the given timestamp. 🛠️
  • --builds <builds> — Query for updates containing the given builds, given as a comma-separated list. 📦
  • --bugs <bugs> — Query for updates related to the given bugs, given as a comma-separated list. 🐞
  • --content-type <content_type> — Query for updates of a given content type: either rpm, module, or (in the future) container. 📦
  • --critpath — Query for updates submitted for the critical path. 🚨
  • --from-side-tag — Query for updates created from a side-tag. 🏷️
  • --not-from-side-tag — Query for updates not created from a side-tag. 🚫
  • --gating [passed | failed | ignored | waiting | running | queued | greenwave_failed] — Query for updates based on test gating status. 🚦
  • --mine — Show only your updates. 🙋
  • --packages <packages> — Query for updates related to the given packages, given as a comma-separated list. 📦
  • --pushed — Query for updates that have been pushed. 🚀
  • --pushed-since <timestamp> — Query for updates that have been pushed after the given timestamp. ⏳
  • --pushed-before <timestamp> — Query for updates that have been pushed before the given timestamp. ⏳
  • --releases <releases> — Query for updates related to a list of releases, given as a comma-separated list. It is possible to use the macro filters __current__, __pending__ and __archived__ to include all releases in a certain status. 🏷️
  • --locked — Query for updates that are currently locked. 🔒
  • --request [testing | stable | unpush] — Query for updates marked with the given request type. 🚀
  • --severity [unspecified, urgent, high, medium, low] — Query for updates with a specific severity. 🚨
  • --submitted-since <timestamp> — Query for updates that were submitted since the given timestamp. ⏳
  • --submitted-before <timestamp> — Query for updates that were submitted before the given timestamp. ⏳
  • --status [pending | testing | stable | obsolete | unpushed] — Filter by status. 📊
  • --suggest [logout | reboot] — Filter for updates that suggest logout or reboot to the user. 🔄
  • --type [newpackage | security | bugfix | enhancement] — Filter by update type. ✨
  • --user <username> — Filter for updates by a list of usernames, given as a comma-separated list. 👤
  • --rows <integer> — Limits number of results shown per page. 📄
  • --page <integer> — Go to page number. 📖

bodhi updates request [options] <update> <state>

Request that the given update be changed to the given state. update should be given by update id, and state should be one of testing, stable, unpush, obsolete, or revoke. 🔄

bodhi updates waive [options] <update> <comment>

Show or waive unsatisfied test requirements on an update.

The following options are supported:

  • --show — List the unsatisfied test requirements. 👀
  • --test TEXT — Waive the test specified by name in TEXT. all can be used to waive all unsatisfied tests. ✅
  • --debug — Display debugging information. 🐛

bodhi updates trigger-tests [options] <update>

Trigger tests for an update. This update must be in testing state. 🧪

🌸 RELEASES 🌸

okay bestie, the releases command is your whole backstage pass for managing update releases. let's get into it 💖

✨ bodhi releases create [options] ✨

the create command is how admins spin up brand new releases in Bodhi. it's giving "new era loading" 🦋

  • --branch TEXT — the git branch that corresponds to this release (like f29).
  • --candidate-tag TEXT — the Koji tag to use to search for update candidates (like f29-updates-candidate).
  • --composed-by-bodhi, --not-composed-by-bodhi — the flag that says whether the release is composed by Bodhi or not.
  • --dist-tag TEXT — the Koji dist tag for this release (like f29).
  • --id-prefix TEXT — the release's prefix (like FEDORA).
  • --long-name TEXT — the long name of the release (like Fedora 29).
  • --name TEXT — the name of the release (like F29).
  • --override-tag TEXT — the Koji tag to use for buildroot overrides (like f29-override).
  • --package-manager [unspecified|dnf|yum] — the package manager this release uses. if you don't specify, it defaults to 'unspecified'.
  • --pending-stable-tag TEXT — the Koji tag to use on updates that are marked stable (like f29-updates-pending).
  • --pending-testing-tag TEXT — the Koji tag to use on updates that are pending testing (like f29-updates-pending-testing).
  • --stable-tag TEXT — the Koji tag to use for stable updates (like f29-updates).
  • --state [disabled|pending|frozen|current|archived] — the state of the release.
  • --testing-repository TEXT — the name of the testing repository used to test updates. not required, so no pressure 🫶
  • --testing-tag TEXT — the Koji tag to use for testing updates (like f29-updates-testing).
  • --version TEXT — the version of the release (like 29).

✨ bodhi releases edit [options] ✨

the edit command lets admins edit releases that already exist. glow-up time 💅

  • --branch TEXT — the git branch that corresponds to this release (like f29).
  • --candidate-tag TEXT — the Koji tag to use to search for update candidates (like f29-updates-candidate).
  • --composed-by-bodhi, --not-composed-by-bodhi — the flag that says whether the release is composed by Bodhi or not.
  • --dist-tag TEXT — the Koji dist tag for this release (like f29).
  • --id-prefix TEXT — the release's prefix (like FEDORA).
  • --long-name TEXT — the long name of the release (like Fedora 29).
  • --name TEXT — the name of the release (like F29).
  • --new-name — change the release's name to a new value (like F29).
  • --override-tag TEXT — the Koji tag to use for buildroot overrides (like f29-override).
  • --package-manager [unspecified|dnf|yum] — the package manager used by this release. if you don't specify, it defaults to 'unspecified'.
  • --pending-stable-tag TEXT — the Koji tag to use on updates that are marked stable (like f29-updates-pending).
  • --pending-testing-tag TEXT — the Koji tag to use on updates that are pending testing (like f29-updates-testing-pending).
  • --stable-tag TEXT — the Koji tag to use for stable updates (like f29-updates).
  • --state [disabled|pending|frozen|current|archived] — the state of the release.
  • --testing-repository TEXT — the name of the testing repository used to test updates. not required ✨
  • --testing-tag TEXT — the Koji tag to use for testing updates (like f29-updates-testing).
  • --version TEXT — the version of the release (like 29).

✨ bodhi releases info RELEASE_NAME ✨

the info command prints info about the release you named. it's giving "tell me everything" 🙈

✨ bodhi releases list [options] ✨

the list command prints a list of releases. window shopping but for releases 🛍️

  • --display-archived — display the full list, archived releases included.
  • --rows <integer> — limits how many results show up per page.
  • --page <integer> — go to page number.

✨ bodhi releases requirements RELEASE_NAME ✨

the requirements command prints info about the status of the release you named, plus the requirements its updates need before they can be pushed to stable. the vibe check before the promotion 💖

🌈 EXAMPLES 🌈

wanna create a new update with multiple builds? say less:

$ bodhi updates new --user bowlofeggs --type bugfix --notes "Fix permission issues during startup." --bugs 1393587 --close-bugs --request testing --autokarma --stable-karma 3 --unstable-karma -3 ejabberd-16.09-2.fc25,erlang-esip-1.0.8-1.fc25,erlang-fast_tls-1.0.7-1.fc25,erlang-fast_yaml-1.0.6-1.fc25,erlang-fast_xml-1.1.15-1.fc25,erlang-iconv-1.0.2-1.fc25,erlang-stringprep-1.0.6-1.fc25,erlang-stun-1.0.7-1.fc25

🫶 HELP 🫶

if you find bugs in bodhi (or in the man page — rude but valid), please feel free to file a bug report or a pull request. the door is open bestie, no gatekeeping here:

https://github.com/fedora-infra/bodhi

Bodhi's documentation is available online:

https://fedora-infra.github.io/bodhi

👑 AUTHOR 👑

Randy Barlow, Luke Macken

2007-2026, Red Hat, Inc.

and that's the whole page, bestie 🎀 this one comes from the BODHI(1) manual page, dated Mar 26, 2026 — go be a main character with your updates, ily, mwah 💋✨

📦 where this page comes from