On Sat, Nov 10, 2018 at 04:09:55PM +0100, Helmut Grohne wrote: > On Sat, Nov 10, 2018 at 09:29:42AM -0500, James McCoy wrote: > > On Fri, Oct 26, 2018 at 03:30:54PM +0200, Helmut Grohne wrote: > > > Looking to reproducible builds, the failure pattern looks quite random: > > > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neovim.html > > > The armhf & ppc64el buildd failures I can't reproduce on the > > porterboxes, although the latter is likely another flaky test. > > armhf likely needs to be retried as the build timed out.
It should't have timed out, though. A single test shouldn't take >150 minutes. :) It got stuck, and I would need to investigate that live. > > > However, in local builds for unstable/amd64 in sbuild, I didn't get a > > > single successful build. > > > > If it's not any of the mentioned failures, then some more information > > would be useful, as I have quite the opposite behavior locally. > > What information are you interested in? First off would be the actual failure, but it seems you were hitting the one I reported to upstream. > I also tried in pbuilder and there I only got the utf_char2bytes > failure, not the ones with check_cores. This hints that something about > my build environment is fishy. If I understand correctly, my user's > resource limits "leak" through sbuild while they don't pass through > pbuilder. Would limiting the number of processes or virtual memory be a > plausible explanation for the failures? Possibly. I can more reliably hit the utf_char2bytes failure when I have other builds running in parallel. It seems to correlate with resource contention. > So it might be useful to reduce the scope of this bug to the > utf_char2bytes failure and the armhf/ppc64el buildd failures. Sounds reasonable. Any help triaging/narrowing down ways to reproduce the failures would be helpful. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
