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 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.
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) 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
out.
16) Valid from 2021-05-04 At the begin of the log there is also the list of installed packages (qlist –
ICvUSS)
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