Open main menu

CDOT Wiki β

Changes

Winter 2011 SBR600 Weekly Schedule

1,445 bytes removed, 10:39, 12 April 2011
→‎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]] 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</code> in order to test building based on Chroot chroot] environment containing only the libraries and available packages for a specific architecture and Fedora release. If errors are reported[[:fedora: Packaging/Guidelines# Review the log files (see the mock output to determine the directory containing the log files) to see what dependencies are missing.# Add these dependencies to the <code>Exceptions_2|basic build packages]] plus any packages indicated by BuildRequires</code> lines in your the spec file.# Rebuild your SRPM and repeat the mock test.
=== 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 Fedora-supported primary architectures (currently i386 and x86_64):  koji build ''dist-f18'' --scratch ''foo*.src.rpm'' In this example, ''dist-f18'' selects the build target corresponding to the distribution for Fedora 18 (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>) .You can queue builds for ppc, ppc64, sparc, sparc64, ia64, parisc, mips, and s390 systems in a similar way.}} === 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 == ''Class is cancelled. Recover from FUDCon and work on your project plan.'' == Thursday == * Project pages are due.* Be prepared to give a detailed but brief (3- to 5-minute presentation) on your project plan. = Week 5 (February 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 =
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/wiki/Special:MobileDiff/55447...62401"