Hi. Any progress on this? This is still reproducible. I'm attaching a build log for the version which has just entered testing.
On Sun, 17 Apr 2016, Balint Reczey wrote: > It suggests there is something wrong with the mutex handling and TSAN seems > to confirm that: > [...] > I need to test if the problem still exists in upstream master and verify if > it is not a false positive TSAN warning and the root cause is indeed here. Could you translate that into a language that a non-programmer could understand? > I'm setting the bug's severity to normal because while it is reproducible > the FTBFS does not happen on Debian's buildds [...] Hmm. I'm not going to enter into a severity war, but you should be aware that the theory that a FTBFS is not RC because "it does not happen" in Debian's buildds has many flaws. For example, for a package which FTBFS randomly, it is completely useless, as a successful build just means that we were lucky that time. We should better not care too much about what happened in the autobuilders the last time it was tried, we should care more about what could happen the next time. I'm using sbuild and the autobuilders are using sbuild as well (or a variant of it). If you think this may not happen in official autobuilders, could you please explain why? (Because my machine does not have enough memory? How would I know that in advance when we don't have a Build-Memory control field?) > thus does not prevent rebuilding the package when needed. It does prevent me from rebuilding the package, which makes the software non-free for me and apparently anybody who does not have a machine with 32 GB of RAM (which is still a lot of people). I would say that would deserve important severity at least. (I said 32 GB just as an example, but if that's a more or less accurate summary of this bug, I'd like to know the exact figure). Thanks.
kodi_16.1+dfsg1-2_amd64-20160824T064358Z.gz
Description: application/gzip
