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


TINDERBOX:

It compiles the entire portage tree against a particular change like:
– a new GCC version
– a new LDFLAG
– a different toolchain
– and so on

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

CI:

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) Because of the first, I don’t know if additional files are needed (e.g. test-suite.log testlog.txt CMakeOutput.log CMakeError.log LastTest.log config.log testsuite.log autoconf.out). So if you need anything 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 end 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 YY:MM:DD”

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:
TBD

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
TBD

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:
TBD

10) Deprecated configure.in:
TBD

11) .Desktop do not pass validation:
TBD

12) Path that should be created at runtime:
TBD

13) Libraries that lack NEEDED entries:
TBD

14) Libraries that lack a SONAME:
TBD

15) Text relocation:
TBD

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

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

18) Files with broken symlink:
TBD

19) Command that do not exist:
TBD

20) Pkg-config files with wrong LDFLAGS:
TBD

21) Pre-stripped files:
TBD

22) File collision:
TBD

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

24) Compile failure with -fno-common:
TBD

25) Files with unresolved SONAME dependencies:
TBD

26) Files that contain insecure RUNPATHs:
TBD

27) Files installed into unexpected paths:
TBD

28) LD usage instead of CC/CXX:
TBD

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

30) Compilation in src_install phase:
TBD

31) Automake usage in maintainer-mode:
TBD

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

33) Broken png files installed:
TBD

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

35) Udev rules installed into wrong directory:
TBD

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.