On Wed, Jul 09, 2025 at 06:28:44PM +0200, Étienne Mollier wrote:
For what it's worth, I have run the builds on a beefy laptop,
and despite having most of the build process being already
serialized, I noticed that my memory consumption was pretty
high. I wonder if there could also be some resource exhaustion
at play.
That would be a possibility in theory, but my autobuilders do nothing
else than building packages, always one package at a time, and they
always have enough memory.
To achieve that, I monitor Committed_AS in /proc/meminfo and collect
statistics about all packages. Then, when the central server receives
a request from one of the autobuilders to "build something", a package
which is buildable in the autobuilder which request a jobs
is always assigned, according to its available memory.
For the particular case of scilab, it needs around 981 MB to build
on single-cpu systems and 1321 MB to build on systems with 2 CPUs.
My smallest machine these days have 4GB of RAM, so I don't think
memory is the problem here.
I also notice that the kernel run is the cloud variant. Maybe
having a look at differences with the plain kernel could reveal
some clues? (assuming that the problem has not disappeared from
6.12.32 to 6.12.33…)
That would also be a possibility in theory, but I think it's unlikely.
Lucas Nussbaum has been using the cloud variant for ages for his
archive rebuilds, and so far we have never ever found a package which
failed because of such reason.
So, it is not impossible, but I would prefer to leave that for the
case that we have no other choice.
(If you think about it, that would pose some interesting challenges
and technical issues: What legitimate reason could a package have to
ftbfs if you don't use the standard kernel, and how are we supposed to
express such dependency in debian/control?)
In case it matters, the failure rates that I got recently were:
10% (5 out of 50) on systems with 1 CPU
78% (39 out of 50) on systems with 2 CPUs.
I suspect of a race condition of some kind, so if you are still
willing to try different things (as opposed to directly trying
in my VM after I finish my last test build), I would try
bulding the package on a self-hosted qemu/kvm machine
with exactly 2 CPUs. You can probably achieve the same
effect by using GRUB_CMDLINE_LINUX="nr_cpus=2" (i.e.
modify /etc/default/grub, run update-grub and reboot).
(btw: Building scilab in unstable 100 times as we speak, I believe
that by night I will be able to tell the outcome).
Thanks.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)