Difference between revisions of "DPI908/SBR600 Mock Lab"

From CDOT Wiki
Jump to: navigation, search
(Redirected page to DPI908/SBR600 Mock Lab)
m (spelling)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
#REDIRECT [[DPI908/SBR600_Mock_Lab]]
+
[[Category:DPI908/SBR600 Labs]][[Category: SBR600 Labs]]
 +
= Purpose =
 +
 
 +
To use and become familiar with the ''mock'' tool.
 +
 
 +
''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.
 +
 
 +
= Background Resources =
 +
 
 +
* [[:fedora:Using_Mock_to_test_package_builds|Fedora Wiki - Using Mock to test package builds]]
 +
 
 +
= 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 =
 +
 
 +
* Install the mock package: <code>yum install mock</code>
 +
* Add yourself to the mock group: <code>usermod -aG mock ''yourUserName''</code>
 +
* Log out and then log back in for the additional group to become effective.
 +
 
 +
= Steps =
 +
 
 +
# Run this command for each of your SRPMs: <code>mock -r fedora-26-x86_64 ''yourSRPM''</code>
 +
#* Replace ''fedora-26-x86_64'' with the appropriate distribution-release-arch values; the example is for Fedora 26 on 64-bit AMD/Intel systems. 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-26-x86_64'', the results will be in <code>/var/lib/mock/''fedora-26-x86_64''/result</code>).
 +
# Correct any errors by adding appropriate <code>BuildRequilres:</code> tags, build the source RPM, and then retest.
 +
 
 +
= Deliverable =
 +
 
 +
Create a blog post describing your experience. Include:
 +
* Notes on what you did, and what worked and didn't work.
 +
* How long mock took to complete the build (the first time and on subsequent runs, compared to the rpmbuild time).
 +
* The results, including a link to your SRPM if it was modified from your previous lab.
 +
* Your reflections on the tools, process, and experience.

Latest revision as of 12:23, 26 September 2013

Purpose

To use and become familiar with the mock tool.

Mock is used to test that the BuildRequires for a package are complete and accurate, by creating a bare-bones chroot environment containing only the basic build packages plus any packages indicated by BuildRequires lines in the spec file.

Background Resources

Required Resources

Before starting this lab, you will need:

  1. A Fedora Account System (FAS2) account.
  2. The SRPMs from the previous lab.

Preparation

  • Install the mock package: yum install mock
  • Add yourself to the mock group: usermod -aG mock yourUserName
  • Log out and then log back in for the additional group to become effective.

Steps

  1. Run this command for each of your SRPMs: mock -r fedora-26-x86_64 yourSRPM
    • Replace fedora-26-x86_64 with the appropriate distribution-release-arch values; the example is for Fedora 26 on 64-bit AMD/Intel systems. This must correspond to a config file in /etc/mock (without the .cfg extension).
    • Replace yourSRPM with the filename of the SRPM you wish to test.
  2. 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-26-x86_64, the results will be in /var/lib/mock/fedora-26-x86_64/result).
  3. Correct any errors by adding appropriate BuildRequilres: tags, build the source RPM, and then retest.

Deliverable

Create a blog post describing your experience. Include:

  • Notes on what you did, and what worked and didn't work.
  • How long mock took to complete the build (the first time and on subsequent runs, compared to the rpmbuild time).
  • The results, including a link to your SRPM if it was modified from your previous lab.
  • Your reflections on the tools, process, and experience.