Hi, The CASHTest failure is interesting. Can you share the log? The others are all time dependent. CASH could depend on random, but the tests would all try to fix random seeding.
On Wed, Mar 8, 2017 at 6:57 PM, Santiago Vila <sanv...@unex.es> wrote: > On Wed, Mar 08, 2017 at 06:13:34PM +0100, Erich Schubert wrote: > > > Or you just add* e.g. the -*Dmaven.test.skip=true parameter, and it will > > build fine. > > That would be the easy thing, indeed, but not necessarily the right > thing to do. > > This is really a decision to be made by the maintainer: Either the > tests fail because they are wrongly designed (in which case they > should be disabled to fix the FTBFS bug) or the tests are ok and the > fact that they fail means the package is not suitable to be released. > > Only in the first case we want to disable the tests. In the second > case what we want is to keep the package out of testing. > > For the record, this is the number of times I've seen each test to > fail in my environment: > > 201 de.lmu.ifi.dbs.elki.utilities.datastructures.arrays. > IntegerArrayQuickSortTest > 48 de.lmu.ifi.dbs.elki.database.SortingDuplicatesTest > 25 de.lmu.ifi.dbs.elki.utilities.datastructures.arrays. > DoubleIntegerArrayQuickSortTest > 1 de.lmu.ifi.dbs.elki.utilities.datastructures.heap. > IntegerMinHeapPerformanceTest > 1 de.lmu.ifi.dbs.elki.algorithm.clustering.correlation.CASHTest > > I guess disabling the first three would make the failure rate to > improve dramatically, but as I said before I don't really know if they > fail because the program is wrong or because the tests are wrong. > > As much as I would like to investigate and help everybody to fix their > FTBFS-randomly bugs, there are too much of them and I can't fix all > the bugs I report myself. This is your package, not mine. In either > case, if you still need help to reproduce the bug, please say so, > but this one does not seem particularly difficult to reproduce. > > Thanks. >
