From Fedora Project Wiki
m (builroot -> buildroot)
(13 intermediate revisions by 8 users not shown)
Line 1: Line 1:
= What is a BuildRoot Override =
= What is a BuildRoot Override =


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, successful builds become available fairly soon after they complete]]. These packages can then be used to build other packages against.
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]], successful builds become available fairly soon after they complete. These packages can then be used to build other packages against.


However, when building for any of the release branches below rawhide, 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. You can work around this problem 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. It is good practice to specify an expiry date that is only as long as you need (eg, a few days). It can easily be extended if needed. You can also manually expire the Override before the expiry date.
However, when building for any of the release branches below rawhide, 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. You can work around this problem 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. It is good practice to specify an expiry date that is only as long as you need (eg, a few days). It can easily be extended if needed. You can also manually expire the Override before the expiry date. Note that there is only one buildroot per stable branch, so your override applies to everyone's package builds, so take care if this will affect others.  


To submit a BuildRoot override for a package, you need commit access. If you don't have commit access, you can ask the maintainer for the package you are interested in (or a [[Provenpackager_policy|proven packager]]) to submit the BuildRoot Override for you.
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.
It usually takes about 15 to 30 minutes for a new BuildRoot Override to take effect.


= Using Bodhi to manage Koji Buildroot Overrides =
= Using fedpkg to manage koji BuildRoot Overrides =


This document describes how to manage your Koji BuildRoot Overrides using
As of version 1.34 of fedpkg you can make and manage overrides via 'fedpkg override'. Run 'fedpkg override --help' for full information.  
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}}
= Using Bodhi to manage Koji Buildroot Overrides =
 
== Submitting a new override ==
 
https://admin.fedoraproject.org/updates/override/new
 
<pre>
    bodhi --buildroot-override=<name-version-release> --duration=5 --notes="Useful details."
</pre>
 
For example, you successfully built version '''1.12.0''' of the '''mocha''' package for '''f20''', with a release value of '''3'''. The command would be:
 
<pre>
    bodhi --buildroot-override=mocha-1.12.0-3.fc20 --duration=5 --notes="For running test suites when building other nodejs packages"
</pre>
 
== Viewing your own overrides ==
 
https://admin.fedoraproject.org/updates/override/list?mine=True
 
<pre>
    bodhi --my-overrides [--show-expired]
</pre>
 
== Viewing all overrides ==
 
https://admin.fedoraproject.org/updates/override/list
 
<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 ==
See bodhi's online docs: https://bodhi.fedoraproject.org/docs/user/buildroot_overrides.html or 'man bodhi' and look for the OVERRIDES section.


https://admin.fedoraproject.org/updates/override/edit/<name-version-release>
= Issues or special cases =


<pre>
{{admon/tip|Legacy method|Legacy method/backup plan: submit releng ticket: https://pagure.io/releng/new_issue}}
    bodhi --edit-override=<name-version-release> --duration=10 --notes="Oh hai"
</pre>

Revision as of 08:16, 9 September 2020

What is a BuildRoot Override

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, successful builds become available fairly soon after they complete. These packages can then be used to build other packages against.

However, when building for any of the release branches below rawhide, 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. You can work around this problem 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. It is good practice to specify an expiry date that is only as long as you need (eg, a few days). It can easily be extended if needed. You can also manually expire the Override before the expiry date. Note that there is only one buildroot per stable branch, so your override applies to everyone's package builds, so take care if this will affect others.

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 koji BuildRoot Overrides

As of version 1.34 of fedpkg you can make and manage overrides via 'fedpkg override'. Run 'fedpkg override --help' for full information.

Using Bodhi to manage Koji Buildroot Overrides

See bodhi's online docs: https://bodhi.fedoraproject.org/docs/user/buildroot_overrides.html or 'man bodhi' and look for the OVERRIDES section.

Issues or special cases

Idea.png
Legacy method
Legacy method/backup plan: submit releng ticket: https://pagure.io/releng/new_issue