On Tue, 19 Jul 2016, Sylvestre Ledru wrote: > The four are caused by the same issue: a test freezes. > Having the name of the test would be super helpful so that we can report > a bug upstream to fix it.
I fully agree, and I'd love to provide the test which fails, but the build process is completely silent about the tests. In fact, back in March I wrote this in this bugreport: > please do not hide output while the tests are running! We want to know > what's happening! Any progress on that? Do you need another different bug report for that? Or maybe would it be helpful if we consider *this* bug report the one about the build process being silent, so that I only report the bug about build failing when we know the test which fails? Please tell what do you think. > However, I don't agree with the severity. > I never experienced such issues on the official build infra ( > https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8 ) > or the upstream CI: http://llvm-jenkins.debian.net/ Well, if I can't build the program, then I can't modify it. If I can't modify it, the program is non-free for me, for all practical purposes. Would this not deserve "important" severity at least? Also, the theory that a package needs to FTBFS in the official autobuilder for a bug to be serious has its flaws: Imagine a package which rolls a dice and decides to fail according to the result, then the fact that it builds ok in the official autobuilder just means we were lucky that time, not that the package is ok. Package building should be deterministic, not something which happens only in the official autobuilders by chance. The previous example is not just a mental experiment. I have found some packages which fail randomly in the past: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817033 Thanks.
