Difference between revisions of "Fall 2011 SBR600 Weekly Schedule"
Chris Tyler (talk | contribs) (→Tuesday =) |
Chris Tyler (talk | contribs) (→Week 2 - Jan 17) |
||
Line 78: | Line 78: | ||
# [[SBR600 RPM-Writing Lab|RPM-Writing Lab]] | # [[SBR600 RPM-Writing Lab|RPM-Writing Lab]] | ||
# Send your [[SSH]] public key to [[User:Chris Tyler|your professor]] so he can create accounts for you on the [[CDOT Development Systems]]. | # Send your [[SSH]] public key to [[User:Chris Tyler|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 [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. | ||
+ | |||
+ | === To Do === | ||
+ | |||
+ | By '''Tuesday, January 24''': | ||
+ | # [[SBR600 Mock and Koji Lab]] | ||
+ | |||
<!-- | <!-- |
Revision as of 08:53, 19 January 2012
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:
Week 2 - Jan 17
Tuesday
Using make
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)
- RPMS provide a database of installed software
- Contents of an RPM Package
The RPM Database
Creating an RPM Package
Resources
- Two simple makefile examples
- Fedora Package Maintainers page
- Fedora Linux chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).
- rpmlint
To Do
By Thursday, January 19:
- Build-from-Source Lab
- RPM-Writing Lab
- 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.
To Do
By Tuesday, January 24: