So while I haven’t yet found my current reason to I still am working on the tinderbox, and today I followed up reporting more and more bugs for the build failures I found. Unfortunately I’ve also started considering a few problems with the tinderbox, which I need to find a solution somehow:
- the amount of logs that it produces is unmanageable especially now that tests are enabled; I’m waiting for Mark hoping he can get my old log analyzer to a point where it works, so that can be used to identify non-fatal issues (pre-stripped files, ignored flags, and so on);
- the amount of data in my distfiles cache continues to increase; I don’t often clean up the old cruft I admit that, but it sometimes come useful; on the other hand this is really adding lots of data on my system which is already tight on free space (until I can find a damn eSATA controller, that is);
- some test suites do check software for validity to a point that it sounds silly, like the intltool-based packages failing
make checkbecause of files, with translations, not being indexed; this would be a task formake distcheck! - using the test feature I can find even more
--as-neededfailures since most ebuilds installing only libraries have tests that do link against them; which means that it stops much sooner! - all in all though there aren’t so many tests failing.. or so many tests at all, lots of software does not have anything at all;
- identifying failures due to gcc 4.3 and failures due to gcc 4.4 is extremely fun because often enough they just drop down to “foobar not declared in this scope” for C++ code;
- the glibc 2.10 failures are not extremely difficult to identify at least, but there are lots, and in the strangest places of all, like in binutils’s testsuite;
- there are so many strange failures for “leaf” software (that is software that is not dependency of anything else) that I’ve been calling treecleaners quite a few times, to see if it’s easier just to slim down the tree;
- I don’t think I can use tmpfs for now at least; turns out the Xorg crashes I was giving compiz the fault of are due to the free ATI driver not being able to allocate 64k of contiguous memory, that’s why they only happened under heavy heavy load (like… a tinderbox running); if I were to eat more memory out by using tmpfs I guess I’d say goodbye to using X on this system… I guess it could be an option for me to get a thin client though;
- I could use a bit of motivation boost with ohloh kudos if you wish…
Back to work I guess, just 10k more packages to go!
You *are* crazy 🙂
Great to see this effort to improve the tree. I would think that cleaning up some of those “leafs” really helps to reduce the amount of bugs that nobody has time/motivation to look at.Personally I find the amount of failing test-suites quite considerable. Especially as there appears to be no really good way to skip them with portage even if you know it’s bogus (or already reported). Failing test-suites are simply not very high on the list of bugs getting fixed is my experience (even when patch and/or fix is known).
Uh? Do you think I stop for each package that fails tests? ;)@FEATURES=test-fail-continue@ executes the tests and keep going even if they fail; it’s not perfect but it’s good enough, for what I do.
I got that point….I just meant to say that “normal” users that run with tests enabled have no way of skipping failing test-suites as I assume the “FEATURES=test-fail-continue” would still merge the package even when it fails its testsuite indicating that potentially the built went wrong. I did like the approach Paludis was using, but never found an easy way to skip known test-suite failures in portage.*) above is particularly annoying hitting the same testsuite again for the xx-time with the fix and/or problem already been reported in bugzilla.
Ah per la cronaca, il tuo lavoro come al solito è eccellente! 🙂 dovrebbero clonarti. (ah no è vero, in Italia non si può dire, altrimenti il papa ti chiude il blog!)