Winter 2010 SBR600 Weekly Schedule

Please note:

• The schedule here is tentative.
• Week-by-week details will be filled in as the course progresses.

Week 1 (January 11) - Introduction

Tuesday

• Welcome
• Introductions
• Intro to Build & Release
  • Brief overview of the process
    • Versioning & repository systems
    • Compilation
    • Testing
    • Packaging
    • Compositing
    • Release
    • Distribution
    • Mirroring
  • These steps vary according to the particular project/product. For example, when distributing software physically, "Release" means performing a RTM, where the final "gold disk" is sent to the duplicating house to be mass-produced; but when distributing software electronically, "Release" means sending the software to the online distribution system. The sequence of steps also varies between projects/products.
• Course Layout
  • Project-based course
  • Working with Open Source
  • Working with the Fedora Project
• Communication Tools
• Course Outline
• Visit the CDOT Area

Friday

• Make
• Makefile Basics
  • Targets, Dependencies, and Commands
  • Implied rules (e.g., .o files)
  • Examples
• Building software from a source tarball using a makefile

Readings/Resources

• Two simple makefile examples

ToDo

Communication Lab: By Friday, January 15, Set up your accounts (wiki, IRC, FAS2).

• Create a blog post which will appear on the OpenSource@Seneca Planet, containing:
  • A portion of an IRC conversation you've had with someone on a Fedora or Seneca IRC channel.
  • A link to your User page on the Seneca wikis
  • A link to your User page on the Fedora wiki
  • Note: don't just dump this stuff in a blog post, add some introductory text as well!
• Add an entry to the Winter 2010 SBR600 Participants page

Lab 1: By Tuesday, January 19:

• Build 2 packages from Source
  • The NLED editor from http://cdot.senecac.on.ca
  • Any package that uses a configure script -- SourceForge might be a good place to look for such packages.
• Blog about the experience.

Week 2 (January 18) - RPM Packages I

Wednesday

• Discussion of issues related to building
  • Finding dependencies.
  • -jX flag to enable multiple jobs

RPM Packages

• Purpose
• What's in an RPM package file
  • Metadata
    • What the package provides
    • Dependencies
    • Packager, date, license, summary, description, ...
  • Digital signature
  • Software
  • Data
    • Fonts
    • Icons
    • Sample data
  • Documentation
  • Configuration files
  • Setup scripts
    • Pre-install
    • Post-install
    • Pre-uninstall
    • Post-uninstall
    • Triggers

The RPM Database

• Purpose of the database
• Querying the RPM database
  • rpm -q

Friday

Creating Packages

• Packaging scenarios
• Setting up a Packaging Environment
  • Needed packages
    • rpm-build
    • rpmdevtools
    • rpmlint
  • 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
    • rpmbuild --rebuild nameofpackage.src.rpm
  • Building from the spec file
    • 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

Creating a Simple Package

• NLED
• Writing the specfile
• Testing the specfile
• Using rpmlint

Resources

• Fedora Package Maintainers page
  • Packaging How-To

See also "Fedora Linux" chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).

ToDo

• Finish tasks from week 1 if not already completed.
  • Remember, marking in this course is done on the basis of blog posts which appear on the planet.
  • You should have two blog posts on the planet by now: One with a link to your Seneca and Fedora user pages plus a snippet of IRC conversation, and one with a reflection on your experience compiling software from source code.

• Find out what -j value results in the fastest build time for the software you have chosen. Blog about your results.

• Listen to the audio recording of last semester's conference call with Jesse Keating, Fedora Release Engineer

• Take the software you compiled last week and package it (not Nled!). Blog about the experience. Include a link to your source RPM (and optionally your binary RPM) from your blog. Please complete this by Tuesday, January 26.

Week 3 (January 25) - Using Mock and Koji

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.

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.

To build with mock:

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

The value fedora-12-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).

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-f12 --scratch 'foo*.src.rpm

In this example, dist-f12 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).

Resources

• rpmlint
  • fedora:Common Rpmlint issues
• mock
  • Mock Project page
  • fedora: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 (February 1) - Using Mock and Koji II

Week 5 (February 8) - Repositories/Distributing

Week 6 (February 15) - Compositing

Week 7 (February 22) - Server Farms I

Study Week (March 1)

Week 8 (March 8) - Server Farms II

Week 9 (March 15) - Distributed Processing

Week 10 (March 22) - Virtualization

Week 11 (March 29) - Monitoring & Management

Week 12 (April 5) - Presentations

Week 13 (April 12) - Wrap-Up

Exam Week (April 19)