Маша Глухова: > I can switch between being able/unable to reproduce this bug by just doing > git checkout 64/65, without touching any dependencies. git-bisect, with > test being running build 100 times, points me to the > commit 0c3c88fc930f3755e6f4fb0879783e2585863e85 as the first one after > which builds do not fail anymore. Manual testing confirms as much: I am > able to reproduce the bug before, but not after, said commit. > I am not sure what to make of it: the commit does not seem like it might > cause significant change. > I could also add that the bug does not seem to be connected with virual > machines or number of CPUs. I reproduced it both on 1-CPU KVM/QEMU and real > system (on two different computers with different numbers of CPUs). > Hope that information would provide someone with some insight.
Santiago Vila: > I have built version 66 one hundred times in unstable. > The builds were made on 19 different autobuilders. > The number of failed builds has been zero. > (Previously it failed 10% of the time). I've uploaded version 67 with that commit reverted: https://people.debian.org/~infinity0/apt/pool/main/d/diffoscope/ Would be good if you people could test it to see if the test failures appear again. I agree it's unlikely that this commit is the direct cause, but it's possible that it is interacting with some lower-level stuff that either hides or reveals the bad behaviour. So the bug is probably still present, just hidden. In which case we should still keep a record of it. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds