Download Documentation FAQ
Site Navigation:

How to do QA on Fedora Legacy packages

Please introduce yourself

Being connected only through an anonymous network, it is important for us to get known to you. If you haven't done so yet, please post a self-introduction to fedora-legacy-devel. The SelfIntroduction page on the fedora.us wiki should give you an idea on what we want to know. You are required to include a GnuPG key to enable us to check your signatures on packages that should be published.

Do we have different requirements on the self-introduction?

QA Checklist

This part is shamely ripped off the according fedora.us wiki page. We should use it as a starting point and modify it for our needs, as Fedora Legacy has different (and possibly fewer) requirements than fedora.us packages. As a start, I left all items in their original state and just added comments. Changes to the list entries will be made after some feedback. Please give feedback on list entries that you can comment on. Include the entry number for reference, so updating or deleting an entry is easy. You don't need to comment on all entries, just on the ones you have something to say about. I will take care on updating the specified entries.

This is a checklist of things to check for within a SRPM during Quality Assurance testing of Fedora packages. Please add items, rewrite sections, and reorganize to complete and improve this document.

  1. Does the package follow the Fedora Package Naming Guidelines? I don't think this makes sense for Fedora Legacy as we never publish newly created packages and thus only take the naming of the original package.

  2. Are the sources from upstream pristine and free from trojans? This should be checked for Fedora Legacy packages as well

    • Whenever possible verify GPG signatures, or even ask the upstream developers themselves to confirm the integrity of sources.
    • Another good source is to look within SRPMS of other distributions.

  3. Are the pre- and post(un)install scripts correct? These might have changed through the update; let's keep this check

    • If it installs files named **.so.* into %{_libdir}, is there a %post -p /sbin/ldconfig and %postun -p /sbin/ldconfig?
    • If it has info files, is there a %post script that installs them, and a %postun one which removes them (and only on erase, not upgrade)?

  4. Epoch I don't yet understand this whole epoch thing. Can anyone make clear if and how this is relevant to Fedora Legacy packages?

    • can be optionally defined "0" or omitted entirely. Exception: Never add Epoch to Red Hat updated packages.Does that mean we should always leave Epoch alone?
    • Whenever you have a "Requires", "BuildRequires", "Provides", "Obsoletes", "Conflicts" or "BuildConflicts" that needs a specific version of another package, always have the epoch before the version separated with a colon.
    • See http://www.fedora.us/pipermail/fedora-devel/2003-March/000651.html for more info.
  5. Did you check for missing BuildRequires using HOWTOFindMissingBuildRequires? We should have a strong eye on BuildRequires, judging from this posting!
  6. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS. Relevant for update-only packages?
  7. Are all paths within the .spec replaced with macros? Relevant for update-only packages? Maybe, if bigger changes to the specfile have been made.

  8. If the package has a DesktopEntry, are the VFolder categories ok? Relevant for update-only packages?

    • See FedoraDesktopEntryGuidelines
    • When the .spec uses desktop-file-install for to install menu entries, do not forget "BuildRequires: desktop-file-utils"
  9. Does the package have any %{buildroot} macros? If so, they should be replaced with $RPM_BUILD_ROOT. Ditto for %{optflags} -> $RPM_OPT_FLAGS. For more info, see http://www.fedora.us/pipermail/fedora-devel/2003-April/001155.html. Relevant for update-only packages?
  10. Does the package install any unowned directories? Read the thread at http://www.fedora.us/pipermail/fedora-devel/2003-June/001458.html for details. Relevant for update-only packages? I only expect directory changes when a package is upgraded by version instead of getting patched.
  11. Use License rather than Copyright. Relevant for update-only packages?
  12. Does the package ship with default passwords? Such passwords are treated as packaging-errors; see the thread at http://www.fedora.us/pipermail/fedora-devel/2003-August/001847.html for details. Relevant for update-only packages? I only expect default passwords being introduced when a package is upgraded by version instead of getting patched.
  13. Does the package ship daemons or similar programs which support execution as non-root? It is a packaging-error when the daemon runs as root, or as a standard user like nobody. Instead of, a special user must be used; see the discussion at http://www.fedora.us/pipermail/fedora-devel/2003-June/001492.html for details. Relevant for update-only packages? I only expect changes to this issue when a package is upgraded by version instead of getting patched.
  14. Parallel makes using -jX generally speed up builds, especially on SMP machines. This is correctly accomplished by using make %{?_smp_mflags} in specfiles. However, not all packages are parallel build clean. To catch some of these errors, packagers and QA folks may want to add eg. %_smp_mflags -j3 to ~/.rpmmacros, even if they use UP machines. Relevant for update-only packages?
  15. A suggestion from Warren: "Another good test is using ldd and compare the output of the binaries in RH's package and Legacy's package. It is entirely possible that Legacy's binary in updates-testing could be missing functionality since BuildRequires are missing."
  16. Add checklist item here Do you have any additional suggestions that might be specific for Fedora Legacy?

When you're done...

Please add your QA approval to the according Bugzilla entry. An example comment for a simple package might be "name-version-release works for me on RH7.3 after 1 hour of functionality testing. I also verified that the binary ldd output matches RH's package". Other packages that ship more complex software need more detailed feedback. Your approval has to be clearsigned with your GPG key so we can make sure that nobody can fake-approve packages that contain errors. There's a temporary HOWTO on GPG message signing that will help you if you don't know how to clearsign your message.

What happens next? This page tells that it is the QA tester that removes the QA keyword and sets the PUBLISH keyword. Shouldn't this be done by another person?