|
|
| (8 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | [[Category:SBR60 Labs]]
| + | This page is obsolete, and has been split into these pages: |
| − | = Purpose =
| + | * [[DPI908/SBR600 Mock Lab]] |
| − | | + | * [[DPI908/SBR600 Koji Lab]] |
| − | To use and become familiar with the ''mock'' and ''koji'' tools.
| |
| − | | |
| − | ''Mock'' is used to test that the BuildRequires for a package are complete and accurate, by creating a bare-bones [http://en.wikipedia.org/wiki/Chroot chroot] environment containing only the [[:fedora:Packaging/Guidelines#Exceptions_2|basic build packages]] plus any packages indicated by BuildRequires lines in the spec file.
| |
| − | | |
| − | ''Koji'' is a client-server system which allows you to queue builds within the Fedora build farm. This permits you to test whether your package builds on multiple different architectures, which is especially useful when you don't otherwise have access to the machines of each architecture. For example, if you are working on a 32-bit PC, you won't be able to directly test builds on a 64-bit PC architecture (x86_64), nor non-PC architectures such as ARM, MIPS, PA-Risc, IA64, S390, Sparc, and PowerPC.
| |
| − | | |
| − | = Background Resources =
| |
| − | | |
| − | * [[:fedora:Using_Mock_to_test_package_builds|Fedora Wiki - Using Mock to test package builds]]
| |
| − | * [[:fedora:PackageMaintainers/UsingKoji|Fedora Wiki - Using Koji]] | |
| − | | |
| − | = Required Resources =
| |
| − | | |
| − | Before starting this lab, you will need:
| |
| − | # A [https://admin.fedoraproject.org/accounts/ Fedora Account System] (FAS2) account.
| |
| − | # The SRPMs from the [[SBR600 RPM-Writing Lab|previous lab]].
| |
| − | | |
| − | = Preparation =
| |
| − | | |
| − | == Mock ==
| |
| − | | |
| − | * Install the mock package: <code>yum install mock</code>
| |
| − | * Add yourself to the mock group: <code>usermod -G mock ''yourUserName''</code>
| |
| − | | |
| − | == Koji ==
| |
| − | | |
| − | * Follow the procedure on the [[:fedora:PackageMaintainers/UsingKoji|UsingKoji]] page on the Fedora wiki for setup instructions. | |
| − | | |
| − | = Steps =
| |
| − | | |
| − | == Testing BuildRequires with Mock ==
| |
| − | | |
| − | # Run this command for each of your SRPMs: <code>mock -r fedora-13-x86_64 ''yourSRPM''</code>
| |
| − | #* Replace ''fedora-13-x86_64'' with the appropriate distribution-release-arch values. This must correspond to a config file in <code>/etc/mock</code> (without the <code>.cfg</code> extension).
| |
| − | #* Replace ''yourSRPM'' with the filename of the SRPM you wish to test.
| |
| − | # If there are errors, they will be recorded in the results directory. Refer to the ''mock'' output for the location of the results directory, which will vary according to the mock configuration file used (if the configuration is ''fedora-13-x86_64'', the results will be in <code>/var/lib/mock/''fedora-13-x86_64''/result</code>).
| |
| − | # Correct any errors by adding appropriate <code>BuildRequilres:</code> tags, build the source RPM, and then retest.
| |
| − | | |
| − | == Testing Builds on Other Architectures using Koji ==
| |
| − | | |
| − | Koji is a client-server system. Your computer runs the client software, which will submit the build job to a koji build hub. The build task will go through several states as it is picked up from the koji hub by a builder (a separate server system which retrieves jobs from the koji-hub and builds them) and that build either succeeds or fails.
| |
| − | | |
| − | === Queueing the Build Request ===
| |
| − | | |
| − | To queue the build request on the main koji server, used for primary architecture builds (i386 and x86_64):
| |
| − | # Issue the command: <code>koji build ''dist-f14'' --scratch ''yourSRPM''</code>
| |
| − | #* ''dist-f14'' (called the ''Target'') instructs koji to build the package using the packages available in the Fedora 14 distribution, and prepare it for inclusion in that distribution.
| |
| − | #* The ''--scratch'' option causes koji to build the package but not tag it for the target (i.e., not to include it in Fedora 14). To perform a build that will be passed to Bodhi for distribution, substitute <code>--rebuild</code> for <code>--scratch</code> and use a git URL for the package (''do not'' do this until you have passed the [[:fedora:Package Review Process|package review]] and [[:fedora:How to get sponsored into the packager group|sponsor]] procedures!).
| |
| − | # You can either follow the progress of the build by leaving the command running, or you may interrupt the <code>koji</code> command by pressing Ctrl-C once the message "this may be safely interrupted" is printed. Record the ''taskID'' printed for future reference.
| |
| − | | |
| − | To queue the build request on the koji server for another architecture, substitute <code>''arch''-koji</code> for the <code>koji</code> command. For example: <code>arm-koji build ''dist-f18'' --scratch ''foo*.src.rpm''</code>
| |
| − | | |
| − | === Viewing the Build Request Status ===
| |
| − | | |
| − | You can view the status of a task through:
| |
| − | * The original koji command, if you did not interrupt it.
| |
| − | * The command: <code>koji watch-task ''taskID''</code>
| |
| − | * Using the web interface.
| |
| − | ** For the primary arch koji system, go to https://koji.fedoraproject.org
| |
| − | ** For any of the secondary arch koji system, go to https://''arch''.koji.fedoraproject.org (e.g., http://arm.koji.fedoraproject.org for the ARM koji web interface)
| |
| − | | |
| − | === Solving Architecture-Specific Errors Identified with Koji ===
| |
| − | | |
| − | ==== Arch-Specific Conditionals ====
| |
| − | | |
| − | If your package does not build on a particular architecture using the same spec file contents as on the primary architectures, you can use architecture-specific conditionals to include or exclude parts of the spec file.
| |
| − | | |
| − | To include parts of a specfile only on a particular architecture (''ppc'' in this example):
| |
| − | | |
| − | %ifarch ''ppc''
| |
| − | BuildRequires: ''foo''
| |
| − | %endif
| |
| − | | |
| − | To exclude parts of a specfile only on a particular architecture:
| |
| − | | |
| − | %ifnarch ''ppc''
| |
| − | BuildRequires: ''bar''
| |
| − | %endif
| |
| − | | |
| − | You can also use <code>%else</code> to specify alternation:
| |
| − | | |
| − | %ifarch ''ppc''
| |
| − | %configure --baz
| |
| − | %else
| |
| − | %configure --qux
| |
| − | %endif
| |
| − | | |
| − | ==== Excluding an Architecture ====
| |
| − | | |
| − | If a package will not build on a particular architecture, perhaps because the BuildRequires are not available on that arch, you can specify that the package should be excluded from that arch:
| |
| − | | |
| − | ExcludeArch: ''ppc''
| |
| − | | |
| − | {{Admon/important|Arch Macros|Some architectures exist in multiple versions. In these cases, a macro is provided which expands to all of the arch names within a family; for example, to exclude all of the ARM varients, use <code>ExcludeArch: %{arm}</code>}}
| |
| − | | |
| − | = Deliverable =
| |
| − | | |
| − | Create a blog post describing your experience. Include:
| |
| − | * Notes on what you did, and what worked and didn't work.
| |
| − | * How long the process took.
| |
| − | * The results, including a link to your SRPM if it was modified from your previous lab.
| |
| − | * Your reflections on the tools, process, and experience.
| |
