mpb - Man Page

mpb [OPTION]...

Given a set of main packages that need to be modified (either for an update, an upgrade, a bug fix ...), build theses packages and compute a list of other packages that depend on them. The computed list is then built against the new version of the main packages, and the success or failure of these new build is compared to the status when the main packages are kept unmodified.

Once the mass-prebuild is done, a report may be generated using the mpb-report(1) tool.

Except from --help, --version and --config, all these option may be provided using the configuration file (mpb.config(5)).

-h,  --help

Show the help message and exit.

--verbose,  -V

Increase output verbosity. This option may be provided multiple times to modify the amount of information provided (e.g. -VV). Other options are affected by the verbosity level, and may provide different information depending on it.

--version,  -v

Show the program version and exit.

--config,  -c CONFIG

Specify the CONFIG file to look for instead of the default $HOME/.mpb/config. The configuration file provides finer control over the cli behavior. See mpb.config(5) for more details.

--stage,  -s STAGE

The provided STAGE should be an integer, representing one of the stages below. (0) Prepare: Project is set-up, main package build is triggered
(1) Check prepare: mpb waits for the main packages builds to be done, and bails out if any of them fails.
(2) Build: The build of dependent packages is triggered. If the dependent package list needs to be computed, that is done at this stage.
(3) Check build: mpb waits for the dependent packages to be built. In case of failure, a pristine build is started for comparison, called checker build. The final status of the packages depend on the result of the build in this checker build.
(4) Collect data: By default, collect logs for packages that are marked as FAILED or UNCONFIRMED.
The tool may be interrupted during stage 1 or 3, in these stages, mpb does nothing but wait on build to proceed in the back-end (usually remote) infrastructure.

--buildid,  -b BUILDID

This option is to be used in order to specify which mpb build needs to be work on. Since mpb may be interrupted, the BUILDID needs to be provided if you want to continue a build that isn’t completed yet. While executing 'mpb -b BUILDID' will continue the execution of a build where it has stopped, some other commands make also use of this option. Specifically: --cancel, --clean, --collect, --info, --list-packages, --rebuild.

--cancel

Cancel any running package build from the given mass rebuild. The project in the back-end infrastructure remains available after this operation.

--clean

This operation is meant to remove the project from the back-end infrastructure. It will therefore cancel any ongoing build (e.g. from COPR) and delete the corresponding data from it. After this operation, there is still some information stored on the local host’s database. This local information is retained until the --clean-db command is invoked.

--backend BACKEND

On the long term, mpb should support multiple back-ends in order to build the packages. This option is available to specify which back-end needs to be used for a new build. For any existing build, this option isn’t necessary, as the information about the back-end to be used is extracted from the local database.

--collect

Collect available data for the given build. This may be used in order to collect data before the completion of a mpb build. User may therefore start to investigate failures while builds are still running. Be aware though that this won’t affect stage (4) in any way, which means that data that was collected through this mean will be collected again in stage (4).

--collect-list COLLECT_LIST

By default, mpb collects all the artifact available for FAILED, UNCONFIRMED and CHECK_NEEDED build status. This option allows to modify this behavior, and therefore more (or less) data.
Accepted values are: 'check_needed', 'failed', 'log', 'running', 'success', 'unconfirmed', 'control-check_needed', 'control-failed', 'control-log', 'control-running', 'control-success', 'control-unconfirmed'.
The control-* values are meant to enable the user to collect data from the checker build.

--list

Dumps a table with basic information about the available mpb builds. By default, it provides the active builds, checker and cleaned build are hidden. In order to see these, the level of verbosity may be increased through the -V option.

--info

Provide detailed information for a given build. This may dump the configuration associated with the build, the build status of the packages, and the list of packages associated with this build depending on the verbosity level that is set. Most of the information is extracted from the local database, although the build status may be updated.

--list-packages

List packages from a given build. Depending on the level of verbosity, more details may be given about the packages. The list is provided in YAML format, which can be understood by mpb, and therefore reused as a base for a new configuration.

--clean-db

Definitely remove cleaned build from the local database. While --clean removes build information from the build infrastructure (e.g. COPR), the --clean-db removes build information still stored locally. Once this information is performed, there is no way to recover the corresponding data.

--rebuild REBUILD

Either a space separated list of packages to rebuild, or one of "failed", "all". Triggers the rebuild of the given packages and reset the stage to build stage. Only reverse dependencies are rebuilt, checker builds are left as-is. Package names are case sensitive. Build ID must be given through '-b/--buildid BUILD_ID' for this command to be executed. + This option may be useful if a failure is assumed to be transient, or if it was due to incorrect build ordering. Packages that are rebuilt that way get there priority lowered prior to the rebuild.

--daemonize,  -d

Starts mpb as a daemon. When starting, information about the build ID is printed out. Knowing the build ID allows the user to follow the status using the --info command.

Depending on the back-end to be used, there are some prerequisites to fulfill:

• For COPR and Koji, the credentials must be setup and available. That means for COPR to have a copr configuration file available in the $XDG_CONFIG_HOME folder. That means for Koji that kinit must have been executed with the proper credentials
• For the remote_mock backend, an ssh access must be available, without user interaction.
• mock needs to be functional on the host it will be executed on.

More information about the mass-prebuilder can be found at https://gitlab.com/fedora/packager-tools/mass-prebuild.

mass-prebuild(7), mpb.config(5), mpb-failedconf(1), mpb-report(1), mpb-whatrequires(1)

mass-prebuild(7), mpb.config(5), mpb-failedconf(1), mpb-report(1), mpb-whatrequires(1).