Open main menu

CDOT Wiki β

Fall 2012 DPI908/SBR600 Weekly Schedule

Revision as of 13:16, 4 September 2012 by Chris Tyler (talk | contribs) (Created page with '{{Chris Tyler Draft}}Category:Winter 2012 SBR600 {{Admon/important|Tentative Schedule - Winter 2012|Please note that the schedule here is tentative. Week-by-week details will…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Important.png
This is a draft only!
It is still under construction and content may change. Do not rely on this information.
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.

Week 5 (Feb 7)

Tuesday

Signing RPM packages

An RPM signature, like the digital signature used on many other software-signing systems, is a private key encryption of a checksum. RPM uses the GPG libraries for signing.

  1. Create a GPG key: gpg --gen-key
  2. Add the e-mail address associated with your gpg key to the %_gpg_name macro in ~/.rpmmacros -- the line will look like this: %_gpg_name "e-mail-address"
  3. Find (or make) some packages to put in your repository. Make sure that the epoch-version-release is higher than that of any package with the same name in the Fedora repositories.
  4. Sign those packages with: rpm --addsign packagefile

Creating a YUM repository

A yum repository is just a directory of packages and some metadata.

To create a yum repository:

  1. Create a directory that can be served. The protocol used to serve that directory could be http, ftp, nfs, or something else (the files can be served by putting them on a DVD too!). For http, create the directory within /var/www/html
  2. Put your signed packages in that directory.
  3. Create the repository metadata for that directory: createrepo /name/of/directory (typically: createrepo . )

Notice that the repository metadata will be placed in a subdirectory named repodata

Testing

  1. Create a new repository file in /etc/yum.repos.d by copying and modifying an existing file in that directory. Keep gpgcheck=1 but comment out the gpgkey file.
  2. Confirm that you cannot install from that repository using yum.
  3. Uncomment the gpgkey line, and point it to a new file within /etc/pki/rpm-gpg/
  4. Create that file by running (as your regular user): gpg --export --armour e-mail-address and saving the output to the new filename (note: you'll need to be your regular user to perform the export, but the root user to install the file).
  5. Confirm that you can now install from your repository. You should be asked whether you wish to import the key for your repo the first time you use a package from that repo.

Creating a Repository-release RPM

To make it easier for users to access your repository, create a RPM containing:

  1. Your repo file
  2. Your GPG key

You can link to this repository-release RPM from a web page, and users can install access to your repository by simply clicking on that link. You can also include this package in a Spin or Remix. If you ever need to move your repository's location or make other adjustments, you can provide an updated repository-release package which will be installed when your users perform a yum update.

Take a look at the RPMFusion release RPM for an example.

ToDo

Lab

  1. Create a signed repository containing your RPM package.
  2. Create an RPM package that will install your repository configuration file and the key (repository-release package).
  3. Test it.
  4. Blog about this lab, and include a link to your repository-release package and the repository URL.

Thursday

Project Plan Presentations (0.0)

  • Project pages are due. Link from the Projects column of the Winter 2012 SBR600 Participants table to a page for your project; use the Sample Project template for your project page, and fill in as much detail as possible.
  • Be prepared to give a professional, detailed, but very brief (2- to 4-minute) presentation on your project plan. Include:
    • Your approach to the problem.
    • Contacts and resources you've identified.
    • Your plans for each release. Note that at each release you will be expected to actually release something -- an RPM, a script, test results -- as appropriate to your project. Identify what you are intending to release at each stage:
      • 0.1 Release - proof of concept
      • 0.2 Release - initial functionality
      • 0.3 Release - tested and usable
    • Challenges and potential pitfalls that you have identified, and your approach to mitigating those challenges so that you can complete your project on time regardless of things beyond your control.
    • Time for a brief Q&A/Feedback session at the end.

Week 6 (Feb 14)

Tuesday

Using GIT

Resources:

Thursday

To Do

GIT Lab

Week 7 (Feb 21)

Tuesday

  • Demo of packaging some odd real-world cases for the Raspberry Pi

Wednesday

Thursday

  • Python

Break week!

  • Please don't leave your 0.1 milestone work until the last minute!

Week 9-13

  • Project work
  • Schedule:
    • 0.1 Milestone: March 9
    • 0.2 Milestone: March 23
    • 0.3 Milestone: April 13



Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Fall_2012_DPI908/SBR600_Weekly_Schedule&oldid=86668"