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.

Reply via email to