This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.

Please visit our production wiki at https://wiki.gentoo.org

Package testing

From Gentoo Wiki (test)
Jump to:navigation Jump to:search

Like all healthy software projects, developing Gentoo requires lots of testing. This article provides information for ebuild developers on testing ebuilds.

It is preferred that ebuild testing takes place on a real system, inside a chroot, or within another type of non-virtualized container. Virtualization may be acceptable in situations where it is not possible or practical to test on real hardware.

The test environment must only have stable packages installed, with no unstable ebuilds present (keyworded or unmasked). The test environment should be up-to-date, and it is recommended to have as few packages installed as possible. This will aid in finding missing dependencies.

Configuration

make.conf

 As of feb 2, 2018, the information in this Section is probably outdated. You can help the Gentoo community by verifying and updating this Section.

The make.conf file should have settings similar to the following:

Note
-Wl,--hash-style=gnu no longer works because it's set by default starting with sys-apps/binutils 2.23.51.0.9 . See Bug 455232
FILE /etc/portage/make.conf
# CFLAGS should be reasonable
CFLAGS="-march=native -O2 -pipe -frecord-gcc-switches"
CXXFLAGS="${CFLAGS}"

# Defining all four *FLAGS variables enables a portage QA check reporting when these variables are not respected
FFLAGS="${CFLAGS}"
FCFLAGS="${CFLAGS}"

# Enables a Portage QA check to report when LDFLAGS is not respected
LDFLAGS="${LDFLAGS} -Wl,--defsym=__gentoo_check_ldflags__=0"

# collision-protect - prevent a package from overwriting files it does not own
# ipc-sandbox - prevent host IPC access (requires Linux and namespace support in kernel)
# network-sandbox - prevent network access during merge (requires Linux and network namespace support in kernel)
# sandbox - ensure package does not write directly to live system
# split-log - store logs created by PORTAGE_ELOG_SYSTEM="save" in category subdirectories
# split-elog - store build logs in category subdirectories
# strict - have portage react strongly to conditions that have the potential to be dangerous
# test - run package tests, or alternatively test-fail-continue
# userfetch - drop privileges during fetching
# userpriv - drop privileges during merge
# usersandbox - enable sandbox when userpriv is enabled
FEATURES="collision-protect ipc-sandbox network-sandbox sandbox split-log split-elog strict test userfetch userpriv usersandbox"

# Display selected types of messages again when emerge exits, and save them to disk
PORTAGE_ELOG_CLASSES="log warn error qa"
PORTAGE_ELOG_SYSTEM="echo save"

Testing

Each ebuild in Gentoo is different and therefore requires a slightly different approach to stabilization. Consider the following guidelines for each class of package, and use common sense when in doubt.

General

USE flags

While it is preferable to test every USE flag combination, this is not always possible or appropriate. The ebuild may have a large number of USE flags, a long compile time, or the stabilization in question may just not call for it.

In cases where all USE flags combinations are not being tested, it is still recommended to test:

  • With all USE flags enabled.
  • With all USE flags disabled.
  • The default USE flag settings.

Runtime testing

Consider the level of runtime testing that is required for the target package. Remember, the focus of stabilization is to integrate a testing ebuild into stable and not to identify routine upstream bugs or regressions - that is the purpose of the ebuild's 30 day wait time in while it's marked ~ (unstable).

The level of runtime testing required will vary wildly based on a variety of factors. Consider the following examples:

  • Multiple days of "normal use" testing may be appropriate for a new version of sys-libs/glibc.
  • Basic functionality testing, such as browsing some web pages, may make sense for a new version of www-client/firefox.
  • Passing tests might be enough for dev-python/yenc.
  • A leaf package such as kde-apps/kcalc may not require any runtime testing at all.

Libraries

A new library version may introduce incompatibles with reverse dependencies. Where there is a risk of such breakage, each stable reverse dependency must be rebuilt. Beware of reverse dependencies that only use the library conditionally (eg. USE="png").

Kernel

Kernel ebuilds referenced in the Handbook have certain exemptions from the usual stabilization policy, so stabilization requests are normally only filed for the first version in a long term stable branch (subsequent versions can be stabilized at the discretion of the maintainer).

First, test all available kernel options:

user $cd /usr/src/example-sources-1.2.3
user $make allyesconfig
user $make # add '-j' as appropriate for the hardware

If that succeeds, build with a normal kernel configuration:

user $make distclean
user $make menuconfig
user $make
user $make modules_install # if you use modules

After reboot, check dmesg for anything strange and use the system as normal, trying to get a bit of uptime.

If stabilizing a special feature variant such as sys-kernel/hardened-sources, try to test relevant features.

Toolchain

New versions of toolchain packages can often introduce major changes and widespread breakage into the Gentoo ebuild repository. The purpose of a stabilization request for a toolchain package is to test the package itself on each architecture - not to detect build failures in miscellaneous packages. It is expected that such failures are managed and resolved by the maintainer (normally through tracker bugs and tinderboxing) prior to filing a stabilization request.

Once the normal testing is successful, rebuild @system (or @world if the hardware permits) and once successful, observe the system in normal operation for abnormalities.

Tools

getatoms

getatoms is a simple script to get a list of atoms from a stabilization bug. It's designed to feed atoms into another tool for processing, such as batch_stabilize.

tatt

app-portage/tatt is a tool designed to automate some of the repetitive tasks involved in arch testing. Currently only version 9999 supports working with a git ebuild repository and the Bugzilla atom field.

For each job, tatt produces a series of scripts allowing the user to control exactly what is performed:

Script name Function
cleanup Removes generated scripts and atoms from the keyword file
commit Commits the keyword changes to the repository
rdeps Compiles a selection of stable reverse dependencies
success Reports a successful stabilization to the bug, removing the arch from CC and closing if appropriate
useflags Builds the atoms with various USE flag combinations

Configuration

tatt has a variety of configuration options (see man 5 tatt), but there is a few that must be set to ensure useful operation of all functions.

FILE ~/.tatt
# architecture to use for keyword changes and bug updates
arch=amd64

# success message to print on bugs
successmessage=@@ARCH@@ stable

# repository to work in when committing keyword changes
repodir=/home/dev/gentoo

# API key to authenticate with bugzilla for updating/closing bugs
# generate at https://bugs.gentoo.org/userprefs.cgi?tab=apikey
bugzilla-key=XXX

Sample workflow

First, start a new job:

user $tatt -b 590118
Bugnumber:  590118
Stabilization bug detected.
Jobname: writerperfect
Found the following package atom : =app-text/writerperfect-0.9.5
=app-text/writerperfect-0.9.5 already in /etc/portage/package.keywords/archtest
No stable rdeps for writerperfect
Success Report script written to writerperfect-success.s
Commit script written to writerperfect-commit.sh

Now the various scripts are available for use:

user $ls
writerperfect-cleanup.sh  writerperfect-commit.sh  writerperfect-success.sh  writerperfect-useflags.sh

Next, build the package and perform whatever testing is necessary:

root #./writerperfect-useflags.sh
user $writerperfect

A report is also produced summarizing the build status of each USE flag combination:

user $cat writerperfect.report
USE='-abiword -cdr -ebook -freehand -gsf -keynote -mspub -mwaw -pagemaker -visio -wpd -wpg -wps' : REQUIRED_USE not satisfied (probably)                                                                           
USE='abiword cdr ebook -freehand gsf -keynote mspub mwaw pagemaker visio -wpd -wpg -wps'  succeeded for =app-text/writerperfect-0.9.5                                                                              
USE='abiword cdr ebook freehand gsf keynote mspub mwaw pagemaker visio wpd wpg wps'  succeeded for =app-text/writerperfect-0.9.5                                                                                   
 FEATURES= test succeeded for =app-text/writerperfect-0.9.5

Once everything looks good, commit the keyword change:

user $./writerperfect-commit.sh
writerperfect-0.9.5: amd64 ~x86 ~x86-linux ~x86-solaris

RepoMan scours the neighborhood...
RepoMan sez: "If everyone were like you, I'd be out of business!"

RepoMan scours the neighborhood...
>>> Creating Manifest for /home/michael/dev/gentoo/gentoo/app-text/writerperfect

Note: use --include-dev (-d) to check dependencies for 'dev' profiles


* 1 files being committed... 
[master fe834f9] app-text/writerperfect: amd64 stable
 1 file changed, 1 insertion(+), 1 deletion(-)

Commit complete.
RepoMan sez: "If everyone were like you, I'd be out of business!"

Finally, update the bug and cleanup the job:

user $./writerperfect-success.sh
user $./writerperfect-cleanup.sh

QA violations

Most of these violations will be detected automatically using the testing tool, but are also described here for completeness.

  • Does not respect the CC variable.
  • Does not respect CFLAGS variable.
  • Does not respect LDFLAGS variable.
  • Bundled symbols.
  • Insecure symbols.
  • Installs documentation outside of /usr/share/doc/${PF}
  • ELF files found in /usr/share

Architecture-specific notes

A number of items described in earlier sections, such as checking of reverse dependencies and miscellaneous QA checks, are architecture-neutral. At a stabilization level, the primary responsibility for carrying out these checks rests on the first architecture to stabilize an ebuild. Subsequent architectures may assume that these checks have been completed and skip them if they wish.

amd64

  • Any developer may perform amd64 stabilization - it is not necessary to be on the arch team.
  • multilib-strict must be added to the FEATURES variable in the make.conf file.

arm

The ARM project supports four arm variants - armv4, armv5, armv6, and armv7. In addition to regular testing, the package must be build tested on each variant. If access to each physical variant is not possible, CFLAGS="-march=$arch" is acceptable.

x86

  • Any developer may perform x86 stabilization - it is not necessary to be on the arch team.
  • It is acceptable to stabilize in an x86 chroot on amd64.
  • It is generally acceptable to stabilize a package with only a build test on x86 if it is already stable on amd64.

See also

  • Stable request - Instructions for how to make a stabilization request for an ebuild.

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Agostino Sarubbo (ago), various arch testing teams
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.

Retrieved from "https://wikitest.gentoo.org/index.php?title=Package_testing&oldid=746773"