From Fedora Project Wiki
(update for how things work currently and include a lot of loud advertising for using side tags instead of overrides)
 
(23 intermediate revisions by 12 users not shown)
Line 1: Line 1:
= Using Bodhi to manage Koji Buildroot Overrides =
== What is a Buildroot Override ==


This document describes how to manage your Koji BuildRoot Overrides using
{{Admon/warning|Use on-demand side tags instead|Buildroot overrides should now be used only rarely. The normal method for creating multi-package updates, both for Rawhide and other branches, is to use on-demand side tags. See [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages the Package Update Guide] for more details.}}
Bodhi. Each section contains URLs for performing actions via the web and
commands for doing it from the console.


{{admon/tip|Legacy method|Legacy method/backup plan: submit releng ticket: https://fedorahosted.org/rel-eng/newticket}}
Sometimes a package you are trying to build can't be done until another package that it depends on is updated. [[Releases/Rawhide#Producing_Rawhide|When building packages for Rawhide]] and Branched before updates-testing activation, updates are automatically created for successful builds. As long as all gating tests pass, the update will be immediately pushed "stable" and shortly thereafter the package will be available in the Rawhide buildroot to build other packages against. However, if the update breaks the dependencies of downstream packages it may fail gating tests and be blocked from stable push, so when trying to update packages with dependency implications like this, you should [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages follow the instructions to use an on-demand side tag] to create a multi-package update.


== Submitting a new override ==
When building for Branched after updates-testing is activated or for any stable release, builds are usually only available to be built against once they are pushed to "stable". Often it isn't practical or convenient to wait for this to happen.


{{admon/note|Auto expiration|If you do not specify a 'duration', which is the number of days you wish for it to be active, your override will automatically be expired when your update gets pushed to the 'stable' repository (or gets deleted/unpushed/obsoleted).}}
The normal way to handle this now is to use an on-demand side tag, as explained in [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages the Package Update Guide]. You can create a side tag, do your initial build there, and it will immediately be included in the buildroot for that side tag, so you can build other packages against it in the same side tag. Once all related packages have been built, you can create an update from the side tag, which will contain all the packages.


https://admin.fedoraproject.org/updates/override/new
The older way to work around this problem was by submitting a buildroot override for any package builds you need that haven't yet made it to "stable". This will place the package into the buildroot for the branch that you specify until the expiry date that you specify. During this time, the package is available to be built against. A drawback of this method is that '''all''' builds run by anybody during the time the override is active will build against the overridden package, so it is strongly recommended to specify an expiry date that is only as long as you need (e.g. a few hours). It can easily be extended if needed. You can and should also manually expire the override before the expiry date, once you have completed all the builds you wish to run.


<pre>
To submit a buildroot override for a package, you need to be a member of the packager group.
    bodhi --buildroot-override=<name-version-release> --duration=5 --notes="Useful details."
</pre>


== Viewing your own overrides ==
It usually takes about 15 to 30 minutes for a new buildroot override to take effect.


https://admin.fedoraproject.org/updates/override/list?mine=True
= Using fedpkg to manage buildroot overrides =


<pre>
You can make and manage overrides via {{command|fedpkg override}}. Run {{command|fedpkg override --help}} for full information.
    bodhi --my-overrides [--show-expired]
</pre>


== Viewing all overrides ==
= Using Bodhi to manage buildroot overrides =


https://admin.fedoraproject.org/updates/override/list
See [https://bodhi.fedoraproject.org/docs/user/buildroot_overrides.html bodhi's online docs] or {{command|man bodhi}} and look for the OVERRIDES section.
 
<pre>
    bodhi --list-overrides [--show-expired]
</pre>
 
== Manually expiring your buildroot override ==
 
https://admin.fedoraproject.org/updates/override/expire/<name-version-release>
 
<pre>
    bodhi --expire-override=<name-version-release>
</pre>
 
== Extending your duration or editing override notes ==
 
https://admin.fedoraproject.org/updates/override/edit/<name-version-release>
 
<pre>
    bodhi --edit-override=<name-version-release> --duration=10 --notes="Oh hai"
</pre>

Latest revision as of 18:53, 29 February 2024

What is a Buildroot Override

Use on-demand side tags instead
Buildroot overrides should now be used only rarely. The normal method for creating multi-package updates, both for Rawhide and other branches, is to use on-demand side tags. See the Package Update Guide for more details.

Sometimes a package you are trying to build can't be done until another package that it depends on is updated. When building packages for Rawhide and Branched before updates-testing activation, updates are automatically created for successful builds. As long as all gating tests pass, the update will be immediately pushed "stable" and shortly thereafter the package will be available in the Rawhide buildroot to build other packages against. However, if the update breaks the dependencies of downstream packages it may fail gating tests and be blocked from stable push, so when trying to update packages with dependency implications like this, you should follow the instructions to use an on-demand side tag to create a multi-package update.

When building for Branched after updates-testing is activated or for any stable release, builds are usually only available to be built against once they are pushed to "stable". Often it isn't practical or convenient to wait for this to happen.

The normal way to handle this now is to use an on-demand side tag, as explained in the Package Update Guide. You can create a side tag, do your initial build there, and it will immediately be included in the buildroot for that side tag, so you can build other packages against it in the same side tag. Once all related packages have been built, you can create an update from the side tag, which will contain all the packages.

The older way to work around this problem was by submitting a buildroot override for any package builds you need that haven't yet made it to "stable". This will place the package into the buildroot for the branch that you specify until the expiry date that you specify. During this time, the package is available to be built against. A drawback of this method is that all builds run by anybody during the time the override is active will build against the overridden package, so it is strongly recommended to specify an expiry date that is only as long as you need (e.g. a few hours). It can easily be extended if needed. You can and should also manually expire the override before the expiry date, once you have completed all the builds you wish to run.

To submit a buildroot override for a package, you need to be a member of the packager group.

It usually takes about 15 to 30 minutes for a new buildroot override to take effect.

Using fedpkg to manage buildroot overrides

You can make and manage overrides via fedpkg override. Run fedpkg override --help for full information.

Using Bodhi to manage buildroot overrides

See bodhi's online docs or man bodhi and look for the OVERRIDES section.