This page contains the text I would not like to repeat on each bug produced by the tinderbox.
What is a tinderbox?
Basically it is a machine that compiles 24/7. but I’d like to differentiate it in:
It compiles the entire portage tree against a particular change like:
– a new GCC version
– a new LDFLAG
– a different toolchain
– and so on
It is a continuous integration; it compiles the packages after they have been touched in gentoo.git
While the tinderbox uses strange settings to aims find breakages with non-default things, the ci uses a conservative and more standard set of settings.
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) 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.
8) 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.
9) If you see a compressed build log, is because the plain text version exceeds the limits on our bugzilla (1MB).
10) This system is not perfect. There may be duplicates or invalid bugs.
11) My best suggestion is try to reproduce the issue on empty stage3 (or docker for convenience).
12) When you close the bug with a resolution different from RESOLVED/FIXED please not be cryptic.
13) If new points will be added, there may be a mention like “Valid from YY:MM:DD”
These are not really rules and they do not need a number. However a number is assigned because sometimes I will redirect people here by asking to see point 100,101,102
100) Is Gentoo the system of choice if a cosmetic change breaks YOUR ebuild?
101) If you hate bugs, then you should do a bit of testing before your ebuild is in the tree
102) While you are closing the bug as INVALID with the attitude “I am the best in the world, if there is an error it is not mine” please ask yourself if it’s the right thing for you to be there 😉