Fall 2011 SBR600 Weekly Schedule

Tentative Schedule - Winter 2012
Please note that the schedule here is tentative. Week-by-week details will be filled in as the course progresses. This content is also being refactored for easier navigation.

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

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