[Debian-med-packaging] Bug#988469: mypy: failure on armhf and i386

[Michael R. Crusoe]

On Thu, 13 May 2021 21:04:57 +0530 Ritesh Raj Sarraf <rrs at debian.org> wrote:
 > Package: mypy
 > Severity: important
 > Tags: ftbfs
 >
 > Dear Maintainer,
 >
 > During a rebuild of your package, it was noticed that the package ftbfs
 > on common 32 bit platforms. So far, I've seen it happen on i386 and
 > armhf. The same failures are also seen on the reproducible builds
 > project.

 >
 > cc1: out of memory allocating 32764 bytes after a total of 93487104 bytes

Dear Ritesh Raj Sarraf,

Thank you for your report.

The mypy package built just fine on the buildds for all release 
architectures, including i386 and armhf: 
https://buildd.debian.org/status/package.php?p=mypy

This out of memory situation in your rebuild and by the reproducible 
builds project could be fixed by lowering the optimization level or even 
disabling compilation and using the pure Python approach, but then users 
will have a less performant mypy experience.

https://salsa.debian.org/med-team/mypy/-/blob/d9c04b579f68035058c06a2e393a6d46d1447e3d/debian/rules#L16

Given that we have working packages built on the buildds already, I am 
disinclined to lower the performance at this time.

I will positively consider other approaches to reducing the memory 
requirements that do not reduce the optimization level of the compiled 
mypy libraries.

I wonder how big the difference is between the buildd systems (or the 
parts allocated to package building) are compared to the reprobuilds VMs.

At 
https://jenkins.debian.net/userContent/about.html#_reproducible_builds_jobs 
I read that

 > for i386 we are also using four virtual machines, 
ionos(2+6+12+16)-i386, which have 10 or 9 cores and 36gb ram each. 
ionos2+12 run emulated AMD Opteron CPUs and ionos6+16 Intel Xeon CPUs.

and

 > To test armhf we are using 28 small boards hosted by 
vagrant at reproducible-builds.org <mailto:vagrant at reproducible-builds.org>:
 > - six quad-cores (cbxi4a, cbxi4b, ff4a, jtx1a, jtx1b, jtx1c) with 4gb 
ram,
 > - one hexa-core (ff64a) with 4gb ram,
 > - two quad-core (virt32a, virt64a) with 15gb ram,
 > - four quad-core (virt32b, virt32c, virt64b, virt64c) with 7gb ram,
 > - two octo-cores (odxu4a, odxu4b) with 2gb ram,
 > - eleven quad-cores (wbq0, cbxi4pro0, ff2a, ff2b, odu3a, opi2a, 
opi2c, jtk1a, jtk1b, p64b and p64c) with 2gb ram, and
 > - two dual-core (bbx15 and cb3a) with 2gb ram each.

I don't see where to get the specs of the buildd nodes: 
https://db.debian.org/machines.cgi?host=x86-grnet-01 does not list 
number of cores or memory available, for example

On IRC I was told that the x86-grnet-01 i386 buildd machine has "4 
cores, 8G" of memory, so I wonder if the repo-builds are artificially 
limiting the amount of memory to their VMs. 93487104 bytes is just 89 
Mebibytes..

-- 
Michael R. Crusoe


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20210514/5ccffec4/attachment.sig>