Fall 2011 SBR600 Weekly Schedule

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

Previous semester: Fall 2011 SBR600 Weekly Schedule

Week 1 (Jan 10) - Introduction

Tuesday

Welcome

• About this course
• Introductions

Intro to SBR600 - Software Build & Release

• Brief overview of the Build & Release process
• 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
  • Course Outline
• How this Course Works
  • SBR600 Communication Tools
  • How coursework is submitted in SBR600

To Do

By Tuesday, January 17:

1. Communication Lab
2. Fedora Installation

Week 2 (Jan 17) - RPM Packaging, Mock, and Koji

Tuesday

Using make

• make and Makefiles

Building from Source

• Obtaining source code
• Configuring the build
• Performing the build
• Testing the build
• Installing the built software

RPM Packages

• Differences between managing RPMS and Installing from Source
  • RPMS provide a database of installed software
    • Let you determine what's installed
    • Automatic management of dependencies
    • Identify the origin of files
    • Permit easy update or removal
    • Enable you to verify installation (useful for spotting file corruption and intrusions)
• Contents of an RPM Package

The RPM Database

• Querying the RPM database

Creating an RPM Package

• RPM Packaging Process

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 Thursday, January 19:

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

Thursday

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 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.

Koji: Testing on Multiple Architectures

Most developers and packagers have access to only a small number of system architectures (for example, a developer might have access to 64-bit AMD/Intel, but not have access to 32-bit AMD/Intel, s390 mainframe, PowerPC, or ARM systems). The Koji build system provides a mechanism for building a package in mock on one or more remote systems.

To Do

By Tuesday, January 24:

1. SBR600 Mock and Koji Lab

Week 3 (Jan 24) - The Fedora Build System

Tuesday

Guest Lecturer: Dennis Gilmore, Fedora Release Engineer, Red Hat, Inc.

Dennis is Fedora's release engineer. He will be visiting Seneca Centre for Development of Open Technology (CDOT) this week and has agreed to give a guest lecture on Tuesday.

Thursday

Project Selection