On Sat, May 7, 2016 at 2:46 PM, Andreas Beckmann <a...@debian.org> wrote: > On 2016-05-07 12:17, László Böszörményi (GCS) wrote: >> Sorry for the slow reaction. The FTBFS reason is the package test >> case. It's threaded and the sequence is confused by the file timestamp >> resolution of Hurd and kFreeBSD architectures. It's one second only >> (Linux has millisecond resolution). >> Question is, how should it be handled? Disable self-tests, ignore the >> results or maybe remove mongodb from the mentioned architectures? > > Does mongodb run reliably on filesystems with second resolution? Or will > it cause problems like in this test? > If the package is usable on !linux, maybe disabling just that > problematic test could work. Otherwise I'd recommend partial removal. I can't directly answer this question; I don't use kFreeBSD nor Hurd. While I don't know how many users do that, I've never had a bugreport indicating it may have any problem on these architectures. Upstream do _not_ list any of these in their supported platforms page[1] nor say it doesn't work. :) But I've already experienced this kind of FTBFS problem with an other package. That's a small one and doesn't handle too much data - it's not multithreaded in writing those. Could workaround the build situation and it is (and was always) worked correctly.
I may look into the tests, but please don't take my word on it. I just wonder if Hurd and/or kFreeBSD will have a filesystem in the near future with more granular timestamp support or not. Regards, Laszlo/GCS [1] https://docs.mongodb.com/v3.0/installation/
