1,885
edits
Changes
→Release Dates, Presentations, and Quizzes
** 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.
Over the next 2 weeks, finalize your project plans and get started on your project:
=== ToDo ===
* Finish [[SBR600 RPM-Writing Lab|building your two RPMs for ]] 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: 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. <code>mock</code> is a tool that uses the chroot system call to create a "cleanroom" environment for the build, so that any missing BuildRequires cause the build to fail. {{Admon/caution|The ''Mock'mock''' Group|To use mock, you must first add yourself is used to test that the '''mock''' groupBuildRequires for a package are complete and accurate, by creating a bare-bones [http: <code>usermod -G mock ''yourUserName''</code>}} To build with mock: mock -r ''fedora-13-x86_64'' --rebuild ''foo*/en.srcwikipedia.rpm'' The value ''fedora-13-x86_64'' may be changed to any of the config files found in <code>org/etcwiki/mock<Chroot chroot] environment containing only the [[:fedora:Packaging/code> Guidelines#Exceptions_2|basic build packages]] plus any packages indicated by BuildRequires lines 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)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.
* 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 ==
= 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 ==
Lab
# Test it.
# Blog about this lab, and include a link to your repository RPM package.
= 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 =
