1,885
edits
Changes
Created page with 'Category:Fall 2013 SBR600 <!-- {{Admon/important|Tentative Schedule - Fall 2012|Please note that the schedule here is tentative. Week-by-week details will be added as the cou…'
[[Category:Fall 2013 SBR600]]
<!-- {{Admon/important|Tentative Schedule - Fall 2012|Please note that the schedule here is tentative. Week-by-week details will be added as the course progresses.}} -->
{{Chris Tyler Draft}}
This is the Fall 2013 weekly schedule for the [[SBR600]] course.
Previous semester: [[Fall 2012 DPI908/SBR600 Weekly Schedule]]
<!-- ---------------------------------------------------------------------------------------------- Week 1 ------------ -->
= Week 1 - Introduction =
== Tuesday (September 3) ==
=== Welcome ===
* About this course
* Introductions
=== Intro to SBR600 - Software Build & Release ===
* [[SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process]]
* Introduction to the Fedora Project
** [[:fedora:Main Page|Fedora Project]]
** Fedora ARM Secondary Architecture project at [[Fedora ARM Secondary Architecture|Seneca]] and at the [[:fedora:Architectures/ARM|Fedora Project]]
** Pidora [http://pidora.ca website] and [[Pidora|wiki content]]
* Course Layout
** Project-based course
** Working with Open Source
** Working with the Fedora Project
** [[SBR600|Course Outline]]
* How this Course Works
** [[SBR600 Communication Tools]]
** How coursework is submitted
* Future
** Winter 2014 Semester
*** Project continuation course
** Upcoming Events
*** [http://fsoss.ca Free Software and Open Source Symposium 2013]
== Thursday (September 5) ==
* Communication Tool Setup
=== To Do ===
'''By Tuesday, September 10:'''
# [[SBR600 Communication Lab|Communication Lab]]
# [[SBR600 Fedora Installation|Fedora Installation]]
# Submit the ''Open Source Student Agreement''
<!-- ---------------------------------------------------------------------------------------------- Week 2 ------------ -->
= Week 2 - Building from Source & RPM Packaging =
== Tuesday (September 10) ==
=== 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)
* [[RPM Package Contents|Contents of an RPM Package]]
==== The RPM Database ====
* [[RPM Queries|Querying the RPM database]]
=== Using SSH ===
* Using [[SSH]] - a Review
** Using public/private keypairs
** Passphrase protection
** Keyrings
==== 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 '''Wednesday, September 12''':
# [[DPI908/SBR600 Build-from-Source Lab|Build-from-Source Lab]]
# Send your [[SSH]] public key to your professor.
== Thursday (September 12) ==
==== Creating an RPM Package ====
* [[RPM Packaging Process]]
=== To Do ===
By '''Monday, September 17''':
* [[DPI908/SBR600 RPM-Writing Lab|RPM-Writing Lab]]
<!-- ---------------------------------------------------------------------------------------------- Week 3 ------------ -->
= Week 3 - Mock and Koji, Signing and Repos =
== Tuesday (September 17) ==
=== Mock ===
Mock is a tool which builds a package using rpmbuild in a 'cleanroom' environment. This has several advantages:
* it tests the completeness of the BuildRequires in the spec file
* it avoids the installation of a lot of tools (BuildRequires) on the main host system
* it permits different tools and tool versions to be used for the build than are installed on the host (e.g., building for F18 on an F16 system)
Background information on using Mock:
* [[:fedora:Using_Mock_to_test_package_builds|Using Mock to test package builds]]
=== Using Koji to Test on Multiple Architectures ===
* [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
=== To Do ===
By '''Thursday, September 19''':
# [[DPI908/SBR600 Mock Lab|Mock Lab]]
# [[DPI908/SBR600 Koji Lab|Koji Lab]]
== Thursday (September 19) ==
[[Signing and Creating a Repository for RPM Packages]]
=== To Do ===
By '''Tuesday, September 24''':
# [[DPI908/SBR600 RPM Signing Lab|RPM Signing Lab]]
# [[DPI908/SBR600 Repo Creation Lab|Repo Creation Lab]]
-->
<!-- ---------------------------------------------------------------------------------------------- Week 4 ------------ -->
= Week 4 - Project Selection =
<!--
== Monday (September 24) and Wednesday (September 26) ==
=== 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 2012 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.
This week, 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. Ensure that you have a link from the ''Projects'' column of the [[Fall 2012 DPI908/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.
** 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 to the appropriate repositories (or released in an appropriate manner).
* You must have a strategy in place for reaching your targets.
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.
* During your presentation, you'll
=== To Do ===
* Prepare your project page and project plan presentation.
<!-- ---------------------------------------------------------------------------------------------- Week 5 ------------ -->
= Week 5 - Using GIT and Python =
== Tuesday (October 1) ==
=== Using GIT and FedPkg ===
Resources:
* http://git-scm.com/
* https://github.com/
== Thursday (October 3) ==
=== Python Primer ===
[[SBR600 Python Lab|Python Lab]]
<!-- ---------------------------------------------------------------------------------------------- Week 6 ------------ -->
= Week 6 - Presentations =
== Tuesday (October 8) and Thursday (October 10) ==
=== Project Plan (Release 0.0) Presentations ===
* Please book your time slot on [[Fall 2013 SBR600 Presentation Schedule| the presentation schedule page]] on a first-come first-serve basis.
* Each presentation should take no more than 10 minutes.
<!-- ---------------------------------------------------------------------------------------------- Week 7 ------------ -->
= Week 7 - Project Work =
{{Admon/important|Thanksgiving|Monday, October 14 is the Thanksgiving Holiday.}}
{{Admon/caution|No Class October 15 & 17|Our class will not be meeting this week. Your professor will be at a Polytechnics Canada meeting in Calgary but will be communicating by e-mail (and possibly IRC). Please use this time to work on your 0.1 Project Milestones. You can meet with your professor on Monday or Friday, by appointment.}}
= Study Week and FSOSS =
* Please don't leave your 0.1 milestone work until the last minute!
* Your professor will be around campus most of the week, working on FSOSS. He is also available to meet regarding projects from Monday to Wednesday, by appointment.
* [http://fsoss.ca FSOSS 2012] is Thursday/Friday October 24/25.
= Week 8 - Project Work =
{{Admon/caution|No Class October 19 & 31|Our class will not be meeting this week. Your professor will be at Linaro Connect / ARM TechCon in California but will be communicating by e-mail (and possibly IRC). Please use this time to work on your 0.1 Project Milestones.}}
= Week 9 - Project Work =
{{Admon/caution|No Class November 5 & 7|Our class will not be meeting this week. Your professor will be hiding in a secret location with no Internet access whatsoever.}}
= Week 10 - Presentations =
== Tuesday (November 12) and Thursday (November 14) ==
=== Release 0.1 Presentations ===
* Please book your time slot on [[Fall 2013 SBR600 Presentation Schedule| the presentation schedule page]] on a first-come first-serve basis.
* Each presentation should take no more than 10 minutes.
= Week 11 - Practical Quiz & Project Work =
== Tuesday (November 19) ==
=== Practical Quiz ===
* The quiz consists of one task: you will need to update an RPM to the latest upstream version of the software. For example, if the package is foo-2-1 and there is a new upstream version 3 of foo available, you will need to produce a foo-3-1 package. It would be worthwhile practicing this task in advance.
* The practical quiz will be in T3076 (which not our normal room) so that lab computers will be available.
* Make sure that you have access to your Fedora system, either on your laptop, on a removable disk pack, or through an SSH connection to one of your computers at home. Verify your arrangements! You may want to bring a Fedora Live system on USB or DVD as a backup.
* You may use your notes and online resources during the quiz. However, you may not share information with other people during the quiz.
== Thursday (November 21) ==
=== Problem Solving ===
* We will brainstorm on solutions to project problems.
= Week 12 - Presentations =
== Tuesday (November 26) and Thursday (November 28) ==
=== Release 0.2 Presentations ===
* Please book your time slot on [[Fall 2013 SBR600 Presentation Schedule| the presentation schedule page]] on a first-come first-serve basis.
* Each presentation should take no more than 10 minutes.
= Week 13 - Wrap-up =
== Tuesday (December 3) ==
=== Problem Solving ===
* We will brainstorm on solutions to project problems.
== Thursday (December 5) ==
=== Wrap-Up ===
* Final opportunity to get help and feedback on your project work.
== Exam Week ==
=== Projects Due ===
<!--
== Friday ==
=== Using ''make'' ===
* [[SBR600 make and Makefiles|make and Makefiles]]
=== 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]]
=== 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 '''Monday, January 12''':
# [[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]].
# [[SBR600 Build-from-Source Lab|Build-from-Source Lab]]
= Week 2 (September 12) - Using Mock and Koji =
== 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 ===
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 [[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 [[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.
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 '''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 ===
* 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 Monday, September 19 (also needed for the next lab)
* Review the [[SBR600 Potential Projects]] and start researching the top 2-3 possibilities.
= Week 3 (September 19) - Koji and Solving Build Issues =
== Tuesday ==
=== koji: Testing multiple architectures ===
<code>koji</code> is a client-server system which allows you to queue builds within the Fedora build farm. This permits you to test whether your package builds on several different architectures, which is especially useful when you don't otherwise have access to the machines of that architecture.
=== Resources ===
* koji
** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
=== ToDo ===
* [[SBR600 Mock and Koji Lab|Mock and Koji Lab]]
== Friday ==
=== Solving Build Issues ===
* Reasons for Build Failures
* Solving Build Failures
= Week 4 (September 26) - Project Plan Presentations =
* Project pages are due.
* Be prepared to give a detailed but brief (3- to 5-minute presentation) on your project plan.
= Week 5 (October 3) - Repositories/Distributing =
== 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.
# Create a GPG key: <code>gpg --gen-key</code>
# Add the e-mail address associated with your gpg key to the <code>%_gpg_name</code> macro in <code>~/.rpmmacros</code> -- the line will look like this: <code>%_gpg_name "<i>e-mail-address</i>"</code>
# 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.
# Sign those packages with: <code>rpm --addsign <i>packagefile</i></code>
== Creating a YUM repository ==
A yum repository is just a directory of packages and some metadata.
# 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 <code>/var/www/html</code>
# Put your signed packages in that directory.
# Create the repository metadata for that directory: <code>createrepo <i>/name/of/directory</i></code>
Notice that the repository metadata will be placed in a directory named <code>repodata</code>
== Testing ==
# Create a new repository file in <code>/etc/yum.repos.d</code> by copying and modifying an existing file in that directory. Keep <code>gpgcheck=1</code> but comment out the <code>gpgkey</code> file.
# Confirm that you cannot install from that repository using yum.
# Uncomment the <code>gpgkey</code> line, and point it to a new file within <code>/etc/pki/rpm-gpg/</code>
# Create that file by running (as your regular user): <code>gpg --export --armour <i>e-mail-address</i></code> and saving the output
# Confirm that you can now install from your repository. You should be asked whether you wish to import the key for your repo.
== Repository-release RPM ==
To make it easier for users to access your repository, create a RPM containing:
# Your repo file
# Your GPG key
Take a look at the [http://rpmfusion.org/ RPMFusion] release RPM for an example.
== ToDo ==
Lab
# Create an RPM package that will install your repository configuration file and the key.
# Test it.
# Blog about this lab, and include a link to your repository RPM package.
= Week 7 =
* Using GIT
= Weeks 6 - 13 =
* Project work
<!-- = Release Dates, Presentations, and Quizzes =
* March 7 - '''Release 0.1'''
* March 15/17 - Pre-0.2 presentations
* March 24 - Written Quiz
* April 4 - '''Release 0.2'''
* April 5/7 - Pre-0.3 presentations
* April 11/13 (To Be Confirmed) - OCE Presentations
* April 14 - Practical Quiz
* April 22 - '''Release 0.3''' - DO NOT BE LATE!
-->
<!-- = Week 8 =
* Git
** See http://git-scm.org for basic notes and tutorials
* Using a Git repository
file:///var/www/html/raspi-graphics/raspberry_pi_fedora_remix_horizontal.svg
== ToDo ==
=== Simple Remote Repository Exercise ===
* Clone the repository:
git clone git://england.proximity.on.ca/play
cd play
* Add a branch for your stuff:
git checkout -b $YourName
(add and commit some stuff:)
* Push the branch to the server:
git push --all
* Verify that the branch is on the server:
git ls-remote
* Pull someone else's branch:
git pull origin $SomeoneElsesBranch
git checkout $SomeoneElsesBranch
-->
<!--
= Exam Week =
-->
<!--
= Guest Lecture Notes =
* [[DPI908/SBR600 Guest Lecture-Paul Whalen-20121119]]
-->
<!-- {{Admon/important|Tentative Schedule - Fall 2012|Please note that the schedule here is tentative. Week-by-week details will be added as the course progresses.}} -->
{{Chris Tyler Draft}}
This is the Fall 2013 weekly schedule for the [[SBR600]] course.
Previous semester: [[Fall 2012 DPI908/SBR600 Weekly Schedule]]
<!-- ---------------------------------------------------------------------------------------------- Week 1 ------------ -->
= Week 1 - Introduction =
== Tuesday (September 3) ==
=== Welcome ===
* About this course
* Introductions
=== Intro to SBR600 - Software Build & Release ===
* [[SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process]]
* Introduction to the Fedora Project
** [[:fedora:Main Page|Fedora Project]]
** Fedora ARM Secondary Architecture project at [[Fedora ARM Secondary Architecture|Seneca]] and at the [[:fedora:Architectures/ARM|Fedora Project]]
** Pidora [http://pidora.ca website] and [[Pidora|wiki content]]
* Course Layout
** Project-based course
** Working with Open Source
** Working with the Fedora Project
** [[SBR600|Course Outline]]
* How this Course Works
** [[SBR600 Communication Tools]]
** How coursework is submitted
* Future
** Winter 2014 Semester
*** Project continuation course
** Upcoming Events
*** [http://fsoss.ca Free Software and Open Source Symposium 2013]
== Thursday (September 5) ==
* Communication Tool Setup
=== To Do ===
'''By Tuesday, September 10:'''
# [[SBR600 Communication Lab|Communication Lab]]
# [[SBR600 Fedora Installation|Fedora Installation]]
# Submit the ''Open Source Student Agreement''
<!-- ---------------------------------------------------------------------------------------------- Week 2 ------------ -->
= Week 2 - Building from Source & RPM Packaging =
== Tuesday (September 10) ==
=== 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)
* [[RPM Package Contents|Contents of an RPM Package]]
==== The RPM Database ====
* [[RPM Queries|Querying the RPM database]]
=== Using SSH ===
* Using [[SSH]] - a Review
** Using public/private keypairs
** Passphrase protection
** Keyrings
==== 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 '''Wednesday, September 12''':
# [[DPI908/SBR600 Build-from-Source Lab|Build-from-Source Lab]]
# Send your [[SSH]] public key to your professor.
== Thursday (September 12) ==
==== Creating an RPM Package ====
* [[RPM Packaging Process]]
=== To Do ===
By '''Monday, September 17''':
* [[DPI908/SBR600 RPM-Writing Lab|RPM-Writing Lab]]
<!-- ---------------------------------------------------------------------------------------------- Week 3 ------------ -->
= Week 3 - Mock and Koji, Signing and Repos =
== Tuesday (September 17) ==
=== Mock ===
Mock is a tool which builds a package using rpmbuild in a 'cleanroom' environment. This has several advantages:
* it tests the completeness of the BuildRequires in the spec file
* it avoids the installation of a lot of tools (BuildRequires) on the main host system
* it permits different tools and tool versions to be used for the build than are installed on the host (e.g., building for F18 on an F16 system)
Background information on using Mock:
* [[:fedora:Using_Mock_to_test_package_builds|Using Mock to test package builds]]
=== Using Koji to Test on Multiple Architectures ===
* [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
=== To Do ===
By '''Thursday, September 19''':
# [[DPI908/SBR600 Mock Lab|Mock Lab]]
# [[DPI908/SBR600 Koji Lab|Koji Lab]]
== Thursday (September 19) ==
[[Signing and Creating a Repository for RPM Packages]]
=== To Do ===
By '''Tuesday, September 24''':
# [[DPI908/SBR600 RPM Signing Lab|RPM Signing Lab]]
# [[DPI908/SBR600 Repo Creation Lab|Repo Creation Lab]]
-->
<!-- ---------------------------------------------------------------------------------------------- Week 4 ------------ -->
= Week 4 - Project Selection =
<!--
== Monday (September 24) and Wednesday (September 26) ==
=== 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 2012 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.
This week, 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. Ensure that you have a link from the ''Projects'' column of the [[Fall 2012 DPI908/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.
** 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 to the appropriate repositories (or released in an appropriate manner).
* You must have a strategy in place for reaching your targets.
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.
* During your presentation, you'll
=== To Do ===
* Prepare your project page and project plan presentation.
<!-- ---------------------------------------------------------------------------------------------- Week 5 ------------ -->
= Week 5 - Using GIT and Python =
== Tuesday (October 1) ==
=== Using GIT and FedPkg ===
Resources:
* http://git-scm.com/
* https://github.com/
== Thursday (October 3) ==
=== Python Primer ===
[[SBR600 Python Lab|Python Lab]]
<!-- ---------------------------------------------------------------------------------------------- Week 6 ------------ -->
= Week 6 - Presentations =
== Tuesday (October 8) and Thursday (October 10) ==
=== Project Plan (Release 0.0) Presentations ===
* Please book your time slot on [[Fall 2013 SBR600 Presentation Schedule| the presentation schedule page]] on a first-come first-serve basis.
* Each presentation should take no more than 10 minutes.
<!-- ---------------------------------------------------------------------------------------------- Week 7 ------------ -->
= Week 7 - Project Work =
{{Admon/important|Thanksgiving|Monday, October 14 is the Thanksgiving Holiday.}}
{{Admon/caution|No Class October 15 & 17|Our class will not be meeting this week. Your professor will be at a Polytechnics Canada meeting in Calgary but will be communicating by e-mail (and possibly IRC). Please use this time to work on your 0.1 Project Milestones. You can meet with your professor on Monday or Friday, by appointment.}}
= Study Week and FSOSS =
* Please don't leave your 0.1 milestone work until the last minute!
* Your professor will be around campus most of the week, working on FSOSS. He is also available to meet regarding projects from Monday to Wednesday, by appointment.
* [http://fsoss.ca FSOSS 2012] is Thursday/Friday October 24/25.
= Week 8 - Project Work =
{{Admon/caution|No Class October 19 & 31|Our class will not be meeting this week. Your professor will be at Linaro Connect / ARM TechCon in California but will be communicating by e-mail (and possibly IRC). Please use this time to work on your 0.1 Project Milestones.}}
= Week 9 - Project Work =
{{Admon/caution|No Class November 5 & 7|Our class will not be meeting this week. Your professor will be hiding in a secret location with no Internet access whatsoever.}}
= Week 10 - Presentations =
== Tuesday (November 12) and Thursday (November 14) ==
=== Release 0.1 Presentations ===
* Please book your time slot on [[Fall 2013 SBR600 Presentation Schedule| the presentation schedule page]] on a first-come first-serve basis.
* Each presentation should take no more than 10 minutes.
= Week 11 - Practical Quiz & Project Work =
== Tuesday (November 19) ==
=== Practical Quiz ===
* The quiz consists of one task: you will need to update an RPM to the latest upstream version of the software. For example, if the package is foo-2-1 and there is a new upstream version 3 of foo available, you will need to produce a foo-3-1 package. It would be worthwhile practicing this task in advance.
* The practical quiz will be in T3076 (which not our normal room) so that lab computers will be available.
* Make sure that you have access to your Fedora system, either on your laptop, on a removable disk pack, or through an SSH connection to one of your computers at home. Verify your arrangements! You may want to bring a Fedora Live system on USB or DVD as a backup.
* You may use your notes and online resources during the quiz. However, you may not share information with other people during the quiz.
== Thursday (November 21) ==
=== Problem Solving ===
* We will brainstorm on solutions to project problems.
= Week 12 - Presentations =
== Tuesday (November 26) and Thursday (November 28) ==
=== Release 0.2 Presentations ===
* Please book your time slot on [[Fall 2013 SBR600 Presentation Schedule| the presentation schedule page]] on a first-come first-serve basis.
* Each presentation should take no more than 10 minutes.
= Week 13 - Wrap-up =
== Tuesday (December 3) ==
=== Problem Solving ===
* We will brainstorm on solutions to project problems.
== Thursday (December 5) ==
=== Wrap-Up ===
* Final opportunity to get help and feedback on your project work.
== Exam Week ==
=== Projects Due ===
<!--
== Friday ==
=== Using ''make'' ===
* [[SBR600 make and Makefiles|make and Makefiles]]
=== 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]]
=== 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 '''Monday, January 12''':
# [[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]].
# [[SBR600 Build-from-Source Lab|Build-from-Source Lab]]
= Week 2 (September 12) - Using Mock and Koji =
== 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 ===
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 [[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 [[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.
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 '''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 ===
* 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 Monday, September 19 (also needed for the next lab)
* Review the [[SBR600 Potential Projects]] and start researching the top 2-3 possibilities.
= Week 3 (September 19) - Koji and Solving Build Issues =
== Tuesday ==
=== koji: Testing multiple architectures ===
<code>koji</code> is a client-server system which allows you to queue builds within the Fedora build farm. This permits you to test whether your package builds on several different architectures, which is especially useful when you don't otherwise have access to the machines of that architecture.
=== Resources ===
* koji
** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
=== ToDo ===
* [[SBR600 Mock and Koji Lab|Mock and Koji Lab]]
== Friday ==
=== Solving Build Issues ===
* Reasons for Build Failures
* Solving Build Failures
= Week 4 (September 26) - Project Plan Presentations =
* Project pages are due.
* Be prepared to give a detailed but brief (3- to 5-minute presentation) on your project plan.
= Week 5 (October 3) - Repositories/Distributing =
== 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.
# Create a GPG key: <code>gpg --gen-key</code>
# Add the e-mail address associated with your gpg key to the <code>%_gpg_name</code> macro in <code>~/.rpmmacros</code> -- the line will look like this: <code>%_gpg_name "<i>e-mail-address</i>"</code>
# 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.
# Sign those packages with: <code>rpm --addsign <i>packagefile</i></code>
== Creating a YUM repository ==
A yum repository is just a directory of packages and some metadata.
# 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 <code>/var/www/html</code>
# Put your signed packages in that directory.
# Create the repository metadata for that directory: <code>createrepo <i>/name/of/directory</i></code>
Notice that the repository metadata will be placed in a directory named <code>repodata</code>
== Testing ==
# Create a new repository file in <code>/etc/yum.repos.d</code> by copying and modifying an existing file in that directory. Keep <code>gpgcheck=1</code> but comment out the <code>gpgkey</code> file.
# Confirm that you cannot install from that repository using yum.
# Uncomment the <code>gpgkey</code> line, and point it to a new file within <code>/etc/pki/rpm-gpg/</code>
# Create that file by running (as your regular user): <code>gpg --export --armour <i>e-mail-address</i></code> and saving the output
# Confirm that you can now install from your repository. You should be asked whether you wish to import the key for your repo.
== Repository-release RPM ==
To make it easier for users to access your repository, create a RPM containing:
# Your repo file
# Your GPG key
Take a look at the [http://rpmfusion.org/ RPMFusion] release RPM for an example.
== ToDo ==
Lab
# Create an RPM package that will install your repository configuration file and the key.
# Test it.
# Blog about this lab, and include a link to your repository RPM package.
= Week 7 =
* Using GIT
= Weeks 6 - 13 =
* Project work
<!-- = Release Dates, Presentations, and Quizzes =
* March 7 - '''Release 0.1'''
* March 15/17 - Pre-0.2 presentations
* March 24 - Written Quiz
* April 4 - '''Release 0.2'''
* April 5/7 - Pre-0.3 presentations
* April 11/13 (To Be Confirmed) - OCE Presentations
* April 14 - Practical Quiz
* April 22 - '''Release 0.3''' - DO NOT BE LATE!
-->
<!-- = Week 8 =
* Git
** See http://git-scm.org for basic notes and tutorials
* Using a Git repository
file:///var/www/html/raspi-graphics/raspberry_pi_fedora_remix_horizontal.svg
== ToDo ==
=== Simple Remote Repository Exercise ===
* Clone the repository:
git clone git://england.proximity.on.ca/play
cd play
* Add a branch for your stuff:
git checkout -b $YourName
(add and commit some stuff:)
* Push the branch to the server:
git push --all
* Verify that the branch is on the server:
git ls-remote
* Pull someone else's branch:
git pull origin $SomeoneElsesBranch
git checkout $SomeoneElsesBranch
-->
<!--
= Exam Week =
-->
<!--
= Guest Lecture Notes =
* [[DPI908/SBR600 Guest Lecture-Paul Whalen-20121119]]
-->
