[[Category:SBR600]][[Category:Winter 2010 SBR600]]'''Please note:'''

= Week 2 (September 15January 18) - RPM Packages I =

* Listen to the [http://cdot.senecac.on.ca/audio/sbr600/ audio recording] of last semester's conference call with Jesse Keating, Fedora Release EnginEngineer * Take the software you compiled last week and package it (not Nled!). Blog about the experience. Include a link to your source RPM (and optionally your binary RPM) from your blog. '''Please complete this by Tuesday, January 26.''' = Week 3 (January 25) - Using Mock and Koji =  == rpmlint: Checking for a clean spec file, SRPM, and RPM == <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. == 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/note|The '''mock''' Group|To use mock, you will need to add yourself to the '''mock''' group.}} To build with mock:  mock -r ''fedora-12-x86_64'' --rebuild ''foo*.src.rpm'' The value ''fedora-12-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). == 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-f12'' --scratch '''foo*.src.rpm'' In this example, ''dist-f12'' 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). == Resources == * rpmlint** [[:fedora:Common Rpmlint issues]]* mock** [[:fedora:Projects/Mock|Mock Project page]]** [[:fedora:Using_Mock_to_test_package_builds]]* koji** [[:fedora:PackageMaintainers/UsingKoji|Using Koji]] == ToDo == * Test your RPM from last week with:** rpmlint** mock** koji

= Week 2 4 (January 18February 1) - Overview of the Build Using Mock and Release Processs Koji II =

  == Week 6 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 (February 15or 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 - Compositing -addsign <i>packagefile</i></code> == Creating a YUM repository === Week 7 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 (February 22the files can be served by putting them on a DVD too!) - Server Farms I . 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= Study Week (March 1) =</code> but comment out the <code>gpgkey</code> file.# Confirm that you cannot install from that repository using yum.= Week 8 (March 8) # Uncomment the <code>gpgkey</code> line, and point it to a new file within <code>/etc/pki/rpm- Server Farms II =gpg/</code>= Week 9 # Create that file by running (March 15as your regular user) : <code>gpg --export --armour <i>e-mail- Distributed Processing 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. == Week 10 (March 22) Repository- Virtualization 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. = Week 11 (March 29) - Monitoring & Management =ToDo = Week 12 (April 5) - Presentations = # 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 Weeks 6 - 13 (April 12) - Wrap-Up =* See the [[Fedora ARM Secondary Architecture]] project. = Exam Week (=* April 19) =23: [[Winter 2010 SBR600 Posters and Presentations]]