gentoo tinderbox

If you are visiting this page, it is very likely that the software you maintain has been analyzed by my tinderbox system.

What is a tinderbox?

It is a machine that compiles 24/7 that aims to find build failures, test failures, QA issues and so on in the portage tree.
It can be differentiated into:

– tinderbox

– ci


It compiles the entire portage tree against a particular change like:
– a new version of compiler/libc/linker
– a new C/CXX/LD FLAG
– a different toolchain like clang/llvm/lld
– and so on

In short it uses uncommon but supported settings and looks for breakage.


It is a continuous integration; the CI system compiles the packages after they have been touched in gentoo.git

The CI system uses a standard set of settings, so if you get a bug report from it, it is very likely that the failure is reproducible for users too.

What are the rules that you may know when you see a report from those systems?

1) The reports are filed automatically.
2) Because of the first, it is not possible for me to set an exact error in the bug summary. Instead a general error is used.
3) Because of the above, maintainer is encouraged to set an appropriate summary at its convenience
4) Common additional logs (like test-suite.log testlog.txt CMakeOutput.log CMakeError.log LastTest.log config.log testsuite.log autoconf.out) are automatically attached but before of the first if you need something else please ask for them.
5) If you ask for another log, I have to stop the tinderbox service, so there may be a delay between your request and my reaction.
6) There may be an internal reference between round brackets on the “Discovered on” line. This is for me to understand where that failure was reproduced.
7) If you see ‘ci’ as internal reference after you pushed a fix, it is very probably that the bug still exist, or there is another failure in the same ebuild phase. Please inspect deeply the build log. Point 8 may help you about that.
8) At the beginning of the build log a git SHA of the repository at the time of emerging is provided. For convenience there is a link.
9) To avoid making a separate attachment on bugzilla, at the beginning of the build log there is the ’emerge –info’, please check it DEEPLY to understand the system configuration and what differs respect to a more ‘standard’ system.
10) If you see a compressed build log, is because the plain text version exceeds the limits on our bugzilla (1MB).
11) This system is not perfect. There may be duplicates or invalid bugs.
12) My best suggestion is try to reproduce the issue on empty stage3 (or docker for convenience).
13) When you close the bug with a resolution different from RESOLVED/FIXED please not be cryptic.
14) If new points will be added, there may be a mention like “Valid from YYYY:MM:DD”
15) Valid from 2021-01-10 If in the emerge history there are dev-lang/python-exec, sys-devel/gcc-config and sys-devel/binutils-config means a test with USE=”-native-symlinks” against the package.
16) Valid from 2021-05-04 At the begin of the build log, the commit SHA that causes the build is pointed
16) Valid from 2021-05-04 At the begin of the log there is also the list of installed packages (qlist –

How to fix the common errors:

1) Compile/build failure:
It depends on the error. Please get in touch with upstream if you are unsure.

2) Test failure:
It depends on the error. Please get in touch with upstream if you are unsure.

3) CFLAGS/LDFLAGS not respected:
You can touch the build system or inject the flags in the ebuild where possible. There are a lot of examples in the tracker.

4) -Wformat-security failure:

5) Metainfo installed in /usr/share/appdata:
Install metainfo into /usr/share instead of /usr/share/appdata

6) Python modules that are not byte-compiled

7) Unrecognized configure options:
Remove the configure options from the ebuild where possible. Sometimes there are false positives related to the option passed to configure in subdirectories.

8) Compressed manpages and documentation:
Decompress documentation and install it as plain text.

9) Icon cache not updated:

10) Deprecated

11) .Desktop do not pass validation:

12) Path that should be created at runtime:

13) Libraries that lack NEEDED entries:

14) Libraries that lack a SONAME:

15) Text relocation:

16) Toolchain binaries called directly (cc/gcc/g++/c++/nm/ar/ranlib/cpp/ld/strip/objcopy/objdump/size/as/strings/readelf and so on):

17) Files with name not encoded with UTF-8:

18) Files with broken symlink:

19) Command that do not exist:

20) Pkg-config files with wrong LDFLAGS:

21) Pre-stripped files:

22) File collision:

23) Compile failure if CPP is set to CC -E:

24) Compile failure with -fno-common:

25) Files with unresolved SONAME dependencies:

26) Files that contain insecure RUNPATHs:

27) Files installed into unexpected paths:

28) LD usage instead of CC/CXX:

29) Link failure with LLD because of /usr/lib:

30) Compilation in src_install phase:

31) Automake usage in maintainer-mode:

32) Mimeinfo cache not updated when .desktop files with MimeType are installed:

33) Broken png files installed:

34) Mime-info files installed without update mime-info cache:

35) Udev rules installed into wrong directory:

This entry was posted in arch testing, gentoo. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.