Apart from theory best learning is done by hands-on examples.
gatt --resolve 12345
gatt --use-desc nptlonly
gatt --work-on 12345
gatt --stat 12345
gatt --no-tests --work-on 12345 sys-devel/gcc-4.2.2-r12
gatt --work-on 12345 $(cat /tmp/packagelist)
gatt --give-me development dev-util/regexxer-0.9
gatt --drop development
gatt --clean unneeded
This describes the steps when an architecture developer wants to stable a package after the package's maintainer has filed a stabilisation request. Some more information about the used template can be found in Templates at the bottom.
Assumed the bug 999999 has the summary line "Please stabilise app-editors/emacs-30.1", you call
gatt --work-on 999999which extracts the package atom "=app-editors/emacs-30.1" and unmasks the package for the currently used architecture in your package.keywords file. Gatt lets you confirm the emerge run (skip it with the
--no-user-interaction option) and after that you test it extensively.
Being ready for transferring it to stable, you type
gatt --resolve 999999 --script-from keywords --script-dest-dir /tmp/gatt/ \ --template-script-dir /usr/share/gatt/templates/which considers the section for bug 999999 from package.keywords. Used as a template is the file keywords (
--script-from), found in the directory /usr/share/gatt/templates/post-resolve/ (
--resolveaction), while the resulting script(s) will be stored in /tmp/gatt/post-resolve/ (
--script-dest-dirtaking into regard
--resolve, too). All arguments (except the action) can be added to your .gattrc file. This template is really shipped with Gatt and usable, just by the way.
Assuming you worked with Gatt in a chrooted environment, you need to transfer the generated script to the machine you commit from. This can be either be achieved by exporting it over your network (NFS, SMB, whatever) or maybe sharing the /tmp/ directory on the same machine with chroot and normal system. So you go to the commit system, call the script by
/tmp/gatt/post-resolve/gatt_ps-999999 --bug-message "Gatt is great" \ --changelog "stable for us"and enjoy the fancy actions that are carried out automatically. Note that the parameters are only needed if you want to announce something special on the bug entry or in the ChangeLog file. The script chooses correct entries for Bugzilla and ChangeLog on its own. The script is heavily documented by comments and in this manual further up.
After that you go to your testing system again and let
gatt --clean unneededup the mess in package.keywords.