On Fri, Sep 12, 2025 at 08:13:21PM -0400, James McCoy wrote: > This is the part that fails and even in the non-truncated logs, I don't see > any error. It looks more like the process just died. > > This sounds more like a situation of the build trying to do more than the VM > can handle (possibly related to the discussion[0] on -devel at the end of > 2024). > > [0]: https://lists.debian.org/msgid-search/20241128095437.ga845...@subdivi.de
Hi. It would seem at first, but I monitor Committed_AS in /proc/meminfo during the build, at 1-second intervals, and then use the collected data to ensure that a given package is never built on a machine which might have less RAM than required. The collected data for subversion tells me that 1 GB of RAM is more than enough to build the package on a machine with 2 CPUs, and therefore this does not seem the kind of problem that Helmut tries to solve in the above thread. I'm going to provide a VM for you. The caveat is that the build failures happen randomly with a probability less than 10%, so you will need to build the package inside a for loop to get some build failures. For completeness, I'm also putting all the failed build logs I keep for subversion in trixie here: https://people.debian.org/~sanvila/build-logs/202509/ There is one datail that might be relevant: I usually do archive rebuilds with machines having 1 CPU and 2 CPUs. So far, subversion has never failed when using 1 CPU and all the failures happened with 2 CPUs. Not sure if this means something for you. Thanks.
