== Tuesday ==
=== mock: Testing BuildRequires 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 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]].* 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.
It's often difficult to Over the next 2 weeks, finalize your project plans and get the BuildRequires 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 spec file exactly rightpackage, because ita basic script, infrastructure set up on a test system) - Note that this must include the release of ''something''s easy to overlook packages that , not just research, and must be done in consultation with the community.** Release 0.2: Initial working state - Whatever you are coincidentally installed working on -- package, script, infrastructure configuration -- should be working, although it may not be feature-complete, fully deployed, or fully documented. Feedback from the machinecommunity should be solicited. <code>mock</code> If there is a tool that uses 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 chroot system call to create work has been committed been* You must have a "cleanroom" environment strategy in place for the buildreaching your targets.You will make a brief (3-5 minute) presentation of your project plans on '''Thursday, so that any missing BuildRequires cause the build to failFebruary 3'''.
{{Admon/caution|The '''mock''' Group|To use mock, you must first add yourself to the '''mock''' group: <code>usermod -G mock ''yourUserName''</code>}}=== ToDo ===
To build with mock* Finish [[SBR600 RPM-Writing Lab|building your two RPMs]] before Thursday's class (we'll use them in the lab)* Send your [[SSH]] key to [[User:Chris Tyler|your prof]] by Wednesday (will be needed for Thursday's lab)* Review the [[SBR600 Potential Projects]] and start researching the top 2-3 possibilities.
mock -r ''fedora-13-x86_64'' --rebuild ''foo*.src.rpm''== Thursday ==
The value ''fedora-13-x86_64'' may be changed to any of the config files found in <code>/etc/=== mock</code> in order to test building based on the libraries and available packages for a specific architecture and Fedora release. If errors are reported, review the log files (see the mock output to determine the directory containing the log files).: Testing BuildRequires ===
== Thursday ==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 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.
{{Admon/note|Koji Setup|Note that koji requires some setup, particularly for certificate-based authentication. See the [[:fedora:PackageMaintainers/UsingKoji|UsingKoji]] page on the Fedora wiki for setup instructions.}} To queue a build for all four Fedora-supported architectures (currently i386, x86_64, ppc, and ppc64): koji build ''dist-f14'' --scratch ''foo*.src.rpm'' In this example, ''dist-f14'' selects the package repository (similar to the <code>-r</code> option for mock, except that the build arch is not specified); <code>--scratch</code> specifies that this is a scratch build (the results are not kept or fed to Bodhi). To perform a build that will be passed to Bodhi for distribution, substitute <code>--rebuild</code> for <code>--scratch</code> (do not do this until you have passed the package review and sponsor procedures). {{Admon/tip|ARM Build|You can queue an ARM build by substituting the ''arm-koji'' command for the ''koji'' command. Alternately, you can specify the server "arm.koji.fedoraproject.org" on the Koji command line (or in <code>/etc/koji.conf</code>).}} === Resources ===
* mock
** [[:fedora:Projects/Mock|Mock Project page]]
** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
=== ToDo === * [[SBR600 Mock and Koji Lab|Mock and Koji Lab]] = Week 3 (January 24) - Solving Build Issues = = Week 4 (January 31) - Project Plan Presentations = == Tuesday ==
* Test ''Class is cancelled. Recover from FUDCon and work on your RPM from last week with:** rpmlint** mock** kojiproject plan.''
* Blog about your experience.== Thursday ==
= Week * Project pages are due.* Be prepared to give a detailed but brief (3 (January 24- to 5-minute presentation) - Solving Build Issues = on your project plan.
= Week 4 5 (January 31February 7) - Repositories/Distributing =
== Signing RPM packages ==
# 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>
== ToDo ==
Project
# Make sure your entry in the [[Fall 2010 SBR600 Project Table]] is complete, and that your project plan on your project page is filled in (including 0.1, 0.2, and 0.3 targets).
Lab
# Test it.
# Blog about this lab, and include a link to your repository RPM package.
= Week 5 (February 7) - Repositories/Distributing =
= 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 =
