Difference between revisions of "Fall 2011 SBR600 Weekly Schedule"

From CDOT Wiki
Jump to: navigation, search
(→‎Friday)
(→‎Week 3 (Jan 24) - The Fedora Build System)
 
(18 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
[[Category:Fall 2011 SBR600]]
+
[[Category:Winter 2012 SBR600]]
−
{{Admon/important|Tentative Schedule - Fall 2011|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.}}
+
{{Admon/important|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: [[Winter 2011 SBR600 Weekly Schedule]]
+
Previous semester: [[Fall 2011 SBR600 Weekly Schedule]]
  
−
= Week 1 (Sep 5) - Introduction, Building from Source, and Creating RPM Packages =
+
= Week 1 (Jan 10) - Introduction =
 
== Tuesday ==
 
== Tuesday ==
 
===  Welcome ===
 
===  Welcome ===
Line 12: Line 12:
 
=== Intro to SBR600 - Software Build & Release ===
 
=== Intro to SBR600 - Software Build & Release ===
 
* [[SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process]]
 
* [[SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process]]
−
* Introduction to Free Software and Open Source
 
−
** The [http://fsf.org Free Software Foundation]
 
−
** The [http://opensource.org Open Source Initiative]
 
 
* Introduction to the Fedora Project
 
* Introduction to the Fedora Project
 
** [[:fedora:Main Page|Fedora Project]]
 
** [[:fedora:Main Page|Fedora Project]]
Line 22: Line 19:
 
** Working with Open Source
 
** Working with Open Source
 
** Working with the Fedora Project
 
** Working with the Fedora Project
−
** [[SBR600 Communication Tools|Communication Tools]]
 
 
** [[SBR600|Course Outline]]
 
** [[SBR600|Course Outline]]
 
* How this Course Works
 
* How this Course Works
 
** [[SBR600 Communication Tools]]
 
** [[SBR600 Communication Tools]]
 
** How coursework is submitted in SBR600
 
** How coursework is submitted in SBR600
−
* [[FUDCon Blacksburg 2012]] trip
 
−
** Selection of attendees
 
  
 
=== To Do ===
 
=== To Do ===
−
'''By Monday, September 12:'''
+
'''By Tuesday, January 17:'''
 
# [[SBR600 Communication Lab|Communication Lab]]
 
# [[SBR600 Communication Lab|Communication Lab]]
 
# [[SBR600 Fedora Installation|Fedora Installation]]
 
# [[SBR600 Fedora Installation|Fedora Installation]]
 +
 +
= Week 2 (Jan 17) - RPM Packaging, Mock, and Koji =
 +
 +
== Tuesday ==
 +
 +
=== Using ''make'' ===
 +
 +
* [[SBR600 make and Makefiles|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)
 +
* [[RPM Package Contents|Contents of an RPM Package]]
 +
 +
==== The RPM Database ====
 +
 +
* [[RPM Queries|Querying the RPM database]]
 +
 +
==== Creating an RPM Package ====
 +
* [[RPM Packaging Process]]
 +
 +
==== Resources ====
 +
 +
* Two simple [http://matrix.senecac.on.ca/~chris.tyler/osd600/makefile-examples.tgz makefile examples]
 +
* [[:fedora:PackageMaintainers|Fedora Package Maintainers page]]
 +
** [[:fedora:PackageMaintainers/CreatingPackageHowTo|Packaging How-To]]
 +
* ''Fedora Linux'' chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).
 +
* rpmlint
 +
** [[:fedora:Common Rpmlint issues|Fedora Common Rpmlint issues]]
 +
 +
=== To Do ===
 +
 +
By '''Thursday, January 19''':
 
# [[SBR600 Build-from-Source Lab|Build-from-Source Lab]]
 
# [[SBR600 Build-from-Source Lab|Build-from-Source 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]].
 +
 +
== 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.
 +
 +
=== 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''':
 +
# [[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.
 +
 +
==== The Fedora Build System ====
 +
==== How Koji Works ====
 +
 +
== Thursday ==
 +
 +
* Work on packages
 +
 +
= Week 4 (Jan 31)
 +
 +
== Tuesday/Thursday ==
 +
 +
=== Project Selection ===
 +
 +
This is a project-based course. These projects involve participation in an open-source community.
 +
* Projects are listed on the [[SBR600 Potential Projects]] page.
 +
* Select two or three projects that are of interest to you.
 +
** Do some initial research into what the project involves.
 +
*** Find out who to talk to in the community (start with the initial contacts listed on the project description)
 +
*** See what work has already been done related to that project. Check the Seneca wiki for work by previous SBR600 semesters, the upstream project's wiki and mailing list archives for information about the current state of the project, and the web for related information (similar projects being done by other groups).
 +
*** Join the mailing lists and IRC channels of the upstream community.
 +
** Update the [[Winter 2012 SBR600 Participants]] table with your project information, according to the instructions at the top of that page.
 +
* On Thursday we'll sort out project conflicts.
 +
* [[User:Chris Tyler|Your professor]] will approve your project selection via the [[Winter 2012 SBR600 Participants|participants page]].
 +
* Link your project title on the [[Winter 2011 SBR600 Participants|participants page]] to a page of the same name to create a project page. Copy the contents of the [[Sample Project]] page to your project page and fill in the details.
 +
 +
Over the next 2 weeks, finalize your project plans and get started on your project:
 +
* The project page must be filled in, including your 0.1, 0.2, and 0.3 targets.
 +
** Release 0.1: Proof of concept (e.g., a first draft of a package, a basic script, infrastructure set up on a test system) - Note that this must include the release of ''something'', not just research, and must be done in consultation with the community.
 +
** Release 0.2: Initial working state - Whatever you are working on -- package, script, infrastructure configuration -- should be working, although it may not be feature-complete, fully deployed, or fully documented. Feedback from the community should be solicited. If there is a review process required to submit upstream, it should be started.
 +
** Release 0.3: Completed working state - The work is complete and documented. Any upstream review, whether formal or informal, has been completed, feedback has been incorporated into the project, and the work has been committed been
 +
* You must have a strategy in place for reaching your targets.
 +
You will make a brief (3-5 minute) presentation of your project plans on '''Thursday, February 9'''.
 +
 +
 +
 +
<!--
 
== Friday ==
 
== Friday ==
  
Line 70: Line 172:
 
# [[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]].
 +
# [[SBR600 Build-from-Source Lab|Build-from-Source Lab]]
  
 
= Week 2 (September 12) - Using Mock and Koji =
 
= Week 2 (September 12) - Using Mock and Koji =
  
 
== Tuesday ==
 
== Tuesday ==
 +
 +
=== Layout of a specfile ===
 +
 +
* [[Contents of an RPM spec file]]
 +
 +
=== Creating Packages ===
 +
 +
* [[RPM Packaging Process]]
 +
 +
=== Demo: Creating a Simple Package ===
 +
 +
* Writing the specfile
 +
* Testing the specfile
 +
** Using rpmlint
 +
 +
=== Resources ===
 +
* [[:fedora:PackageMaintainers|Fedora Package Maintainers page]]
 +
** [[:fedora:PackageMaintainers/CreatingPackageHowTo|Packaging How-To]]
 +
* ''Fedora Linux'' chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).
 +
* rpmlint
 +
** [[:fedora:Common Rpmlint issues|Fedora Common Rpmlint issues]]
 +
 +
=== Field Trip! ===
 +
 +
* Visit to the [[CDOT Area]]
 +
 +
== Friday ==
 +
 +
 +
=== 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.
  
 
=== Project Selection ===
 
=== Project Selection ===
Line 84: Line 219:
 
*** See what work has already been done related to that project. Check the Seneca wiki for work by previous SBR600 semesters, the upstream project's wiki and mailing list archives for information about the current state of the project, and the web for related information (similar projects being done by other groups).
 
*** See what work has already been done related to that project. Check the Seneca wiki for work by previous SBR600 semesters, the upstream project's wiki and mailing list archives for information about the current state of the project, and the web for related information (similar projects being done by other groups).
 
*** Join the mailing lists and IRC channels of the upstream community.
 
*** Join the mailing lists and IRC channels of the upstream community.
−
** Update the [[Winter 2011 SBR600 Participants]] table with your project information, according to the instructions at the top of that page.
+
** Update the [[Fall 2011 SBR600 Participants]] table with your project information, according to the instructions at the top of that page.
−
* [[User:Chris Tyler|Your professor]] will approve your project selection via the [[Winter 2011 SBR600 Participants||participants page]].
+
* [[User:Chris Tyler|Your professor]] will approve your project selection via the [[Fall 2011 SBR600 Participants|participants page]].
 
* Link your project title on the [[Winter 2011 SBR600 Participants|participants page]] to a page of the same name to create a project page. Copy the contents of the [[Sample Project]] page to your project page and fill in the details.
 
* Link your project title on the [[Winter 2011 SBR600 Participants|participants page]] to a page of the same name to create a project page. Copy the contents of the [[Sample Project]] page to your project page and fill in the details.
  
Line 94: Line 229:
 
** Release 0.3: Completed working state - The work is complete and documented. Any upstream review, whether formal or informal, has been completed, feedback has been incorporated into the project, and the work has been committed been
 
** Release 0.3: Completed working state - The work is complete and documented. Any upstream review, whether formal or informal, has been completed, feedback has been incorporated into the project, and the work has been committed been
 
* You must have a strategy in place for reaching your targets.
 
* You must have a strategy in place for reaching your targets.
−
You will make a brief (3-5 minute) presentation of your project plans on '''Thursday, February 3'''.
+
You will make a brief (3-5 minute) presentation of your project plans on '''Tuesday, September 27'''.
 +
 
 +
=== Resources ===
 +
* mock
 +
** [[:fedora:Projects/Mock|Mock Project page]]
 +
** [[:fedora:Using_Mock_to_test_package_builds|Using Mock to test package builds]]
  
 
=== ToDo ===
 
=== ToDo ===
  
−
* Finish [[SBR600 RPM-Writing Lab|building your two RPMs]] before Thursday's class (we'll use them in the lab)
+
* Finish [[SBR600 RPM-Writing Lab|building your two RPMs]] by Monday, September 19 (we'll use them in the next lab) - '''remember to blog!'''
−
* Send your [[SSH]] key to [[User:Chris Tyler|your prof]] by Wednesday (will be needed for Thursday's lab)
+
* Send your [[SSH]] key to [[User:Chris Tyler|your prof]] by Monday, September 19 (also needed for the next lab)
 
* Review the [[SBR600 Potential Projects]] and start researching the top 2-3 possibilities.
 
* Review the [[SBR600 Potential Projects]] and start researching the top 2-3 possibilities.
  
−
== Thursday ==
 
  
−
=== mock: Testing BuildRequires ===
+
= Week 3 (September 19) - Koji and Solving Build Issues =  
  
−
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.
+
== Tuesday ==
  
 
=== koji: Testing multiple architectures ===
 
=== koji: Testing multiple architectures ===
Line 113: Line 252:
  
 
=== Resources ===
 
=== Resources ===
−
* mock
 
−
** [[:fedora:Projects/Mock|Mock Project page]]
 
−
** [[:fedora:Using_Mock_to_test_package_builds|Using Mock to test package builds]]
 
 
* koji
 
* koji
 
** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
 
** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
Line 123: Line 259:
 
* [[SBR600 Mock and Koji Lab|Mock and Koji Lab]]
 
* [[SBR600 Mock and Koji Lab|Mock and Koji Lab]]
  
−
= Week 3 (September 19) - Solving Build Issues =  
+
== Friday ==
 +
 
 +
=== Solving Build Issues ===
  
 
* Reasons for Build Failures
 
* Reasons for Build Failures
Line 176: Line 314:
 
# Test it.
 
# Test it.
 
# Blog about this lab, and include a link to your repository RPM package.
 
# Blog about this lab, and include a link to your repository RPM package.
 +
 +
= Week 7 =
 +
 +
* Using GIT
 +
  
 
= Weeks 6 - 13  =
 
= Weeks 6 - 13  =

Latest revision as of 00:30, 2 February 2012

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

To Do

By Tuesday, January 17:

  1. Communication Lab
  2. Fedora Installation

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

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)
  • Contents of an RPM Package

The RPM Database

Creating an RPM Package

Resources

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.

The Fedora Build System

How Koji Works

Thursday

  • Work on packages

= Week 4 (Jan 31)

Tuesday/Thursday

Project Selection

This is a project-based course. These projects involve participation in an open-source community.

  • Projects are listed on the SBR600 Potential Projects page.
  • Select two or three projects that are of interest to you.
    • Do some initial research into what the project involves.
      • Find out who to talk to in the community (start with the initial contacts listed on the project description)
      • See what work has already been done related to that project. Check the Seneca wiki for work by previous SBR600 semesters, the upstream project's wiki and mailing list archives for information about the current state of the project, and the web for related information (similar projects being done by other groups).
      • Join the mailing lists and IRC channels of the upstream community.
    • Update the Winter 2012 SBR600 Participants table with your project information, according to the instructions at the top of that page.
  • On Thursday we'll sort out project conflicts.
  • Your professor will approve your project selection via the participants page.
  • Link your project title on the participants page to a page of the same name to create a project page. Copy the contents of the Sample Project page to your project page and fill in the details.

Over the next 2 weeks, finalize your project plans and get started on your project:

  • The project page must be filled in, including your 0.1, 0.2, and 0.3 targets.
    • Release 0.1: Proof of concept (e.g., a first draft of a package, a basic script, infrastructure set up on a test system) - Note that this must include the release of something, not just research, and must be done in consultation with the community.
    • Release 0.2: Initial working state - Whatever you are working on -- package, script, infrastructure configuration -- should be working, although it may not be feature-complete, fully deployed, or fully documented. Feedback from the community should be solicited. If there is a review process required to submit upstream, it should be started.
    • Release 0.3: Completed working state - The work is complete and documented. Any upstream review, whether formal or informal, has been completed, feedback has been incorporated into the project, and the work has been committed been
  • You must have a strategy in place for reaching your targets.

You will make a brief (3-5 minute) presentation of your project plans on Thursday, February 9.



Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Fall_2011_SBR600_Weekly_Schedule&oldid=80288"