Open main menu

CDOT Wiki β

Changes

Winter 2011 SBR600 Weekly Schedule

1,454 bytes removed, 10:39, 12 April 2011
→‎Release Dates, Presentations, and Quizzes
{{Chris Tyler Draft}}[[Category:Winter 2011 SBR600]]{{Admon/important|Tentative Schedule - Winter 2011|Please note that the schedule here is tentative. Week-by-week details will be filled in as the course progresses. This content is also being refactored for easier navigation.}}
Previous semester: [[Fall 2010 SBR600 Weekly Schedule]]
* Introductions
=== Intro to SBR600 - Software Build & Release ===* [[SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process - These steps vary according to the particular project/product. For example, when distributing software physically, "Release" means performing a release-to-manufacturing (RTM), where the final "gold disk" is sent to the duplicating house to be mass-produced; but when distributing software electronically, "Release" means sending the software to the online distribution system. The sequence of steps also varies between projects/products.** Version Control** Compilation** Testing** Packaging** Compositing** Release** Distribution** Mirroring]]
* Introduction to Free Software and Open Source
** The [http://fsf.org Free Software Foundation]
** [[SBR600 Communication Tools|Communication Tools]]
** [[SBR600|Course Outline]]
* How this Course Works** [[SBR600 Communication Tools]]** How coursework is submitted in SBR600* [[FUDCon Tempe 2011]] trip** Selection of attendees* Visit to the [[CDOTArea]] Area
=== To Do ===
=== Using ''make'' ===
* Makefile Basics** Targets, Dependencies, [[SBR600 make and Makefiles|make and Commands** Implied rules (e.g., .o files)** Examples* Building software from a source tarball using a makefileMakefiles]]
=== RPM Packages ===
* Purpose* What's in an RPM package fileDifferences between managing RPMS and Installing from Source** MetadataRPMS provide a database of installed software*** What the package providesLet you determine what's installed*** DependenciesAutomatic management of dependencies*** Packager, date, license, summary, description, ...** Digital signature** Software** Data*** Fonts*** Icons*** Sample data** Documentation** Configuration Identify the origin of files** Setup scripts*** Pre-installPermit easy update or removal*** Post-installEnable you to verify installation (useful for spotting file corruption and intrusions)*** Pre-uninstall*** Post-uninstall*** Triggers[[RPM Package Contents|Contents of an RPM Package]]
=== The RPM Database ===
* Purpose of the database
* [[RPM Queries|Querying the RPM database]]
** rpm -q
 
=== Creating Packages ===
* Packaging scenarios
* Setting up a Packaging Environment
** Needed packages
*** rpm-build
*** rpmdevtools
*** rpmlint
*** yum-utils
** Setting up the RPM tree
*** run <code>rpmdev-setuptree</code>
* Taking a look at existing source RPMS (useful as examples)
** Installing
*** <code>yumdownloader --source <i>nameofpackage</i></code>
*** <code>rpm -i <i>nameofpackage</i>.src.rpm</code>
*** Source will be in ~/rpmbuild/SOURCES and specfile will be in ~/rpmbuild/SPECS
** Examine the specfile
** Rebuild on the local machine -- takes a source RPM (SRPM) as input, produces binary and source RPMs as output
*** <code>rpmbuild --rebuild <i>nameofpackage</i>.src.rpm</code>
** Building from the spec file -- takes a specfile and source code as input, produces binary and source RPMs as output
*** <code>cd ~/rpmbuild/SPECS; rpmbuild -ba <i>nameofpackage</i>.spec</code>
 
=== Writing a specfile ===
 
* Run <code>rpmdev-newspec ''packagename''</code> in ~/rpmbuild/SPECS
* Edit the skeleton specfile.
* Test it: <code>rpmbuild -ba ''packagename''.spec</code>
** If successful, output will be binary RPM(s) in ~/rpmbuild/RPMS and source RPM in ~/rpmbuild/SRPMS
*** Can install binary RPM with: <code>rpm -i ''rpmname''</code>
** If unsuccessful, read the error messages carefully.
* Check it with rpmlint: <code>rpmlint ''packagename''*</code>
** Remember to check the spec file as well as the binary and source RPMs.
** Correct any errors found.
=== Layout of a specfile ===
* Basic Sections# preamble - basic metadata# %prep - commands to prepare the package for building# %build - commands to build the package# %install - commands to install the built files# %check - commands to check/test the built files (optional, often not included)# %clean - commands to clean up the disk space# %files - list [[Contents of files to be included in the pacakge# %changelog - record of the package's change-history* Scriptlets** %pre -- run before installation** %post -- run after installation** %preun -- run before uninstallation** %postun -- run after uninstallation*** Note that during upgrade, the installation of the new package is considered to happen before the removal of the old package.* Macros** %{_tmppath}** %{buildroot}** %{_bindir}** %{_datadir}** %{_mandir}** %{_smp_flags}** %setup** %configure** %makeinstallan RPM spec file]]
=== rpmlint: Checking for a clean spec file, SRPM, and RPM Creating Packages === <code>rpmlint</code> is a spec file, SRPM (.src.rpm), and RPM (.rpm) checker. To use it, supply the names of the file(s) to be checked as argument(s):  rpmlint ''foo.spec foo*.rpm''
Notice that the checks performed vary based on the input file. For example, some errors in the spec file (such as the summary ending in a period ".") could be determined from the spec file, but only show up when the SRPM/* [[RPM is checked. Each run will report the number of errors and warnings; errors are serious problems which should not be ignored, while warnings may be ignored depending on the context.Packaging Process]]
=== Demo: Creating a Simple Package ===
* Writing the specfile
* Testing the specfile
** Using rpmlint
=== Resources ===
By '''Monday, January 17''':
# [[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]].
= Week 2 (January 17) - Using Mock and Koji =
== Tuesday ==
=== mock: Testing BuildRequires Project Selection ===
It's often difficult 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 get you.** Do some initial research into what the BuildRequires project involves.*** Find out who to talk to in a spec file exactly rightthe 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, because itthe upstream project's easy 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 overlook packages the instructions at the top of that are coincidentally installed 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 machine. <code>mock</code> is [[Winter 2011 SBR600 Participants|participants page]] to a tool that uses page of the chroot system call same name to create a "cleanroom" environment for project page. Copy the build, so that any missing BuildRequires cause contents of the build [[Sample Project]] page to failyour project page and fill in the details.
{{Admon/note|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'mock''' Group|To use mock, not just research, and must be done in consultation with the community.** Release 0.2: Initial working state - Whatever you will need to add yourself 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 '''mock''' group: <code>usermod -G mock 'Thursday, February 3'yourUserName''</code>}}.
To build with mock:=== ToDo ===
mock * Finish [[SBR600 RPM-r Writing Lab|building your two RPMs]] before Thursday's class (we'fedora-13-x86_64'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--rebuild ''foo*.src3 possibilities.rpm''
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).== Thursday ==
== 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 [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=== Resources ===* mock** [[:fedora:Projects/noteMock|Koji SetupMock Project page]]** [[:fedora:Using_Mock_to_test_package_builds|Note that Using Mock to test package builds]]* koji requires some setup, particularly for certificate-based authentication. See the ** [[:fedora:PackageMaintainers/UsingKoji|UsingKojiUsing Koji]] 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):=== ToDo ===
koji build ''dist-f14'' --scratch ''foo*.src.rpm''[[SBR600 Mock and Koji Lab|Mock and Koji Lab]]
In this example, ''dist-f14'' selects the package repository = Week 3 (similar to the <code>-r</code> option for mock, except that the build arch is not specifiedJanuary 24); <code>--scratch</code> specifies that this is a scratch build (the results are not kept or fed to Bodhi).Solving Build Issues =
To perform a build that will be passed to Bodhi for distribution, substitute <code>--rebuild</code> for <code>--scratch</code> = Week 4 (do not do this until you have passed the package review and sponsor proceduresJanuary 31).- Project Plan Presentations =
{{Admon/note|ARM Build|You can queue an ARM build by specifying the server "arm.koji.fedoraproject.org" on the Koji command line (or in <code>/etc/koji.conf</code>).}}== Tuesday ==
== Resources ==* mock** [[:fedora:Projects/Mock|Mock Project page]]** [[:fedora:Using_Mock_to_test_package_builds]]* koji** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]''Class is cancelled. Recover from FUDCon and work on your project plan.''
== ToDo Thursday ==
* Test your RPM from last week with:Project pages are due.** rpmlint** mock** kojiBe prepared to give a detailed but brief (3- to 5-minute presentation) on your project plan.
* Blog about your experience. = Week 3 5 (January 24) - Solving Build Issues =  = Week 4 (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 =
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/wiki/Special:MobileDiff/54083...62401"