Christian Faulhammer <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 05 Sep 2008 21:47:59 +0200:
>> 2) Should I file stabilization requests on software that works mostly >> as in everything that I use it for normally but I can force it to fail >> if I feed it some really strange input or contrive a specific set of >> options that will cause invalid or incorrect output. > > Try to sort it out with upstream (original package author). Depends > on the problem, if an older stable version shows the same behavior it > should be no show-stopper. Also, consider merging with FEATURES=test and the test USE flag if appropriate as well. If a package fails its tests and doesn't have RESTRICT=test turned on in the ebuild, and if the previous version passed the tests, it's not likely to be stabilized. If the previous version failed the tests as well, for everyone, then in theory, RESTRICT=test should be on, and the fact that it isn't indicates a problem with your specific installation (either of that package or something else). However, theory doesn't always match reality as I'm sure you've observed by now. In any case, it's certainly worth checking for stabilization bugs for previous versions and seeing what the comments on testing were for them, then either exploring the problem locally or filing a bug as appropriate. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
