Hi Santiago, 2016-08-24 17:36 GMT+02:00 Santiago Vila <sanv...@unex.es>: > Hi. > > Any progress on this? This is still reproducible. I'm attaching a > build log for the version which has just entered testing.
I have uploaded a new version to experimental with two related changes. One is not failing the build when the test fails. This is not nice, but the tests were completely broken while kodi ran fine on my test system. The second is running the tests with Valgrind when it is installed to have better chance at finding allocation errors. I also proposed the change at upstream listing an error which could mess up mutex handling: https://github.com/xbmc/xbmc/pull/10334 > > 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. I'm trying to apply definitions from here: https://www.debian.org/Bugs/Developer#severities I don't like having this bug, but if a program fails to build 50% of the time but runs fine it can be released IMO since users are not affected. > > 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? I don't think that it may not happen, but I say that it did not seem to happen so far which makes me think it won't happen often and when it happens autobuilders will try again anyway. I understand that having this issue is painful for people like you doing the hard work of rebuilding many packages and I'm trying to help. Starting with 17.x the tests won't make the build fail until they run reliably thus you'll be able to rebuild kodi. Valgrind will also help upstream in catching bugs earlier. > > (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 guess you can build it with "DEB_BUILD_OPTIONS=nocheck", thus this seems to be a bit of exaggeration. > > I would say that would deserve important severity at least. I think the bug does not fit "important"'s definition [1] but feel free to raise it. I agree with you on this bug being valid and needs to be fixed no matter what the severity is. Cheers, Balint > > (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. [1] "important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone." _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers