Christian Faulhammer

Arch work consists of many boring tasks, but nonetheless all architecture teams are the last stand of Gentoo's QA. The testing branch is messed up quite regularly, so transmission to the stable branch has to be done in a way that is the least annoying for users. Seldom there are tree-wide problems that affect a great share of users, mostly some minor packages are broken for a short while, but I think arch teams don't let it slip too often. All success is based on the effort of some really dedicated people, some of them burn-out because they cared too much. Anyway, I wanted to talk about the boring part. What are the tasks of an arch dev?

1. emerge the package with different USE flags
2. emerge packages that depend on the tested ebuild to make sure they still work
3. test the package in all incarnations
4. stabilise the package in the Portage tree
5. announce it on the stabilisation bug and remove the arch team from the cc field

Tasks 1, 2, 4 and 5 can be automated, while 3 needs some experience and brain-work. Arch testers ease the testing part and are of great value...x86 is underequipped in that regard currently. Many devs have their own scripts that work as they are used to do it, but in general there is no all-purpose tool widely used. For more than a year though x86 arch tester Matthias Langer (mlangc on IRC) has been working on the Gentoo Arch Testing Tool (Gatt) which comes in very handy at least in phase 2 and will extend to phase 4 and 5 in the near future.

First a quote from the README:

      "gatt is still under heavy development and may therefore contain
      nasty bugs.  Please make backups of "/etc/make.conf" and
      "/etc/portage/*" before you start working with the tool. You
      have been warned!"

Second: This is just a primer and no extensive tutorial, so explore some possibilities yourself as documentation is a bit sparse (but this will hopefully change soon). Don't hesitate to ask mlangc, pylon or myself.

Currently Gatt only is available as a live SVN ebuild, so unmask app-portage/gatt-svn, and emerge it.

What does it have at the moment? Given a bug number, Gatt determines which package to stable, so the summary line needs to have package atoms in the format category/packagename-version, which most have, security bugs are an accepted exception here. If the summary line is not understandable you are free to give a number of package atoms on the command line, so

      gatt --work-on 123456 app-editors/emacs-22.1-r1 

will add that package to your package.keywords file plus all dependencies needed to emerge. It then calls Portage with FEATURES="collision-protect test" (and multilib-strict on some arches) and lets you confirm the to be emerged packages. Preceeding the command with USE="blah -blubb" has the expected effects on the emerge process, though it won't make it permanent. A limitation is at the moment that you can only run one instance of Gatt at a time, as both will modify package.keywords and could conflict. This is being worked on. Calling the same command after an succesful emerge will remerge the desired packages.

Gatt will add some additional information to package.keywords so it can easily find its entries. They may look like the following

      ###### for bug 193095 {
      ## attribute: uninstall
      =net-libs/opal-2.2.11
      ## attribute: keep
      =dev-libs/pwlib-1.10.10-r1
      ## attribute: uninstall
      =net-im/ekiga-2.0.11
      ## attribute: uninstall
      =net-libs/opal-2.2.6
      ###### }

Normally every entry has an assigned bug number with a subsequent list of packages dedicated to that bug (dependencies, extra arguments on the command line), grouped by braces. All keywords for Gatt are masked with two or more comment signs so Portage will not be disturbed by it. The attribute is determined by the status of the package when Gatt is called: Packages that are new to the system will be removed on clean-up (attribute: uninstall), updates to already existing packages are kept (attribute: keep).

You can clean-up afterwards by

      gatt --resolve 123456 

and

      gatt --clean 

The --resolve option only marks it to be cleaned if the packages needed by that bug number are really stable in the official tree (sync!). --clean will remove them.

The real power comes from Gatt's ability to create scripts that will do tasks based on the bug you worked on. Until now this is not really used, but pylon and myself work on a script that will easily do phase 4 and 5 with a lot of tweaks to determine what to actually do to an ebuild (keywording, stabilisation etc.). As this could cause a lot of harm, we won't let people use it too early.

You have a template that is a normal shell script (stored in /tmp/gatt/ e.g.) but with additional variables from Gatt, that are filled with the appropriate value when calling 

      gatt --resolve 123456 --script-from test.template \
            --script-dest-dir /tmp/gatt/

In your template you set the GATT_* variables to a fixed value you need/choose or you tell it to be gatt-define, so they will be filled by Gatt.

Available are:

• GATT_SCRIPT_TYPE: Tells Gatt what type of template it is, this is fixed to post-resolve at the moment. This makes sure the right kind of script template is called with the correct action.
• GATT_ARCH: The architecture we are on.
• GATT_BUG_NUMBER: The bug number that was given.
• GATT_CATEGORY: Category of the package.
• GATT_PN: Name of the package without version number.
• GATT_PV: Version number without revision.
• GATT_PR: Revision number (even -r0 is explicitly set!).
• GATT_CURRENT_MASK: Tells you if this ebuild had ~arch or no KEYWORD for your arch at all.
• GATT_NUM_SCRIPTS: Number of scripts that have been generated.
• GATT_SCRIPT_ID: Current position in the script "chain".

The last two are important as for every package that has been pulled from ~arch to stable gets an own script with a master script that calls all those individual ones. SCRIPT_ID and NUM_SCRIPTS allow us to deterime at which position of the script chain we are: At the beginning, in the middle or at its end.

A simple template could look like this, which is inspired by the stabilisation template that is currently in the works. The latter will handle special cases (security bugs, keywording, ask for confirmation on crucial steps, modify the bug accordingly, nicer output of messages, more information on stdout). This means: DON'T USE THE FOLLOWING TEMPLATE TO DO REAL WORK OR EXTEND IT FOR YOUR NEEDS! If you are interested, contact either pylon or me and help us with it.

See the template in action in a little (about 14MB) Theora video.

#!/bin/bash

GATT_SCRIPT_TYPE="post-resolve"
GATT_ARCH=""
GATT_BUG_NUMBER=""
GATT_CATEGORY=""
GATT_PN=""
GATT_PV=""
GATT_PR=""
GATT_CURRENT_MASK=""
GATT_SCRIPT_ID=""
GATT_NUM_SCRIPTS=""

PORTDIR=/home/user/gentoo-cvs/gentoo-x86/

# Enter the CVS directory
cd "${PORTDIR}/${GATT_CATEGORY}/${GATT_PN}"
cvs update

# Revision 0 needs special handling to build the ebuild's file name
if [[ "${GATT_PR}" == "r0" ]]; then
    EBUILDNAME=${GATT_PN}-${GATT_PV}.ebuild
else 
       EBUILDNAME=${GATT_PN}-${GATT_PV}-${GATT_PR}.ebuild
fi

# Stabilisation
ekeyword ${GATT_ARCH} ${EBUILDNAME}

# ChangeLog entry
echangelog "stable ${GATT_ARCH}, bug ${GATT_BUG_NUMBER}"

repoman scan

# No commit, that's too dangerous at the moment
#

# we are in the last script so write a log file
if [[ ${GATT_SCRIPT_ID} -eq ${GATT_NUM_SCRIPTS} ]]; then
   echo "Done with ${GATT_BUG_NUMBER}" >> /var/log/gatt.log
fi

< Zurück		Weiter >