On 21.11.2016 13:09, Santiago Vila wrote: > On Sat, 19 Nov 2016, Matthias Klose wrote: > >>> It's unlikely a hardware problem because the build was made in a >>> virtual machine and the build was tried twice. This is written >>> in the bug report itself. >>> >>> This is a lot more likely to be a bug which happens randomly, >>> for example, a bug in the Makefile. >>> >>> Such bugs *do* exist, just see >>> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841096 >>> >>> for a very simple example. >>> >>> >>> In this case, there is absolutely zero evidence that it's a hardware >>> problem and not a bug which happens randomly. >>> >>> Do you always close bugs which happen randomly just because you can't >>> reproduce them yourself, or can you acknowledge the fact that not all >>> packages either always build or always fail? >>> >>> (I can give a lot more examples of packages which fail to build >>> randomly if you are interested). >> >> it might not be "hardware" problem, but with all this "virtual overhead" a >> corruption with some file system or something else. Yes, I intend to close >> such >> bug reports, > > It's completely ok to close a report which happens because of hardware > problems. However, that's not the kind of randomness I was talking > about. > > I refer, for example, to randomness which happens when some Makefile > expect the output of "find" to be in a certain order. > > [ Please read the link I posted before ] > > There is no canonical order for the output of "find", so different > filesystem ordering does not mean the system is misconfigured or that > there is corruption in the filesystem. > >> because GCC itself retries to build these files, and apparently it >> succeeded to build it (or else you wouldn't see this message). That might >> be a >> real bug, but then GCC is the wrong package to file a bug report for. > > What would be the right package for a bug in one of GCC Makefiles, then? > > What if Lucas was able to reproduce this in two different machines and > the failure and the error message was the same? Would you discard > "filesystem corruption" as the "most likely reason" in such case? > > [ Or maybe you are claiming that GCC Makefiles are 100% bug-free and > absolutely perfect and any evidence in contrary *must* be an error? > I really hope that's not what you meant here. ]
what have Makefile errors to do with GCC ICEs? The gcc driver starts the compiler again and tries to reproduce it. Nothing to do with Makefiles.
