Bodhi/BuildRootOverrides

From FedoraProject

< Bodhi(Difference between revisions)
Jump to: navigation, search
(Add information about what buildroot overrides actually are and why you would need it)
m (What is a BuildRoot Override)
 
(5 intermediate revisions by one user 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. 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 once they are pushed to "stable". You can work around this problem by submitting a BuildRoot Override for this particular build. This will place it into the BuildRoot for the branch that you specify, until the date that you specify. During this time, the package is available to be built 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.
 +
 
 +
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.
 +
 
 +
It usually takes about 15 to 30 minutes for a new BuildRoot Override to take effect.
  
 
= Using Bodhi to manage Koji Buildroot Overrides =
 
= Using Bodhi to manage Koji Buildroot Overrides =
Line 19: Line 23:
 
<pre>
 
<pre>
 
     bodhi --buildroot-override=<name-version-release> --duration=5 --notes="Useful details."
 
     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>
 
</pre>
  

Latest revision as of 06:59, 27 August 2013

Contents

[edit] 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.

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 proven packager) to submit the BuildRoot Override for you.

It usually takes about 15 to 30 minutes for a new BuildRoot Override to take effect.

[edit] Using Bodhi to manage Koji Buildroot Overrides

This document describes how to manage your Koji BuildRoot Overrides using Bodhi. Each section contains URLs for performing actions via the web and commands for doing it from the console.

Idea.png
Legacy method
Legacy method/backup plan: submit releng ticket: https://fedorahosted.org/rel-eng/newticket

[edit] Submitting a new override

https://admin.fedoraproject.org/updates/override/new

    bodhi --buildroot-override=<name-version-release> --duration=5 --notes="Useful details."

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:

    bodhi --buildroot-override=mocha-1.12.0-3.fc20 --duration=5 --notes="For running test suites when building other nodejs packages"

[edit] Viewing your own overrides

https://admin.fedoraproject.org/updates/override/list?mine=True

    bodhi --my-overrides [--show-expired]

[edit] Viewing all overrides

https://admin.fedoraproject.org/updates/override/list

    bodhi --list-overrides [--show-expired]

[edit] Manually expiring your buildroot override

https://admin.fedoraproject.org/updates/override/expire/<name-version-release>

    bodhi --expire-override=<name-version-release>

[edit] Extending your duration or editing override notes

https://admin.fedoraproject.org/updates/override/edit/<name-version-release>

    bodhi --edit-override=<name-version-release> --duration=10 --notes="Oh hai"