Winter 2011 SBR600 Weekly Schedule

This is a draft only!
It is still under construction and content may change. Do not rely on this information.

Tentative Schedule - Winter 2011
Please note that the schedule here is tentative. Week-by-week details will be filled in as the course progresses.

Previous semester: Fall 2010 SBR600 Weekly Schedule

Week 1 (Jan 10) - Introduction, Building from Source, and Creating RPM Packages

Tuesday

Welcome

• About this course
• Introductions

Intro to SBR600 - Software Build & Release

• Brief overview of the Build & Release process
• Introduction to Free Software and Open Source
  • The Free Software Foundation
  • The Open Source Initiative
• Introduction to the Fedora Project
  • Fedora Project
  • Fedora ARM Secondary Architecture project at Seneca and at the Fedora Project
• Course Layout
  • Project-based course
  • Working with Open Source
  • Working with the Fedora Project
  • Communication Tools
  • Course Outline
• Overview of Deliverables
  • SBR600 Communication Tools
  • How coursework is submitted in SBR600
• FUDCon Tempe 2011 trip
  • Selection of attendees
• Visit to the CDOT Area

To Do

By Wednesday, January 12:

1. Communication Lab
2. Fedora Installation
3. Build-from-Source Lab

Thursday

Using make

• make and Makefiles

RPM Packages

• Purpose
• RPM Package Contents

The RPM Database

• Querying the RPM database

Creating Packages

• Packaging scenarios
• Setting up a Packaging Environment
  • Needed packages
    • rpm-build
    • rpmdevtools
    • rpmlint
    • yum-utils
  • Setting up the RPM tree
    • run rpmdev-setuptree
• Taking a look at existing source RPMS (useful as examples)
  • Installing
    • yumdownloader --source nameofpackage
    • rpm -i nameofpackage.src.rpm
    • Source will be in ~/rpmbuild/SOURCES and specfile will be in ~/rpmbuild/SPECS
  • Examine the specfile
  • Rebuild on the local machine -- takes a source RPM (SRPM) as input, produces binary and source RPMs as output
    • rpmbuild --rebuild nameofpackage.src.rpm
  • Building from the spec file -- takes a specfile and source code as input, produces binary and source RPMs as output
    • cd ~/rpmbuild/SPECS; rpmbuild -ba nameofpackage.spec

Writing a specfile

• Run rpmdev-newspec packagename in ~/rpmbuild/SPECS
• Edit the skeleton specfile.
• Test it: rpmbuild -ba packagename.spec
  • If successful, output will be binary RPM(s) in ~/rpmbuild/RPMS and source RPM in ~/rpmbuild/SRPMS
    • Can install binary RPM with: rpm -i rpmname
  • If unsuccessful, read the error messages carefully.
• Check it with rpmlint: rpmlint packagename*
  • Remember to check the spec file as well as the binary and source RPMs.
  • Correct any errors found.

Layout of a specfile

• Basic Sections

1. preamble - basic metadata
2.  %prep - commands to prepare the package for building
3.  %build - commands to build the package
4.  %install - commands to install the built files
5.  %check - commands to check/test the built files (optional, often not included)
6.  %clean - commands to clean up the disk space
7.  %files - list of files to be included in the pacakge
8.  %changelog - record of the package's change-history

• Scriptlets
  •  %pre -- run before installation
  •  %post -- run after installation
  •  %preun -- run before uninstallation
  •  %postun -- run after uninstallation
    • Note that during upgrade, the installation of the new package is considered to happen before the removal of the old package.
• Macros
  •  %{_tmppath}
  •  %{buildroot}
  •  %{_bindir}
  •  %{_datadir}
  •  %{_mandir}
  •  %{_smp_flags}
  •  %setup
  •  %configure
  •  %makeinstall

rpmlint: Checking for a clean spec file, SRPM, and RPM

rpmlint is a spec file, SRPM (.src.rpm), and RPM (.rpm) checker. To use it, supply the names of the file(s) to be checked as argument(s):

rpmlint foo.spec foo*.rpm

Notice that the checks performed vary based on the input file. For example, some errors in the spec file (such as the summary ending in a period ".") could be determined from the spec file, but only show up when the SRPM/RPM is checked. Each run will report the number of errors and warnings; errors are serious problems which should not be ignored, while warnings may be ignored depending on the context.

Demo: Creating a Simple Package

• Writing the specfile
• Testing the specfile
• Using rpmlint

Resources

• Two simple makefile examples
• Fedora Package Maintainers page
  • Packaging How-To
• Fedora Linux chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).
• rpmlint
  • Fedora Common Rpmlint issues

To Do

By Monday, January 17:

1. RPM-Writing Lab
2. Send your SSH public key to your professor so he can create accounts for you on the CDOT Development Systems.

Week 2 (January 17) - Using Mock and Koji

Tuesday

mock: Testing BuildRequires

It's often difficult to get the BuildRequires in a spec file exactly right, because it's easy to overlook packages that are coincidentally installed on the machine. mock is a tool that uses the chroot system call to create a "cleanroom" environment for the build, so that any missing BuildRequires cause the build to fail.

The mock Group
To use mock, you must first add yourself to the mock group: usermod -G mock yourUserName

To build with mock:

mock -r fedora-13-x86_64 --rebuild foo*.src.rpm

The value fedora-13-x86_64 may be changed to any of the config files found in /etc/mock in order to test building based on the libraries and available packages for a specific architecture and Fedora release. If errors are reported, review the log files (see the mock output to determine the directory containing the log files).

Thursday

koji: Testing multiple architectures

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 several different architectures, which is especially useful when you don't otherwise have access to the machines of that architecture.

Koji Setup
Note that koji requires some setup, particularly for certificate-based authentication. See the UsingKoji page on the Fedora wiki for setup instructions.

To queue a build for all four Fedora-supported architectures (currently i386, x86_64, ppc, and ppc64):

koji build dist-f14 --scratch foo*.src.rpm

In this example, dist-f14 selects the package repository (similar to the -r option for mock, except that the build arch is not specified); --scratch specifies that this is a scratch build (the results are not kept or fed to Bodhi).

To perform a build that will be passed to Bodhi for distribution, substitute --rebuild for --scratch (do not do this until you have passed the package review and sponsor procedures).

ARM Build
You can queue an ARM build by substituting the arm-koji command for the koji command. Alternately, you can specify the server "arm.koji.fedoraproject.org" on the Koji command line (or in /etc/koji.conf).

Resources

• mock
  • Mock Project page
  • Using Mock to test package builds
• koji
  • Using Koji

ToDo

• Test your RPM from last week with:
  • rpmlint
  • mock
  • koji

• Blog about your experience.

Week 4 (January 31) - Repositories/Distributing

Signing RPM packages

An RPM signature, like the digital signature used on many other software-signing systems, is a private key encryption of a checksum. RPM uses the GPG libraries for signing.

1. Create a GPG key: gpg --gen-key
2. Add the e-mail address associated with your gpg key to the %_gpg_name macro in ~/.rpmmacros -- the line will look like this: %_gpg_name "e-mail-address
3. Find (or make) some packages to put in your repository. Make sure that the epoch-version-release is higher than that of any package with the same name in the Fedora repositories.
4. Sign those packages with: rpm --addsign packagefile

Creating a YUM repository

A yum repository is just a directory of packages and some metadata.

1. Create a directory that can be served. The protocol used to serve that directory could be http, ftp, nfs, or something else (the files can be served by putting them on a DVD too!). For http, create the directory within /var/www/html
2. Put your signed packages in that directory.
3. Create the repository metadata for that directory: createrepo /name/of/directory

Notice that the repository metadata will be placed in a directory named repodata

Testing

1. Create a new repository file in /etc/yum.repos.d by copying and modifying an existing file in that directory. Keep gpgcheck=1 but comment out the gpgkey file.
2. Confirm that you cannot install from that repository using yum.
3. Uncomment the gpgkey line, and point it to a new file within /etc/pki/rpm-gpg/
4. Create that file by running (as your regular user): gpg --export --armour e-mail-address and saving the output
5. Confirm that you can now install from your repository. You should be asked whether you wish to import the key for your repo.

Repository-release RPM

To make it easier for users to access your repository, create a RPM containing:

1. Your repo file
2. Your GPG key

Take a look at the RPMFusion release RPM for an example.

ToDo

Project

1. Make sure your entry in the Fall 2010 SBR600 Project Table is complete, and that your project plan on your project page is filled in (including 0.1, 0.2, and 0.3 targets).

Lab

1. Create an RPM package that will install your repository configuration file and the key.
2. Test it.
3. Blog about this lab, and include a link to your repository RPM package.

Weeks 6 - 13

• Project work